[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: |
Fri, 14 Mar 2014 17:12:51 -0500 |
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