=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
