"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4