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
decimal->float conversion differs for literals and Str.Num #5565
Comments
From zefram@fysh.org
Observe that the same string yields different Num values when interpreted The conversions yielding different values implies that at least one -zefram |
From @zoffixznetOn Fri, 12 Aug 2016 10:24:48 -0700, zefram@fysh.org wrote:
While OP's code snippet now shows there's no difference any more, it <Zoffix__> m: dd [ "9.998999999999999e0".EVAL, "9.998999999999999e0".Num] A quick print out with C shows both values should be: <Zoffix__> m: say 9.9989999999999988 And looks like our new approach of using nqp::div_In for coercion, literal parsing, <Zoffix__> m: dd 9.9989999999999991e0 == 9.998999999999999e0 after parsing eventually essentially becomes this: <Zoffix__> r: use nqp; dd nqp::div_In(99989999999999991, 100_000_000_000_000_000) == nqp::div_In(9998999999999999, 10_000_000_000_000_000) And it gives False, but in C, those two numbers are equal: $ ccc 'printf("%d\n", 9.9989999999999991e0 == 9.998999999999999e0)' |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetOn Fri, 12 Aug 2016 10:24:48 -0700, zefram@fysh.org wrote:
Thank you for the report. This is now fixed. Fix: rakudo/rakudo@a760ac3cfc6426d9bd2fb00db |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128914 (status was 'resolved')
Searchable as RT128914$
The text was updated successfully, but these errors were encountered: