Re: [Python-Dev] Python's C interface for types
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
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().
Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'.
from decimal import * x = Decimal("NaN") x == x False
I don't know any CURRENT systems where basic floating-point doesn't have the strict transitive relation, but I wouldn't bet that there aren't any. You don't need to extend floating-point to have trouble; even the basic forms often had it. I sincerely hope that one is dead, but people keep reinventing old mistakes :-( The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure.
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".
Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea? We already have the situation where A == B == 0, but where 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in operator and where 'C op' is a standard library function. This one is NOT going to go away, and is going to get more serious, especially if extended floating-point formats like Decimal take off. Note that it is not a fault in Decimal, but a feature of almost all extended floating-points. As I said, I have no answer to it. 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().
Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people?
Why should I? I don't talk about IEEE 754, I talk about Python.
Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'.
I deliberately stated 'transitive', not 'reflexive'. The standard definition of 'transitive' is "if a==b and b==c then a==c".
The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure.
I'm not talking about subtraction, either. I'm talking about == and hash.
Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea?
I'm not explaining anything. I'm stating an opinion.
This one is NOT going to go away, and is going to get more serious, especially if extended floating-point formats like Decimal take off. Note that it is not a fault in Decimal, but a feature of almost all extended floating-points. As I said, I have no answer to it.
It doesn't look like you *need* to give an answer now. I thought you were proposing some change to Python (although I'm uncertain what that change could have been). If you are merely explaining things (to whom?), just keep going. Regards, Martin
participants (2)
-
"Martin v. Löwis" -
Nick Maclaren