"Jim Jewett"
For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0
Unfortunately, that assumes that equality is transitive.
No, but the (transitively closed set of equivalent objects) must have the same hash. ...
Er, how do you have a transitive closure for a non-transitive operation? I really do mean that quite a lot of floating-point bells and whistles are non-transitive. The only one most people will have come across is IEEE NaNs, where 'a is b' does not imply 'a == b', but there are a lot of others (and have been since time immemorial). I don't THINK that IEEE 754R decimal introduces any, though I am not prepared to bet on it.
let us say that I am implementing a special function and want to distinguish -0.0 and +0.0. Why can't I use a dictionary?
Because they are equal. They aren't identical, but they are equal.
You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed.
a = float("+0.0") b = float("-0.0") print a, b 0.0 -0.0
With the standard windows distribution, I get just
0.0 0.0
Watch that space :-) Expect it to change. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679
Nick Maclaren schrieb:
For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0 Unfortunately, that assumes that equality is transitive. No, but the (transitively closed set of equivalent objects) must have the same hash. ...
Er, how do you have a transitive closure for a non-transitive operation?
I really do mean that quite a lot of floating-point bells and whistles are non-transitive.
If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has().
You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed.
If introducing extended floating-points would cause trouble to existing operations, I think extended floating-points should not be introduced to Python. If all three of you really need them, come up with method names to express "almost equal" or "equal only after sunset". Regards, Martin
participants (2)
-
"Martin v. Löwis"
-
Nick Maclaren