HHC 2022 - Programming Contest - no responses until after 6am Monday 6am CENTRAL

[3298]

(09-12-2022 11:52 AM)John Keith Wrote:  I agree with 3298's reasoning and in fact, you don't even have to formally "attach" Library 256, just set flag -86 and do a warm start.

Ohh right, I keep forgetting about that flag because it's one of those omitted from the built-in flag browser. Thanks!

---

Well, all "central" times (Australian, European, North American) have progressed past 6:00, and other programs have shown up, time for my program:

Code:

\<<
  0. SWAP
  \<<
    DUP # A5002h FLASHEVAL
    9. 20. SUB
    "." + OBJ\->
  \>>
  \-> r \<<
    DO
      r EVAL +
      SWAP 1. + SWAP
    UNTIL
      IF
        DUPDUP 1. + ==
        PICK3 50. >
        OR
      THEN
        DROP2 0. 0.
        1.
      ELSE
        r EVAL OVER ==
      END
    END
  \>>
\>>

184. bytes, #919Ah as shown. The FLASHEVAL with the binary number before it runs the internal part of \->H (without checking for the presence of an argument). That's the L256 workaround, and replacing it with \->H itself shrinks it to 171. bytes, #DA9Dh.
The subprogram containing this workaround is responsible for reversing the digits of a number. \->H is handy here: a real number has its digits (for both mantissa and exponent) stored in BCD, little endian (= backwards, just like we need). I merely need to lop off the prolog, exponent, and mantissa sign. The digit sequence may contain formerly-trailing now-leading zeroes, but OBJ\-> happily ignores them. I only need to tell it to make a real number by appending ".", otherwise an exact integer will pop out if the user has exact mode on.
This part is a subprogram because it's used in two places: adding the reversed onto the original, and checking for a palindrome (the latter is implemented as an equality check between reversed and original).
The only other remotely noteworthy piece is how I implemented the error conditions:
- an overflow is tested for by checking if adding 1. changes the number at all or if it gets swallowed by rounding to 12 significant digits;
- testing for 50 iterations takes place after the addition, so in the unlikely case it gets triggered there will be a 51st addition, and its result will be discarded. This is merely a performance concern, it doesn't affect the correctness of the results.

A variant with exact integers could be made from this as well. The obvious changes are tossing the overflow check, skipping the piece appending "." to the string given to OBJ\->, and doing R\->I at startup. The non-obvious one is that the arguments to the SUB command extracting the reversed digits from the output of \->H will have to be adjusted to the in-memory format of an exact integer: 11. OVER SIZE 1. - SUB should do the trick.

PS: come to think of it, appending "." is not necessary at all, because adding an exact integer onto a real produces a real anyway. Omitting "." + saves 8.5 bytes, bringing my program down to 175.5 bytes, #C11Ah with the L256 workaround or 162.5 bytes, #1EBAh without.