Skip to content
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

-0e0 === 0e0 in Rakudo #4254

Closed
p6rt opened this issue May 18, 2015 · 5 comments
Closed

-0e0 === 0e0 in Rakudo #4254

p6rt opened this issue May 18, 2015 · 5 comments
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented May 18, 2015

Migrated from rt.perl.org#125216 (status was 'resolved')

Searchable as RT125216$

@p6rt
Copy link
Author

@p6rt p6rt commented May 18, 2015

From @masak

<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

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 20, 2015

From @nwc10

On Mon, May 18, 2015 at 11​:18​:59AM -0700, Carl Mäsak wrote​:

<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?

<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

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 20, 2015

The RT System itself - Status changed from 'new' to 'open'

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 19, 2016

From @zoffixznet

On Mon, 18 May 2015 11​:18​:59 -0700, masak wrote​:

<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-archive.perl.org/perl6/Ticket/Display.html?id=128395

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 19, 2016

@zoffixznet - Status changed from 'open' to 'resolved'

Loading

@p6rt p6rt closed this Dec 19, 2016
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant