[Python-Dev] Weekly Python Bug/Patch Summary

[Michael Hudson]

"Tim Peters" <tim.one at comcast.net> writes:

> [Michael Hudson]
>> Would it make (more) sense to implement rich comparisons for floats?
>
> Not much.

But a little bit?  It might at least make the results closer to what
the underlying C compiler does (modulo bugs in same, of course).

> There are 32 distinct theoretical binary comparison operators under
> 754 semantics (16 for which subset of {<, =, >, unordered} you're
> interested in, and then each of those comes in two flavors depending
> on whether you want a signaling NaN comparand to, or not to, raise
> an exception), and the standard "recommends" implementing something
> like 26 of them.

Well, we don't want an SNaN to S, Python has no concept of unordered.
That's down to 8.  We don't care about the improper subsets of {<,
=, >}.  That's 6.  Rich comparisons.

>> I'm not enthusiastic about the patch that got pasted into the bug
>> report.
>
> That's dead on arrival -- apart from the dubious semantics it's trying to
> invent, it doesn't even work under MSVC 6 (which I've explained in the bug
> report).  There's no reliable cross-platform C support for any of this
> stuff, therefore there's nothing Python can do about 754 oddballs without
> masses of platform-specific code (see fpectlmodule.c for a taste of that
> approach).

I realise it's a game of "pick your surprise", but the case mentioned
in the bug report is particularly, well, surprising.

Cheers,
mwh

-- 
  "Also, does the simple algorithm you used in Cyclops have a name?"
  "Not officially, but it answers to "hey, dumb-ass!"
                       -- Neil Schemenauer and Tim Peters, 23 Feb 2001