Been looking at Bram's proposal, trying to understand it. Here it is in two forms: a new, object-oriented implementation, and his original one commented.
I could have got either of these completely wrong.
You got that right. Minor stylistic points - in your OO implementation, it doesn't clear the already_selected flags when done, and Person.connect() isn't idempotent.
One point you missed in the comments is that when numhits are equal then the order added is used as a tiebreak.
I'm unfamiliar with the 'paraphrase the following in english' style of commenting. It seems to work well.
The reason for not revisiting the same person twice in a single ranking and backing out of dead ends is performance. If you simply cycle through peers, then it can get stuck in an exponential time circuit. For example, if A certifies B, B certifies A and C, C certifies A and D, D certifies A and E, etc.
The main problem with this approach is that it doesn't treat someone who's a friend of a friend in five ways as necessarily higher up than a friend of a friend in only one way. Instead it escalates to the rather crude and arbitrary order peers was added tiebreak. Peer positionings are generally 'near' the optimal places, but far too crude for your 50 closest friends of friends application.
Also you forgot to say that the src unit is infact by multiple loop holes a randomization of influx so that a flux of a flux will make a back reverse postulate into the OC.
It's not as incomprehensible as it seems. Imagine each LJ user as a dot on a huge piece of paper. Draw an arrow from each person to each person on their friends list - we call this line connecting the two of them an "arc". Bram's metric writes a number on each arc, which is initially zero; it's incremented every time the arc is used to certify someone. He considers each outgoing arc from a person in the order of these numbers, lowest first, so the least used arcs are preferred for use next time. However if several arcs carry the same number, then the order in which those friends are listed is a tiebreak.
One point you missed in the comments is that when numhits are equal then the order added is used as a tiebreak.
I'm unfamiliar with the 'paraphrase the following in english' style of commenting. It seems to work well.
The reason for not revisiting the same person twice in a single ranking and backing out of dead ends is performance. If you simply cycle through peers, then it can get stuck in an exponential time circuit. For example, if A certifies B, B certifies A and C, C certifies A and D, D certifies A and E, etc.
The main problem with this approach is that it doesn't treat someone who's a friend of a friend in five ways as necessarily higher up than a friend of a friend in only one way. Instead it escalates to the rather crude and arbitrary order peers was added tiebreak. Peer positionings are generally 'near' the optimal places, but far too crude for your 50 closest friends of friends application.
Reply
I missed this altogether. Thanks for pointing it out!
Reply
Reply
Does that make any more sense?
Reply
Reply
Leave a comment