[Python-Dev] Mixing float and Decimal -- thread reboot (original) (raw)

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