Re: [perl #128820] [BUG] == on Num literals produces bogus answer [Request: ET-9759 is created]
Thank you for your email request. Your request ID is I-1544215 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
Re: [perl #128820] [BUG] == on Num literals produces bogus answer [Request: ET-9760 is created]
Thank you for your email request. Your request ID is I-1544216 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 #128820] [BUG] == on Num literals produces bogus answer
On Tue, 02 Aug 2016 10:55:34 -0700, zef...@fysh.org wrote:
> > 1180591620717411303424e0 == 1180591620717409992704e0
> True
> > 1180591620717411303424e0 === 1180591620717409992704e0
> True
>
> Say what? These are distinct Num values, differing by 10 ulp.
> These literals work fine in other contexts:
>
> > my $a = 1180591620717411303424e0
> 1.18059162071741e+21
> > my $b = 1180591620717409992704e0
> 1.18059162071741e+21
> > $a.Int
> 1180591620717411303424
> > $b.Int
> 1180591620717409992704
> > $a == $b
> False
> > $a === $b
> False
>
> == and === give the right result when applied to $a and $b as here, or
> when applied to declared constants ("constant \A = 118..."). They also
> work fine when comparing a variable against a literal. They go wrong when
> applied directly to two literal expressions. They also go wrong with some
> more complex expressions that bring in both values as literals, such as if
> both sides are multiplied by 1.0e0 or by a variable containing that 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
Test: https://github.com/perl6/roast/commit/52c60ce5c283dd5b8
https://github.com/perl6/roast/commit/bba5e9fdda431c9f4
[perl #128820] [BUG] == on Num literals produces bogus answer
On Tue, 02 Aug 2016 10:55:34 -0700, zef...@fysh.org wrote:
> > 1180591620717411303424e0 == 1180591620717409992704e0
> True
> > 1180591620717411303424e0 === 1180591620717409992704e0
> True
>
> Say what? These are distinct Num values, differing by 10 ulp.
> These literals work fine in other contexts:
>
> > my $a = 1180591620717411303424e0
> 1.18059162071741e+21
> > my $b = 1180591620717409992704e0
> 1.18059162071741e+21
> > $a.Int
> 1180591620717411303424
> > $b.Int
> 1180591620717409992704
> > $a == $b
> False
> > $a === $b
> False
>
> == and === give the right result when applied to $a and $b as here, or
> when applied to declared constants ("constant \A = 118..."). They also
> work fine when comparing a variable against a literal. They go wrong when
> applied directly to two literal expressions. They also go wrong with some
> more complex expressions that bring in both values as literals, such as if
> both sides are multiplied by 1.0e0 or by a variable containing that 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
Test: https://github.com/perl6/roast/commit/52c60ce5c283dd5b8
https://github.com/perl6/roast/commit/bba5e9fdda431c9f4
Re: [perl #128820] [BUG] == on Num literals produces bogus answer
Additional: this also happens with Complex literals, where the real or imaginary parts suffer this as Nums. -zefram
Re: [perl #128820] [BUG] == on Num literals produces bogus answer
Patrick R. Michaud via RT wrote:
>It's not universally true that Num literals like these "work fine
>in other contexts" -- the pair of literals in the example given "work"
>because they differ in the fifteenth decimal digit of precision.
Once again, you're mistakenly supposing my complaint to be from a
decimal point of view and the problem explained by rounding in the
decimal->float conversion. This is not the case. Both of my literals
directly represent values that are exactly representable in floating
point, and in most contexts they correctly yield Nums with those values.
>In short, it's "normal" (expected behavior) for mathematical errors to
>occur beyond 15 digits of precision in Num (floating point) values.
It is not normal for the same literal to represent two different values
when used twice. The decimal->float rounding doesn't account for this.
More information: upon further experimentation, it seems that the critical
issue is whether the two literals are compiled together. Any expression
containing both literals has them actually yield the same value, and
it's the proper value of whichever literal came first:
> (1180591620717411303424e0, 1180591620717409992704e0).map(*.Int)
(1180591620717411303424 1180591620717411303424)
> (1180591620717409992704e0, 1180591620717411303424e0).map(*.Int)
(1180591620717409992704 1180591620717409992704)
> ("1180591620717411303424e0", "1180591620717409992704e0").map(*.EVAL.Int)
(1180591620717411303424 1180591620717409992704)
Perhaps the compiler is coalescing the constants based on them having
identical .WHICH values, for which see [perl #128819]. The expression
"2e0**70" doesn't get the same treatment, so the coalescing can't be
happening after constant folding, if that gets folded.
-zefram
Re: [perl #128820] [BUG] == on Num literals produces bogus answer
On Tue, Aug 02, 2016 at 10:55:34AM -0700, Zefram wrote: > These literals work fine in other contexts: > > > my $a = 1180591620717411303424e0 > 1.18059162071741e+21 > > my $b = 1180591620717409992704e0 > 1.18059162071741e+21 > > $a.Int > 1180591620717411303424 > > $b.Int > 1180591620717409992704 > > $a == $b > False > > $a === $b > False It's not universally true that Num literals like these "work fine in other contexts" -- the pair of literals in the example given "work" because they differ in the fifteenth decimal digit of precision. This is within the acceptable norms for Num (floating point) precision. Choosing a different pair of literal values that differ beyond the first 15 digits of precision shows that things do not work fine in other contexts: > my $a = 1180591620717411303424e0 1.18059162071741e+21 > my $b = 118059162071741133e0 1.18059162071741e+21 > $a.Int 1180591620717411303424 > $b.Int 1180591620717411303424 > $a == $b True > $a === $b True In short, it's "normal" (expected behavior) for mathematical errors to occur beyond 15 digits of precision in Num (floating point) values. Pm
[perl #128820] [BUG] == on Num literals produces bogus answer
# New Ticket Created by Zefram
# Please include the string: [perl #128820]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128820 >
> 1180591620717411303424e0 == 1180591620717409992704e0
True
> 1180591620717411303424e0 === 1180591620717409992704e0
True
Say what? These are distinct Num values, differing by 10 ulp.
These literals work fine in other contexts:
> my $a = 1180591620717411303424e0
1.18059162071741e+21
> my $b = 1180591620717409992704e0
1.18059162071741e+21
> $a.Int
1180591620717411303424
> $b.Int
1180591620717409992704
> $a == $b
False
> $a === $b
False
== and === give the right result when applied to $a and $b as here, or
when applied to declared constants ("constant \A = 118..."). They also
work fine when comparing a variable against a literal. They go wrong when
applied directly to two literal expressions. They also go wrong with some
more complex expressions that bring in both values as literals, such as if
both sides are multiplied by 1.0e0 or by a variable containing that value.
-zefram
