4 ms·

By definition… if there’s no end condition, it won’t end ;)

by baq 3y ago

praptak 3y ago
On top of this there's a negative feedback loop. The ball whose territory gets smaller has less distance to travel between hits. This means that even if there was anything resembling a "win" condition it would be hard to achieve.
- mrec 3y ago
  You'd think, but I'm currently looking at a 161/863 split which has been pretty stable for a while now. I thought at first that ball speed is being scaled by territory size to cancel out the negative feedback, and the "winning" ball is moving noticeably faster than the losing one, but I can't see that being deliberate in the code. (There is some randomization of speed on a bounce, but it ought to be pure noise.) EDIT: 120/904 now.
- yellowapple 3y ago
  One possible win condition would be a ball reaching the opponent's side. That happened in my case, with "night" eventually breaking through to the left-most edge.
- geor9e 3y ago
  That just explains why it tends towards balance. It's just like all the air molocules in a room reliably bouncing around where you can inhale them. There's no hard law of nature saying all the air wont move to one side, suffocating you. It's just statically extremely improbable. But they asked for proof for or against a possibility at all, not whats probable.
deleted 3y ago
[deleted]
keyle 3y ago
Which makes the name War even better. There is no winner in war and the cycle repeats itself.
geor9e 3y ago
It's ambiguous. The end condition could be a pixel spawning with overlap on a ball because there's nowhere else to go. What will happen when there's no room left to add one more pixel, and it tries to add one more pixel? Will it place it with the collision boundaries on the wrong sides? Will it crash with a null value error because there's no good spot to place it? Can't know without understanding the code. But there are many possible end conditions. They're asking if one can prove that you never reach any situation where an end condition (intended or not) could ever exist. Imagine black has a long horizontal 1 pixel tunnel, but it's zigzagging down hitting every side pixel rapidly, while white has a long white tunnel and it's bouncing perfectly horizontally, taking a long time to hit each end. As the ends close in on white, is there some perfectly aligned timespan where black can hit a pixel while white doesn't have a full pixel of open space on either side? It would be interesting if someone can articulate logically why or why not that would ever happen.

By definition… if there’s no end condition, it won’t end ;)

by baq 3y ago

By definition… if there’s no end condition, it won’t end ;)

On top of this there's a negative feedback loop. The ball whose territory gets smaller has less distance to travel between hits. This means that even if there was anything resembling a "win" condition it would be hard to achieve.

mrec 3y ago
You'd think, but I'm currently looking at a 161/863 split which has been pretty stable for a while now. I thought at first that ball speed is being scaled by territory size to cancel out the negative feedback, and the "winning" ball is moving noticeably faster than the losing one, but I can't see that being deliberate in the code. (There is some randomization of speed on a bounce, but it ought to be pure noise.) EDIT: 120/904 now.
yellowapple 3y ago
One possible win condition would be a ball reaching the opponent's side. That happened in my case, with "night" eventually breaking through to the left-most edge.
geor9e 3y ago
That just explains why it tends towards balance. It's just like all the air molocules in a room reliably bouncing around where you can inhale them. There's no hard law of nature saying all the air wont move to one side, suffocating you. It's just statically extremely improbable. But they asked for proof for or against a possibility at all, not whats probable.

deleted 3y ago

[deleted]

keyle 3y ago

Which makes the name War even better. There is no winner in war and the cycle repeats itself.

geor9e 3y ago

It's ambiguous. The end condition could be a pixel spawning with overlap on a ball because there's nowhere else to go. What will happen when there's no room left to add one more pixel, and it tries to add one more pixel? Will it place it with the collision boundaries on the wrong sides? Will it crash with a null value error because there's no good spot to place it? Can't know without understanding the code. But there are many possible end conditions. They're asking if one can prove that you never reach any situation where an end condition (intended or not) could ever exist. Imagine black has a long horizontal 1 pixel tunnel, but it's zigzagging down hitting every side pixel rapidly, while white has a long white tunnel and it's bouncing perfectly horizontally, taking a long time to hit each end. As the ends close in on white, is there some perfectly aligned timespan where black can hit a pixel while white doesn't have a full pixel of open space on either side? It would be interesting if someone can articulate logically why or why not that would ever happen.