"Jim Jewett" <jimjjewett@gmail.com> wrote:
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.
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.
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:
If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has().
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
Nick Maclaren schrieb:
If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has().
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