Hacker News new | ask | show | jobs
by gjm11 5436 days ago
I did a little simulation. Start the vendors off in random places. Each tick, pick a random vendor and move it to its optimal place (either just left of the left-hand other one, or just right of the right-hand other one, or half-way in between; I assume for convenience that some second-order effect makes the midpoint best when you're between two others, and when putting a vendor in a new "outside" position I put it 1% of the way from the old "outside" vendor to the edge).

The resulting evolution settles down quickly to a situation in which all three are very near 0.5, and every time the middle one gets the chance to move it does so (to be just on the other side of whichever of its rivals has more space on the other side). If you plot a graph of this, you get a sort of braided effect, with the braid never getting very wide or moving very far. So it's kinda-sorta stable even though (necessarily) the vendors keep changing places.

With n>3, all sorts of more interesting things happen. For instance, for n=4 the state of the world is usually as follows. You have a cluster of (usually) 2 vendors near a (<1/2) and another near b (>1/2). The outermost vendor in each cluster is happy where it is; the inner ones will jump to just beyond the outermost of whichever cluster is further from 1/2. This means that the clusters tend to be equally far from 1/2 (because the nearer-in one is preferentially jumped to) and tend to move outwards (because a jumping vendor always jumps to just outside a cluster). But this situation can break down in two ways. (1) A vendor jumps from one cluster to the other, so we have 3+1 instead of 2+2. Then the now-isolated vendor, on its next move, will join the other cluster; we now have 4+0. Now what happens is that cluster moves en bloc towards 1/2, at which point it typically splits in two. (2) The two clusters get far enough apart that a leap into the middle becomes favoured. Actually, in my simulation #2 never happens because #1 always happens first. For larger numbers of vendors, though, you get a kinda-similar situation (two clusters, one on each side, slowly moving outward) but the number of vendors in each cluster is large enough that #2 can happen before #1 does, so sometimes you get one leaping into the middle. (As the number of vendors gets big, this becomes the dominant kind of transition, and the overall effect is that generally the vendors are quite evenly spread.)

A more realistic simulation might give quite different results, but I'm at work right now :-).

1 comments

Interesting simulation. The braided behavior sounds like the 'equilibrium behavior' I mentioned earlier. Does this simulation also allow for taking another player's exact location, forcing a split of their market share on both sides? I imagine that's a subtle but game-changing move.

For the higher vendor numbers (3+), did you notice similar behavior when the vendor parity was the same (i.e. all even or all odd)?

No, it doesn't allow two vendors to be in the exact same spot. The amount of trade that gets you is always exactly half-way between being just to the left and being just to the right, and can therefore only be the best option when all three of those are exactly equal, so I don't think it makes much difference.

I wondered whether parity would be a big deal, but -- purely qualitatively and by eye -- it doesn't seem like it is.

Very interesting observation.

In the 2 player case, not allowing for parity means that equilibrium would never be reached. The simulation as you programmed it would approach equilibrium as time goes to infinity, though, so I guess your model works about as well as one with parity, and is simpler. Nice.