[Python-Dev] Mixing float and Decimal -- thread reboot

Mark Dickinson dickinsm at gmail.com
Wed Mar 24 10:51:36 CET 2010


On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Steven D'Aprano writes:
>
>  > As usual though, NANs are unintuitive:
>  >
>  > >>> d = {float('nan'): 1}
>  > >>> d[float('nan')] = 2
>  > >>> d
>  > {nan: 1, nan: 2}
>  >
>  >
>  > I suspect that's a feature, not a bug.

Right:  distinct nans (i.e., those with different id()) are treated as
distinct set elements or dict keys.

> I don't see how it can be so.  Aren't all of those entries garbage?
> To compute a histogram of results for computations on a series of
> cases would you not have to test each result for NaN-hood, then hash
> on a proxy such as the string "Nan"?

So what alternative behaviour would you suggest, and how would you implement it?

I agree that many aspects of the current treatment of nans aren't
ideal, but I as far as I can see that's unavoidable.  For sane
containment testing, Python's == operator needs to give an equivalence
relation.  Meanwhile IEEE 754 requires that nans compare unequal to
themselves, breaking reflexivity.  So there have to be some
compromises somewhere.

The current compromise at least has the virtue that it doesn't require
special-casing nans anywhere in the general containment-testing and
hashing machinery.

One alternative would be to prohibit putting nans into sets and dicts
by making them unhashable;  I'm not sure what that would gain, though.
 And there would still be some unintuitive behaviour for containment
testing of nans in lists.

Mark


More information about the Python-Dev mailing list