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 nativeGnu-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,
FredOn 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)
>
> 107150860718626732094842504906000181056140481170553360744375038837035
> 105112493612249319837881569585812759467291755314682518714528569231404
> 359845775746985748039345677748242309854210746050623711418779541821530
> 464749835819412673987675591655439460770629145711964776865421676604298
> 31652624386837205668069376/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 <christian.robert@polymt
> l.ca> 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 <fred.pitts2@comcast.
> > > net <mailto:[email protected]>> 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 <fred.pitts2@c
> > > omcast.net <mailto:[email protected]>>
> > >
> > > > > 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
> > >
> > > > >
> > >
> > > >
> > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
