On Fri, 12 Aug 2016 10:24:48 -0700, [email protected] wrote:
> > "9.998999999999999e0".EVAL - "9.998999999999999e0".Num
> 1.77635683940025e-15
>
> Observe that the same string yields different Num values when interpreted
> as a Num literal and when coerced. Where the string is meaningful both
> ways, this is a bug. Obviously there are some situations where the
> syntax of Perl 6 literals doesn't exactly match what one would expect of
> a Str.Num conversion, but that's not the case here. Where the syntax
> matches, as it does in this case, or more generally where the same
> digits are presented with the same weights, one would expect the core
> decimal->float conversion to behave the same for both.
>
> The conversions yielding different values implies that at least one
> of them is individually incorrect. In this case, the coercion yields
> the correctly-rounded value, and the literal is getting it wrong.
> [perl #128912] is concerned with these conversions being incorrect per se,
> and my test case there used the conversion for literals. The difference
> between the two forms of decimal->float conversion is not merely a matter
> of literals getting it wrong and coercion getting it right: there are also
> cases where the coercion gets it wrong. In fact, coercion gets it wrong
> in the [perl #128912] test case: both literal interpretation and coercion
> get "9.999e-5" wrong in the same way. I have not yet encountered a case
> where literal interpretation gets it right and coercion gets it wrong,
> but nor can I say that there isn't such a case.
>
> -zefram
While OP's code snippet now shows there's no difference any more, it
appears that the reason is because both literal and coercion give wrong values
now:
<Zoffix__> m: dd [ "9.998999999999999e0".EVAL, "9.998999999999999e0".Num]
<camelia> rakudo-moar f48636011: OUTPUT: «[9.999e0, 9.999e0]»
A quick print out with C shows both values should be:
<Zoffix__> m: say 9.9989999999999988
<camelia> rakudo-moar f48636011: OUTPUT: «9.9989999999999988»
And looks like our new approach of using nqp::div_In for coercion, literal
parsing,
and Rat->Num degradation might be flawed (or there's a bug in that op), as this:
<Zoffix__> m: dd 9.9989999999999991e0 == 9.998999999999999e0
<camelia> rakudo-moar f48636011: OUTPUT: «Bool::False»
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)
<camelia> rakudo-jvm a92950fb4, rakudo-moar f48636011: OUTPUT:
«Bool::False»
And it gives False, but in C, those two numbers are equal:
$ ccc 'printf("%d\n", 9.9989999999999991e0 == 9.998999999999999e0)'
1
