Hello Juergen,
Thanks for the tweak to the decode function. Preliminary testing
indicates that 63 bits of a 64-bit integer are usable. For example
128 128 128 128 128 128 128 128 128 ⊤ ⎕ ← 128 ⊥ 127 127 127 127 127 127
127 127 127
yields
9223372036954775807 ⍝ NOTE this is greater than
Hi,
I have changed the decode function to stay longer in the integer domain,
SVN 416,
Not sure what is wrong with 2⋆63 - looks OK to me.
Note also that the largest integer in GNU APL (see ⎕SYL[20;]) is
920
and not 9223372036854775808 (and therefore 2⋆63 is outside that range)
Your observations are all correct. The behaviour you see are because GNU
APL values can be either integers (backed by a 64-bit integral value) or
floating point (backed by a C++ double value). Conversions between these
two underlying storage formats are transparent to the user most of the time.
*I
Hello Elias,
1) "MOST-NEGATIVE-FIXNUM" and "largest negative integer" are much closer
in connotation to each other than either is to "smallest (negative)
integer". "smallest" and "largest" are generally used when comparing
the magnitudes (or absolute values) of numbers irrespective of the signs
o
Mathematically, the term "small" is ambiguous. Perhaps that's why Common
Lisp names its corresponding value MOST-NEGATIVE-FIXNUM.
That said, in GNU APL, these numbers are somewhat bogus anyway. In
particular, the *actual* maximum number that can be stored without loss of
precision depends on the u
