- Any live cell with fewer than two live neighbours dies, as if caused by under-population.
- Any live cell with two or three live neighbours lives on to the next generation.
- Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
- Any live cell with more than three live neighbours dies, as if by overcrowding.
Hm, another graphic challenge. Gotta try the new PICO-8 0.1.1 out.This is meant to give advantages to calculators.
I think I know what my approach (in Ti-BASIC) will be. It will be very slow when golfed completely, and I don't think we should expect any of these to be of practical speed.This is code golf so size > speed :)
Sorry, stupid question and off-topic but how do I access IRC?You get access to it once you get 40 post IIRC :)
That's true, but for the OmnomIRC shoutbox. Otherwise, get a IRC client such as Hexchat or mIRC and point it at either irc.efnet.org or irc.omnimaga.org.Sorry, stupid question and off-topic but how do I access IRC?You get access to it once you get 40 post IIRC :)
I don't really see why it wouldn't. It's pretty much Lua with a graphics library.Hm, another graphic challenge. Gotta try the new PICO-8 0.1.1 out.This is meant to give advantages to calculators.
I think I know what my approach (in Ti-BASIC) will be. It will be very slow when golfed completely, and I don't think we should expect any of these to be of practical speed.yeah, Ti-Basic already needs about a minute to update every pixel without doing any logic. I hope you're patient, c4ooo :P
EDIT: That pun was probably the worst in the history of code golf.
Sorry, stupid question and off-topic but how do I access IRC?
EDIT: -_- I don't want to spam the fora, so I'll wait.
EDIT: That pun was probably the worst in the history of code golf.
- The game must start in a pseudo random configuration, and no user input is required.
Overall, I'm fairly happy with this question being sufficiently specified. However, I see one rule that should probably be specified further:Fixed :D
- The game must start in a pseudo random configuration, and no user input is required.
As an example of abuse, a single cell placed pseudorandomly is a "pseudo random configuration," but not a very interesting one as every generation after the initial will just be entirely empty. You could fix this by specifying that every cell's initial state must have a nonzero chance of being in each state and must be independent (barring reasonable PRNG limitations) of every other cell's initial state.
Also, you may want to consider adding a minimum bound on FPS. I realize this is a code golf contest, but at a point, one has to say that an extremely slow game of life simulation is no longer an acceptable game of life simulation. I understand that this may make the challenge as currently specified more or less impossible in some languages, in which case you could consider extending the exception to the "full screen" rule. I would suggest something like a minimum of 0.1 FPS and allowing entries that cannot meet this at full screen to run on a square board with a side length of at least 16 and no less than the largest power of two that satisfies the minimum FPS.Nahh, it have plenty of time ;)
I think you should specify a minimum screen size, because on any machine without a screen the solution is trivial: since there are no pixels, do nothing.Standard loopholes apply : http://meta.codegolf.stackexchange.com/questions/1061/loopholes-that-are-forbidden-by-default
@pbfy0 what language are you using? That sounds fast for Axe, especially golfed Axe.Well, doesn't the emulator Wabbitemu have an option to run TI-83/84/+/SE code at 1600% speed or something? That would mean about 7.5 minutes per frame :P
I managed to shave one more byte, but now my code takes two hours per frame. I hope you have the patience to test it, c4ooo...
And also a small hint to axe golfers: randomizing the screen only takes 3 bytes :P
IMO, 11:59:59 PM ET Sunday would probably be better for those who don't have time through the week.
Not to try to nitpick, but I feel obligated to point out that Haobo's solution does not wholly satisfy rule 4: "... every cell's initial state ... must be independent (barring reasonable PRNG limitations) of every other cell's initial state." The reason I suggested this clause was to prevent simple "randomization" implementations that do not provide at least somewhat convincing randomization. Regrettably, this solution's clever approach of simply using a randomly chosen 768-byte block of memory as the initial state does not satisfy this.+1 for that proof ( or attempt of) :thumbsup:
A heuristic proof of this could cite that memory almost always contains meaningful, structured data. As a particuarly apparent example, memory often contains large stretches of zeroes. If one such large stretch were contained in the initial state, then a pixel's probability of starting dead is greatly increased if the byte(s) immediately before it are all zero. This constitutes dependence. And also a pretty boring game of life, which is why the clause was proposed.
Although less apparent on structured data that's not just a stretch of zeroes, the same dependence and insufficient randomness exists in any non-chaotic data. So to extend this heuristic proof to a definitive one, one can prove that non-chaotic data exists in memory. And this can be done by citing the existence of the program itself in memory.