Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value [Request: ET-10405 is created]
Thank you for your email request. Your request ID is I-1549154 DCU Home Branches Branch/ATM Locator Contact Our Privacy Policy protects your privacy and we will never sell your name or email address. Federally insured by NCUA. DCU is an Equal Housing Lender. Please do not reply to this email. For questions or additional information, please email d...@dcu.org. 220 Donald Lynch Boulevard, PO Box 9130, Marlborough, MA 01752-9130 508.263.6700 • 800.328.8797 ABA Routing Number: 211391825NMLS#: 466914 © Digital Federal Credit Union
[perl #128817] [BUG] Num.perl doesn't round-trip numeric value
On Tue, 02 Aug 2016 09:51:31 -0700, zef...@fysh.org wrote: > > (1180591620717411303424.0e0).Int > 1180591620717411303424 > > (1180591620717411303424.0e0).perl.EVAL.Int > 1180591620717409992704 > > The .perl.EVAL process ought to yield the same value we started with. > It's coming back as a different Num value. > > -zefram Thank you for the report. This is now fixed. Fix: https://github.com/MoarVM/MoarVM/commit/067c0594103a025 https://github.com/MoarVM/MoarVM/commit/8841c4241b4faa8 https://github.com/MoarVM/MoarVM/commit/af2eb8a7f7d4344 https://github.com/MoarVM/MoarVM/commit/4d3fc2818d0032b https://github.com/rakudo/rakudo/commit/8422d7b4e23678b https://github.com/rakudo/rakudo/commit/a2a2a745c4242d1 https://github.com/rakudo/rakudo/commit/430266629f2e2a0 Test: https://github.com/perl6/roast/commit/dcdbcb31b43a0f6ec
Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
Additional: the same problem arises with Complex.perl, where the real or imaginary parts suffer this problem as Nums. Fixing this for Num won't automatically fix it for Complex, because Complex.perl doesn't invoke Num.perl. -zefram
Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
On Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote: > Patrick R. Michaud via RT wrote: > >I don't know that we should expect .perl or any other operation on Num > >values to be preserving more precision than that. > > I'd expect .perl to preserve whatever precision is there. Accurately > representing the value, in a form understandable by .EVAL, is its > raison d'etre. > [...] Okay. I'm agreeable to say that .perl (and perhaps sprintf where appropriate) should add two more digits of precision to the strings they produce, to preserve the round-trippiness of the values being represented. > (1180591620717411303424e0).perl 1.18059162071741e+21 > (1.18059162071741e+21).Int # not enough precision 1180591620717409992704 > (1.180591620717411e+21).Int# still not enough 1180591620717411041280 > (1.1805916207174113e+21).Int # okay, this works 1180591620717411303424 Pm
Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value
Patrick R. Michaud via RT wrote: >I don't know that we should expect .perl or any other operation on Num >values to be preserving more precision than that. I'd expect .perl to preserve whatever precision is there. Accurately representing the value, in a form understandable by .EVAL, is its raison d'etre. The value I'm using in this example is 2**70, a very round number that is easily represented in floating point. If the lengthy decimal representation is putting you off, consider > (2e0**70).perl.EVAL == 2e0**70 False >> (1180591620717411303424.0e0 + 1.0 ).Int >1180591620717411303424 >> (1180591620717411303424.0e0 + 10 ).Int >1180591620717411303424 These are as expected: floating point rounding applies, and the results obtained are the closest representable values to the mathematically correct result. This is a red herring. My example doesn't invoke any operation requiring rounding. The initial decimal literal has the exact representable value, which gets represented correctly as a Num. I don't then perform any arithmetic on it. -zefram
[perl #128817] [BUG] Num.perl doesn't round-trip numeric value
# New Ticket Created by Zefram # Please include the string: [perl #128817] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128817 > > (1180591620717411303424.0e0).Int 1180591620717411303424 > (1180591620717411303424.0e0).perl.EVAL.Int 1180591620717409992704 The .perl.EVAL process ought to yield the same value we started with. It's coming back as a different Num value. -zefram
