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 <christian.rob...@polymtl.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.pit...@comcast.net >> <mailto:fred.pit...@comcast.net>> 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.pit...@comcast.net <mailto:fred.pit...@comcast.net>> >> > > 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 >> > > >> > >> > >> >> >> >
