Hello Juergen,
Thanks for the tweak to the decode function. Preliminary testing
indicates that 63 bits of a 64-bit integer are usable. For example
128 128 128 128 128 128 128 128 128 ⊤ ⎕ ← 128 ⊥ 127 127 127 127 127 127
127 127 127
yields
9223372036954775807 ⍝ NOTE this is greater than 9200000000000000000
127 127 127 127 127 127 127 127 127
Is this consistent with your expectations?
Regards
Fred
P.S. I will send the binomial coefficient APL code in a separate email
and subject line for anyone that may have use for it. Timing tests
indicate the code is 100 times slower than the primitive !, but then it
is correct up to the 9200000000000000000 limit. Is it possible to speed
up the code by a factor 100 by re-implementing in C++ in the
interpreter?
On Tue, 2014-08-05 at 15:16 +0200, Juergen Sauermann wrote:
> Hi,
>
> I have changed the decode function to stay longer in the integer domain,
> SVN 416,
>
> Not sure what is wrong with 2⋆63 - looks OK to me.
>
> Note also that the largest integer in GNU APL (see ⎕SYL[20;]) is
> 9200000000000000000
> and not 9223372036854775808 (and therefore 2⋆63 is outside that range).
> The reason
> for that is that in order to detect integer overflow the check for
> overflow itself is performed in
> double arithmetic (and subject to rounding errors). I therefore made the
> integer range slightly
> smaller.
>
> The accuracy of ! is a matter of an accuracy-speed trade-off. Computing
> N! in 64-bit integer can
> take up to 20 multiplications while the float variant is probably faster.
>
> /// Jürgen
>
>
> On 08/05/2014 06:45 AM, Frederick H. Pitts wrote:
> > Hello Elias,
> >
> > 1) "MOST-NEGATIVE-FIXNUM" and "largest negative integer" are much closer
> > in connotation to each other than either is to "smallest (negative)
> > integer". "smallest" and "largest" are generally used when comparing
> > the magnitudes (or absolute values) of numbers irrespective of the signs
> > of those numbers. So I think we are in agreement the label needs to
> > change.
> >
> > 2) 2*63 does not produce the right answer but 2*62 does. So GNU-APL is
> > capable of doing integer arithmetic well outside the 53-bit integer
> > range of double precision floating point. Unfortunately, that
> > capability is not fully utilized. It's disingenuous to claim GNU-APL
> > supports 64-bit integer arithmetic when primitive operations like ⊥
> > (decode) and ! (binomial) yield results of accuracy limited by the
> > 53-bit integer range of floating point when they do not have to be.
> > There are ways to force the use of the use of the APL_Integer! It's a
> > simple matter of programming. If you are
> > interested I can supply you with defined functions that work around
> > the ! (binomial) accuracy limitation. (Jim Weigang presented the
> > functions in comp.lang.apl years ago). I wonder how much faster the
> > functions would be if they were implemented in C++.
> >
> > Regards,
> >
> > Fred
> >
> > On Tue, 2014-08-05 at 11:34 +0800, Elias Mårtenson wrote:
> >> Mathematically, the term "small" is ambiguous. Perhaps that's why
> >> Common Lisp names its corresponding value MOST-NEGATIVE-FIXNUM.
> >>
> >>
> >> That said, in GNU APL, these numbers are somewhat bogus anyway. In
> >> particular, the actual maximum number that can be stored without loss
> >> of precision depends on the underlying data type of the value.
> >>
> >>
> >> For real numbers, this data type can be either APL_Integer in which
> >> the largest number is 9223372036854775808 (2^63), but if you try to
> >> create this number in GNU APL using the expression 2⋆63, you will get
> >> an APL_Float back, which has a smaller maximum precise value
> >> of 9007199254740992 (2^53).
> >>
> >>
> >> So, in summary. You can never rely on integral numbers being precise
> >> to more than 53 bits of precision unless there is a way to force the
> >> use of APL_Integer which I don't believe there is.
> >>
> >>
> >> It would be nice to have support for bignums in GNU APL. It wouldn't
> >> be overly difficult to implement I think. Perhaps I'll try that one
> >> day unless Jürgen is completely against the idea.
> >>
> >>
> >> Regards,
> >> Elias
> >>
> >>
> >> On 5 August 2014 09:37, Frederick H. Pitts <fred.pi...@comcast.net>
> >> wrote:
> >> Juergen,
> >>
> >> Please consider the following:
> >>
> >> ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 53 ⍴ 1
> >> 9007199254740991
> >> 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> >> 1 1 1 1 1
> >> 1 1 1 1
> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> >> ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 54 ⍴ 1
> >> 18014398509481984
> >> 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >> 0 0 0 0 0
> >> 0 0 0 0
> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >>
> >> Between 53 bits and 54 bits, decode starts returning
> >> an incorrect
> >> result (the reported value is even when it should be odd).
> >> Presumably
> >> floating point numbers start creeping in at that point.
> >> Is it possible to tweak the decode code so that at
> >> least 62 bits of a
> >> 64-bit integer are usable with encode and decode? I'd really
> >> like to
> >> use 9 7-bit fields (63 bit total) to track powers of
> >> dimensions in
> >> unit-of-measure calculations but I'm confident that is asking
> >> for too
> >> much. I can cut the range of one of the dimensions in half.
> >>
> >> BTW, the "smallest (negative) integer" label of the
> >> ⎕SYL output would
> >> read better as "largest negative integer".
> >> ¯9200000000000000000 is not
> >> small.
> >> ¯1, 0, and 1 are small.
> >>
> >> Regards,
> >>
> >> Fred
> >> Retired Chemical Engineer
> >>
> >>
> >>
> >>
> >
> >
> >
>
