Are the following acceptable truthy and falsy results:

• 2 and 0
• no error and error
• 1 and no output

Is there a minimum input value up through which the program must return correct results?

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.

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.

I came down on lirtosiast and pbfy0 earlier about skirting around this clause, so I thought it to only be fair that I come down here as well. I even came down on myself by proposing this clause in the first place, as I was considering using such a "randomization" approach but considered it against the spirit of the prompt.

Updated with lots of new stuff on July 1!

---

Axe 1.3.0 may be coming soon. It doesn't change the language at all, but It adds some new commands, improves some old ones, and improves the Axe application a lot because I rewrote a lot of internals. Primarily, compiling should be significantly (~4x) faster:

Axe 1.2.2	Axe 1.3.0

Because of all the rewriting I did, I fear that I may have introduced bugs. I've squashed all the bugs I found so it shouldn't just be bug city, but I'd still like it to be tested a bit more before an official release. So if you're feeling a bit brave, try the potential Axe 1.3.0.

Changelog:

• Compiling may be up to 4x as fast due to extensive internal optimization.
• New, deterministic rand routine. Seedable from external randomness with rand^r (suggested) or with EXP→rand.
• Generate a random integer from a range with randInt(EXP) or randInt(EXP1,EXP2).
• Sprite rotation and flipping commands accept an optional destination pointer for the result.
• Back buffer and arbitrary buffer variants for StoreLCD (StoreGDB).
• Custom constants/variables and labels can start with a lowercase letter and be up to 30 tokens long.
• The compile menu remembers the last selected entry.
• The compile menu shows up/down arrows for more items like OS menus.
• The compile menu allows deletion of source programs.
• The options menu allows toggling the token hook.
• Progress calculation is more accurate.
• Freq() suspends interrupts while executing.
• Send() and Get suspend interrupts and set the CPU to normal speed (~6MHz) while executing.
• USB interrupts should no longer be able to trigger and freeze the calculator when a custom interrupt is enabled.
• Improved/expanded the documentation of a number of commands in the command list.
• Optimized bitwise and/or with constants that only afffect one bit in a byte.
• Optimized nib()^r slightly.
• DS<(VAR,EXP) now works with all variables.
• Files can no longer be used in some places they shouldn't have been able to before.
• Comments are now allowed and parsed correctly in a few places that they should have been before.
• More robust header parsing.
• Axe will now only run Axe Fusion programs compiled with the same version of Axe to protect against flaws inherent in the design of Axe Fusion.
• Greatly increased the number of replacements that the Axiom system can keep track of at once, from 8 to 128.
• The "APP TOO BIG" error is no longer thrown when compiled code hits 16KB for non-application shell targets.
• Removed erroneous "www" from help link.

Also, to remind people:

In the process of completely recoding the menus, I added an option that I've heard asked for a couple of times: the ability to disable the token hook. But in doing so, I needed to add a second options page, which is currently barren. Give me suggestions for two new options!

Are we so against necroposting that we need to create new threads for late, but on-topic replies? It seems to me like that's taking things a bit too far.

If part of the issue is the topic title being misleading, I'd recommend simply putting something like [ENDED] at the front of the topic title when a contest is over, so any posts made after that point will have that tag and show up with that tag in new post notifications.

I believe it's the same build, or if not, very close. Both should just be 1.2.2 with a couple of improvements, so they should be stable.

Apparently certain aspects of Axioms have been broken according to this post on CW. The same code compiles on an older version of Axe, but not the newer versions, and it's an Axiom thing. I haven't gotten around to testing to see if it is every axiom or Glib itself, but I thought you should know, since the discussion is going on elsewhere.

It seems like you misunderstood what he was saying. He brought this problem to my attention a while ago and I fixed it for him in my in-development build of Axe. So he was saying that the Axiom doesn't work with any publicly released versions of Axe and that you need to use this development build.

I hope to make a public release of this eventually. But as of that build, the changes only fixed edge cases ran into by a few users and didn't seem warrant a release. And as of my current, internal build, lots of stuff is broken due to refactoring.

This topic has been moved to TI Z80.

https://www.omnimaga.org/index.php?topic=22051.0