[Python-Dev] Python's C interface for types

[Nick Maclaren]

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