float("nan") in set or as key
Ben Finney
ben+python at benfinney.id.au
Wed Jun 1 01:18:40 EDT 2011
Chris Angelico <rosuav at gmail.com> writes:
> Right. Obviously a true 'real number' representation can't be done.
> But there are multiple plausible approximations thereof (the best
> being rationals).
Sure. But most of those are not what is most commonly meant by ‘float’
type.
> Not asking for Python to be changed, just wondering why it's defined
> by what looks like an implementation detail.
Because, in the case of the ‘float’ type, the agreed-upon meaning of
that type – in Python as in just about every other language that is
well-specified – is “an IEEE float as per the IEEE 754 spec”.
A foolish consistency to the spec would be a hobgoblin for little minds.
But, given that a ‘float’ type which deviated from that spec would just
be inviting all sorts of other confusion, it's not a foolish
consistency.
> It's like defining that a 'character' is an 8-bit number using the
> ASCII system, which then becomes problematic with Unicode.
Right. That's why in Python 3 the Unicode text type is called ‘unicode’,
the IEEE float type is called ‘float’, and the byte string type is
called ‘bytes’.
It's also why the ‘str’ type in Python 2 was painful enough to need
changing: it didn't clearly stick to a specification, but tried to
straddle the worlds between one specification (a text type) and an
incompatible other specification (a bytes sequence type).
Where there is a clearly-defined widely-agreed specification for a type,
it's a good idea to stick to that specification when claiming to
implement that functionality in a type.
--
\ “The man who is denied the opportunity of taking decisions of |
`\ importance begins to regard as important the decisions he is |
_o__) allowed to take.” —C. Northcote Parkinson |
Ben Finney
More information about the Python-list
mailing list