Skip Menu |
Report information
Id: 125216
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] -0e0 === 0e0 in Rakudo
From: Carl Mäsak <cmasak [...] gmail.com>
Date: Mon, 18 May 2015 20:18:45 +0200
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
<AlexDaniel> m: say -1/Inf; <camelia> rakudo-moar 3fc98b: OUTPUT«-0␤» <AlexDaniel> -0? <masak> sure! <masak> -0 is a totally cromulent IEEE 754 number. * FROGGS .oO( why so negative? ) <masak> m: say -0e0 < 0e0 <camelia> rakudo-moar 3fc98b: OUTPUT«False␤» <masak> m: say -0e0 == 0e0 <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» (everything kosher up until this point) <masak> m: say -0e0 === 0e0 <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» <masak> one could argue that that last one should be False... :) <masak> m: say -0e0 <camelia> rakudo-moar 3fc98b: OUTPUT«-0␤» <masak> yeah, this is not how I'd expect === to behave. <masak> it should be more discriminating than == <masak> and be able to pick out that those are actually two distinct values (that happen to be numerically equal) <AlexDaniel> masak: and what's the difference between -0e1 and -1/Inf ? <masak> nothing, IMO. they're the exact same value. <AlexDaniel> masak: but then why did you say "this is not how I'd expect === to behave"? <masak> m: say -0e0 === 0e0 <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» <masak> because of that. <AlexDaniel> oh ok <AlexDaniel> got it <masak> I'm fine with them being numerically equals (because they're the same point on the real line) <masak> but I'd expect === to be able to pick them apart, because === is not encumbered with notions of number-ness <masak> now I'm going to submit this and make it look like I wrote all the right things from the start :P <TimToady> eqv and === on floaters should probably just compare chunks of memory
Subject: Re: [perl #125216] [BUG] -0e0 === 0e0 in Rakudo
To: perl6-compiler [...] perl.org
From: Nicholas Clark <nick [...] ccl4.org>
Date: Wed, 20 May 2015 18:48:21 +0100
Download (untitled) / with headers
text/plain 1.2k
On Mon, May 18, 2015 at 11:18:59AM -0700, Carl Mäsak wrote: Show quoted text
> <masak> I'm fine with them being numerically equals (because they're > the same point on the real line)
I agree with the "numerically equal", and for the reasoning, but strictly are you using the right terms here? Specifically, are floating point numbers "real numbers"? Or are they some sort of well specified approximation to real numbers? Show quoted text
> <masak> but I'd expect === to be able to pick them apart, because === > is not encumbered with notions of number-ness > <masak> now I'm going to submit this and make it look like I wrote all > the right things from the start :P > <TimToady> eqv and === on floaters should probably just compare chunks of memory
Beware - in Perl 5 land there has been fun because if the C ABI ends up allocating more space than the float needs (eg 80 bit IEEE floats in 12 or 16 bytes) then the C compiler isn't always consistent in what it puts in the madding. I think it's been biting for newer gcc (or was it g++) for some things (probably long doubles, but I'm not certain here), and tests with pack that were assuming bitwise perfection. So probably it should be memory comparison on the meat, carefully avoiding the padding. Nicholas Clark
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Mon, 18 May 2015 11:18:59 -0700, masak wrote: Show quoted text
> <AlexDaniel> m: say -1/Inf; > <camelia> rakudo-moar 3fc98b: OUTPUT«-0␤» > <AlexDaniel> -0? > <masak> sure! > <masak> -0 is a totally cromulent IEEE 754 number. > * FROGGS .oO( why so negative? ) > <masak> m: say -0e0 < 0e0 > <camelia> rakudo-moar 3fc98b: OUTPUT«False␤» > <masak> m: say -0e0 == 0e0 > <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» > > (everything kosher up until this point) > > <masak> m: say -0e0 === 0e0 > <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» > <masak> one could argue that that last one should be False... :) > <masak> m: say -0e0 > <camelia> rakudo-moar 3fc98b: OUTPUT«-0␤» > <masak> yeah, this is not how I'd expect === to behave. > <masak> it should be more discriminating than == > <masak> and be able to pick out that those are actually two distinct > values (that happen to be numerically equal) > <AlexDaniel> masak: and what's the difference between -0e1 and -1/Inf > ? > <masak> nothing, IMO. they're the exact same value. > <AlexDaniel> masak: but then why did you say "this is not how I'd > expect === to behave"? > <masak> m: say -0e0 === 0e0 > <camelia> rakudo-moar 3fc98b: OUTPUT«True␤» > <masak> because of that. > <AlexDaniel> oh ok > <AlexDaniel> got it > <masak> I'm fine with them being numerically equals (because they're > the same point on the real line) > <masak> but I'd expect === to be able to pick them apart, because === > is not encumbered with notions of number-ness > <masak> now I'm going to submit this and make it look like I wrote all > the right things from the start :P > <TimToady> eqv and === on floaters should probably just compare chunks > of memory
This has already been fixed and tested as part of a dupe RT#128395: https://rt.perl.org/Ticket/Display.html?id=128395


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org