float("nan") in set or as key

[OKB (not okblacke)]

Carl Banks wrote:

> On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks  wrote:
>> > I think you misunderstood what I was saying.
>> >
>> > It's not *possible* to represent a real number abstractly in any
>> > digita 
> l 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? 
> 
> Python has several non-integer number types in the standard
> library.  The one we are talking about is called float.  If the
> type we were talking about had instead been called real, then your
> question might make some sense.  But the fact that it's called
> float really does imply that that underlying representation is
> floating point. 

    	That's true, but that's sort of putting the cart before the horse.  
In response to that, one can just ask: why is this type called "float"?  
Why is it that when I type 1.37 or sqrt(2) in my program, the resulting 
object is a "float" rather than some other numeric type?  I'm aware 
that there are answers to this having to do with standardization and 
efficiency.  But I do sometimes wish that the "default" type for non-
integers (as created through Python expressions) was something more like 
"rationals with a denominator no bigger than N".

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown