+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Error in 49G/50g ROM Rev 1.19-6 to 2.10-7 (/thread-19628.html)
Error in 49G/50g ROM Rev 1.19-6 to 2.10-7 - Gerald H - 03-08-2023 11:43 AM
FPTR2 ^CK1Z
supposedly converts hexadecimals to zints but in fact errors out.
RE: Error in 49G/50g ROM Rev 1.19-6 to 2.10-7 - 3298 - 03-08-2023 04:44 PM
Huh, interesting. I took a look into ROM 2.15 with Nosy, same issue. I'm tempted to just declare it a documentation error (since we're all using "Programming in SysRPL" by Kalinowski and Dominik, not a HP-made reference; as such it has some mistakes, even after the book's own errata are taken into account), but there's a little more to it:
^CK1Z (and by extension ^CK2Z and ^CK3Z, which both call ^CK1Z) uses CK&DISPATCH0 to handle various types of input with different pieces of code. So far, so normal - the handlers it associates with the dispatch codes for reals and strings are entries documented as converting reals and strings (respectively) to ZINTs: ^R>Z and ^S>Z. The only remaining dispatch code is the one for ZINTs (so the types HXS and BINT are unhandled, contrary to documentation), which makes sense since you would expect already-existing ZINTs to not get rejected. (Unlike CK&DISPATCH1, CK&DISPATCH0 won't auto-convert ZINTs to reals; you wouldn't want this lossy and inefficient there-and-back conversion anyway.)
But then it gets weird. The handler given for ZINTs is ^H>Z, which you would expect is for converting a HXS to ZINT, given the name. The documentation is a little ambiguous on it, but it definitely talks about HXS too.
But that command doesn't convert them! I looked at the code for a while and concluded that it sanity-checks the structure of a ZINT instead: non-empty digit string, no digits that would be invalid for BCD (i.e. hexadecimal digits >9), a leading 0 or 9 (the latter indicates a negative number), and not just a 9 by itself.
Since it doesn't check the prolog, you can stuff a HXS in there (they also consist of prolog, then length field, then digit string, just like a ZINT), but the results will most likely be incorrect or an error.
So here we have a command with plain wrong documentation, and another where it's at least severely misleading.
While we're at it, I recently encountered another issue: psh1& and psh1&rev have the same stack diagram (meta1 meta2 ob -> ob&meta1 meta2), though it's only correct for psh1&. psh1&rev attaches ob to the end of meta2 instead of the start (meta1 meta2 ob -> meta1&ob meta2). Just mentioning it before I forget about it again.
---
Actually, back to the problem of converting a HXS to ZINT: with ^H>Z disqualified, there doesn't seem to be a direct way to convert these types. Going via reals is easy but lossy, because e.g. #FFFFFFFFFFFFFFFFh (that's 2^64-1, the largest number the UserRPL compiler and many HXS-handling commands support) won't fit into the 12 digits of a real, so we'll have to 1) eat the loss of precision, 2) declare that HXS are not a supported input type, 3) chop them into pieces to convert separately, or 4) write our own conversion function in Saturn ASM.
RE: Error in 49G/50g ROM Rev 1.19-6 to 2.10-7 - Gerald H - 03-08-2023 08:36 PM
You might, 3298, be interested in this programme:
https://www.hpmuseum.org/forum/thread-4065.html?highlight=HEXADECIMAL