float("nan") in set or as key

[Chris Angelico]

On Wed, Jun 1, 2011 at 11:44 PM, Jerry Hill <malaclypse2 at gmail.com> wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence at gmail.com> wrote:
>> True, but why should the "non-integer number" type be floating point
>> rather than (say) rational?

Careful with the attributions, Carl was quoting me when he posted that :)

> You seem to be implying that python only provides a single non-integer
> numeric type.  That's not true.  Python ships with a bunch of
> different numeric types, including a rational type.  Off the top of my
> head, we have:
>
> IEEE floating point numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex)
> Rationals (http://docs.python.org/library/fractions.html)
> Base-10 fixed and floating point numbers
> (http://docs.python.org/library/decimal.html)
> Complex numbers
> (http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
> plus http://docs.python.org/library/cmath.html)
> Integers (both ints and longs, which are pretty well unified by now)

I know Python does support all of the above. Leave off int/long and
complex, which are obviously not trying to store real numbers
(although I guess you could conceivably make 'complex' the vehicle for
reals too), there's three: float, fraction, decimal. Of them, one is a
built-in type and the other two are imported modules. Hence my
question about why this one and not that one should be the "default"
that people will naturally turn to as soon as they need non-integers.
(Or, phrasing it another way: Only one of them is the type that "3.2"
in your source code will be represented as.)

> Floats have far and away the best performance in most common
> situations, so they end up being the default, but if you want to use
> something different, it's usually not hard to do.

And that, right there, is the answer.

ChrisA