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

[Frederick H. Pitts]

Hello Jürgen,

        Web page http://www.gnu.org/software/apl/apl.html#Chapter-3 states Gnu
APL integers are 64-bit wide, thus ranging from -9223372036854775808 to
9223372036854775807.

        As a naive user, I expect that to mean I can do accurate integer
addition and subtraction in the above stated range.  My experience is
otherwise. In that range a calculation as simple as

        Z ← 1 + V − V + 1

where V is a randomly generated, fails to return 0 about 99.8% of the
time. Changing the 1's to 100000 in above statement does not materially
change the results.  The calculation still fails over 99% of the time.
Integer addition and subtraction is accurate in the 9007199254740991 to
-9007199254740992 range (which corresponds to 53 bits plus a sign bit).
        
        An apl script file that demonstrates this issue is attached.

        I respectfully submit that the documentation should reflect the
narrower range for integers until such time this issue is corrected.

Regards,

Fred
        
On Wed, 2014-03-12 at 13:24 +0100, Juergen Sauermann wrote:
> Hi Elias,
> 
> thanks, fixed in SVN 162. In that range it can still happen that
> "small" differences occur because an operation may be internally
> performed as double and then converted to integer. The double has
> 48-1 bit precision and the integer 64-1 bit precision. It depends a
> little
> on how the actual operation is implemented.
> 
> /// Jürgen
> 
> 
> On 03/11/2014 04:32 PM, Elias Mårtenson wrote:
> 
> > Running ⎕SYL shows the following:
> > 
> > 
> >       largest integer                         9223372036854775807
> > 
> > 
> > Trying to subtract one from this value gives a weird result:
> > 
> > 
> >       9223372036854775807-1
> > ¯9223372036854775808
> > 
> > 
> > Regards,
> > Elias
>

MAXINT.apl.gz
Description: GNU Zip compressed data