There is also the option of adding another numeric type: bignum. This would
probably take a lot of work though.
On 12 Mar 2014 08:47, "Frederick H. Pitts" <[email protected]> wrote:
> 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
>
>
>
>
