Undocummented (?) limits for the HP50g

[3298]

Can't reproduce on firmware 2.15.

# 1000000000001h (that's \(2^{48}+1\), i.e. a 49-bit number where rounding would definitely load to inaccuracy, regardless of whether rounding is performed in decimal or binary format) shows up in DEC mode as # 281474976710657d, which as far as I can tell is accurate.
SORT on that number and the 5 following numbers (that is \(\{2^{48}+1, ..., 2^{48}+6\}\)), manually brought into a random non-ascending order, sorts them correctly too.

Just don't try to convert them to reals, they only have 12 decimal digits of floating point precision. There is no direct way I know of to convert between CAS infinite-length (decimal) integers and user binary integers, but avoiding the route through reals (which you would encounter with B\->R R\->I and I\->R R\->B) is easy by going through strings: DEC 105. CF \->STR 3. OVER SIZE 1. - SUB OBJ\-> in one direction, \->STR "# " SWAP + "d" + OBJ\-> in the other. That should cover enough type juggling to do heavy calculations on long numbers originally expressed in a non-decimal base.