bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Access to rational number numerator and denominator


From: Frederick Pitts
Subject: Re: [Bug-apl] Access to rational number numerator and denominator
Date: Tue, 29 Aug 2017 05:00:41 -0500

Guys,

To make it clear, I'm not asking for bigints. I'm just seeking to get the maximum benefit of having rational numbers with, as Xtian says, ~63-bit numerator and denominators. As long as you limit yourself to using addition, subtraction, multiplication, and division and avoid overrunning the ~63-bit limitation, the rationals work as expected up to that ~63-bit limit AFAIK. But use any other function, say power (⋆) or least common multiple (∧), difficult to predict floating-point conversions reduce the ~63-bits to 53-bits or less and produce incorrect results.

Louis recommended the LCM function as a means of separating a rational into its numerator and denominator so I could program with them individually. Louis mentioned that he did not have access to a APL keyboard while composing his email, so I took his use of LCM to mean the native
Gnu-APL ∧ function and that is why I tried using it. Turns out that Ken Iverson presented APL code for GCD and LCM functions in his "Notation as a Tool for Thought" Turing Award paper that avoid floating point arithmetic. Preliminary testing indicates those implementations will do the job.

Still, if Gnu-APL is going to support rational numbers, an efficient mechanism for accessing numerators and denominators similar to the circle function (○) with 9 and 11 left arguments for accessing the real and imaginary parts of complex numbers is needed. Could implementing this functionality be added to someone's to-do list, please?

Regards,

Fred
On Tue, 2017-08-29 at 10:57 +0800, Elias Mårtenson wrote:
A bigint is an arbitrary-precision integer. Such as what is provided in Lisp:

In Lisp, I get the correct rational number:

CL> (/ (expt 2 1000) 3)
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376/3

In GNU APL:

      ⎕PS←1 0
      3÷⍨2⋆1000
3.571695357E300

With bigints, the APL result would be similar to that of Lisp.

Regards,
Elias


On 29 August 2017 at 10:48, Christian Robert <address@hidden> wrote:
what is "bigints" ?

larger than ~62 bits or 9200000000000000000 ?

If so, I would agree 100%. Having a limit that is less than exact 64 bits (signed or unsigned)
is wrong. encode & decode can't manage more than ~62-~63 bits limit.


my 2 cents,
Xtian.

On 2017-08-28 22:33, Elias Mårtenson wrote:
The true benefit of rational numbers is realised once there is support for bigints. Jürgen has suggested that that is planned, and personally I can't wait.

Regards,
Elias

On 29 August 2017 at 08:59, Frederick Pitts <address@hidden <mailto:address@hiddent>> wrote:

    Louis,

             Thanks for the quick response.

             After working with the technique a bit, I observe that as long
    as the rational number denominator is well within the range of integers
    representable by floating numbers, 1 ∧ n returns the correct result.
    But if the absolute value of the denominator exceeds 2 ⋆ 35, the
    technique returns incorrect results.  For instance,

           fiMax ← × / 53 ⍴ 2 ⍝ largest integer 53-bit f.p. mantissa holds
           fiMax
    ╔════════════════╗
    ║9007199254740992║
    ╚════════════════╝
           1 ∧ fiMax ⍝ Correct result for fiMax
    ╔════════════════╗
    ║9007199254740992║
    ╚════════════════╝
           1 ∧ ÷ fiMax ⍝ Incorrect result. 1 is numerator of reciprocal.
    ╔═╗
    ║0║
    ╚═╝

             I was hoping to be able to access correct rational number parts
    even when they approach the ⎕SYL[20;2] limit of 9200000000000000000.
    It seems a shame to loose so much of the integer range because floating
    point operations are sneaking into the numerator and denominator access
    methods.

    Regards,

    Fred

    On Tue, 2017-08-29 at 00:08 +0200, Louis de Forcrand wrote:
     > Hi,
     >
     > No APL kb with me right now, sorry :(
     >
     > 1 LCM n
     >
     > gives the numerator of a fraction (floating or exact). If you need
     > the denominator, do the same with the inverse of n. If you need both,
     > for example:
     >
     > 1 LCM n POW 1 _1
     >
     > Cheers,
     > Louis
     >
     > > On 28 Aug 2017, at 23:24, Frederick Pitts <address@hidden <mailto:address@hiddent>>
     > > wrote:
     > >
     > > Hello,
     > >
     > >    Is there an existing mechanism for accessing rational number
     > > numerator and denominator parts analogous to that for accessing
     > > complex
     > > number real and imaginary parts?  If yes, please let me know
     > > how.  If
     > > no, can a mechanism be implemented?
     > >
     > > Respectfully,
     > >
     > > Fred
     > >
     >
     >






reply via email to

[Prev in Thread] Current Thread [Next in Thread]