[Python-Dev] Python's C interface for types (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Feb 1 20:36:24 CET 2007

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:

> 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 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list