There seems to be a bug in extended ELIF statements, at least in Task 1101.
Realizing that the inputs for Task 1101 were only 4 bits (which seems an oversight; there are 34 inputs which could potentially be doubled without overflowing the eight-bit register), I hardcoded a lookup table and soared way under the par time for steps, though obviously was way above the par word count:
However, I ran into serious problems and inconsistencies trying to optimize this solution further. If I end these IF statements with ELIF, the program runs fine. However, ending with ELSE (which, since I cover all possible branches, should lead to the same thing) leads to the ELSE getting triggered a significant portion of the time. In this case, the program only succeeds on the last three branches, which doesn't seem intended:
Additionally, and I don't know if this is intended or not, the @ statement overrides long IF / ELIF chains, forcing the program into sections of code under IF statements whose conditions are not met.
