Re: [Bug-apl] "Largest integer" isnt' really largest?

[Kacper Gutowski]

On 2014-03-11 17:29:08, Frederick H. Pitts wrote:
>       If one executes
> 
>       i ← 0
>         63 1 ⍴ { ⍵ , i ← ¯1 + 2 × i + 1 }¨ 1 + ⍳ 63
> 
> one should get a 2-column table of bit count and corresponding maximum
> positive representable integer (assuming high order bit is a sign bit).
> The maximum integer should be odd.  Running the above on GnuAPL (as well
> as ngnAPL), reveals that maximum integer goes even at bit count 55.  It
> is strange that two independent implementations of APL have the same
> bug.

It isn't really that strange.  In case of ngn, which uses underlaying
Number type of javascript, this isn't a bug at all.  It's the correct
and expected result.  Also note that in ngn it doesn't go negative at
any point.

At count of 54 your number i equals (2⋆53)-1 which is the maximal odd
integer encodable with 53-bit mantissa of double precision floats.
The only type available in javascript is double so in ngn-apl this is
the way it should be and the only way around it is to use some kind of
arbitrary precision arithmetic.

GNU APL, however, uses both doubles and 64-bit integers interchangeably
so as long it is an integer, it should be possible to have odd numbers
up to 2⋆63 as indicated in ⎕SYL.  Apparently there are some problems
with choice of representation or conversions.  Well, it is a bug.

I believe that expected result of your code is to have odd integers up
to the count of 63 where right column should be 4611686018427387903
(i.e. (2⋆62)-1) BUT followed by 9223372036854775808 at the count of 64,
because intermediate value (after multiplication and before adding ¯1)
is bigger than (2⋆63)-1 and therefore must be converted to double.


-k