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 underlying data type of the value. For real numbers, this data type can be either APL_Integer in which the largest number is 9223372036854775808 (2^63), but if you try to create this number in GNU APL using the expression 2⋆63, you will get an APL_Float back, which has a smaller maximum precise value of 9007199254740992 (2^53). So, in summary. You can never rely on integral numbers being precise to more than 53 bits of precision unless there is a way to force the use of APL_Integer which I don't believe there is. It would be nice to have support for bignums in GNU APL. It wouldn't be overly difficult to implement I think. Perhaps I'll try that one day unless Jürgen is completely against the idea. Regards, Elias On 5 August 2014 09:37, Frederick H. Pitts <fred.pi...@comcast.net> wrote: > Juergen, > > Please consider the following: > > ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 53 ⍴ 1 > 9007199254740991 > 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 1 1 1 > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 54 ⍴ 1 > 18014398509481984 > 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > Between 53 bits and 54 bits, decode starts returning an incorrect > result (the reported value is even when it should be odd). Presumably > floating point numbers start creeping in at that point. > Is it possible to tweak the decode code so that at least 62 bits > of a > 64-bit integer are usable with encode and decode? I'd really like to > use 9 7-bit fields (63 bit total) to track powers of dimensions in > unit-of-measure calculations but I'm confident that is asking for too > much. I can cut the range of one of the dimensions in half. > > BTW, the "smallest (negative) integer" label of the ⎕SYL output > would > read better as "largest negative integer". ¯9200000000000000000 is not > small. > ¯1, 0, and 1 are small. > > Regards, > > Fred > Retired Chemical Engineer > > >
