[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] "Largest integer" isnt' really largest?
From: |
Frederick H. Pitts |
Subject: |
Re: [Bug-apl] "Largest integer" isnt' really largest? |
Date: |
Tue, 11 Mar 2014 19:47:04 -0500 |
Hello Kacper,
Thanks for the explanation.
I hope GnuAPL can be fixed so that accurate integer arithmetic can be
performed on integers in the 54 to 63 bit range. If not, ⎕SYL should be
changed to report the largest and smallest integers corresponding to 53
bits so that users do not get mislead into thinking that they can
perform accurate integer arithmetic on larger or smaller numbers.
Regards,
Fred
On Wed, 2014-03-12 at 01:01 +0100, Kacper Gutowski wrote:
> 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