float("nan") in set or as key

[Chris Angelico]

On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence at gmail.com> wrote:
> I think you misunderstood what I was saying.
>
> It's not *possible* to represent a real number abstractly in any digital computer.  Python couldn't have an "abstract real number" type even it wanted to.

True, but why should the "non-integer number" type be floating point
rather than (say) rational? Actually, IEEE floating point could mostly
be implemented in a two-int rationals system (where the 'int' is
arbitrary precision, so it'd be Python 2's 'long' rather than its
'int'); in a sense, the mantissa is the numerator, and the scale
defines the denominator (which will always be a power of 2). Yes,
there are very good reasons for going with the current system. But are
those reasons part of the details of implementation, or are they part
of the definition of the data type?

> (Math aside: Real numbers are not countable, meaning they cannot be put into one-to-one correspondence with integers.  A digital computer can only represent countable things exactly, for obvious reasons; therefore, to model non-countable things like real numbers, one must use a countable approximation like floating-point.)

Right. Obviously a true 'real number' representation can't be done.
But there are multiple plausible approximations thereof (the best
being rationals).

Not asking for Python to be changed, just wondering why it's defined
by what looks like an implementation detail. It's like defining that a
'character' is an 8-bit number using the ASCII system, which then
becomes problematic with Unicode. (Ohai, C, didn't notice you standing
there.)

Chris Angelico