New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Num.perl doesn't round-trip numeric value #5518
Comments
From zefram@fysh.org
The .perl.EVAL process ought to yield the same value we started with. -zefram |
From @pmichaudOn Tue Aug 02 09:51:31 2016, zefram@fysh.org wrote:
Double-precision floating point (which is essentially what "e0" does) generally has only 15-17 digits of decimal precision. I don't know that we should expect .perl or any other operation on Num values to be preserving more precision than that. > (1180591620717411303424.0e0+0).perl In particular, note that the following produce results that are mathematically incorrect but are still within the expected range of behavior for floating-point (Num) values: > (1180591620717411303424.0e0 + 1.0 ).Int Pm |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgPatrick R. Michaud via RT wrote:
I'd expect .perl to preserve whatever precision is there. Accurately The value I'm using in this example is 2**70, a very round number
These are as expected: floating point rounding applies, and the results -zefram |
From @pmichaudOn Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote:
Okay. I'm agreeable to say that .perl (and perhaps sprintf where
Pm |
From zefram@fysh.orgAdditional: the same problem arises with Complex.perl, where the real -zefram |
From @zoffixznetOn Tue, 02 Aug 2016 09:51:31 -0700, zefram@fysh.org wrote:
Thank you for the report. This is now fixed. Fix: MoarVM/MoarVM@067c0594103a025 |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128817 (status was 'resolved')
Searchable as RT128817$
The text was updated successfully, but these errors were encountered: