On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
> On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
<step...@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"?
Not necessarily -- you could merely ignore any key which is a NaN, or
you could pass each key through this first:
def intern_nan(x, nan=float('nan')):
if math.isnan(x): return nan
return x
thus ensuring that all NaN keys were the same NaN.
> So what alternative behaviour would you suggest, and how would you
> implement it?
[...]
> 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.
I think that would be worse than the current situation. That would mean
that dict[some_float] would *nearly always* succeed, but occasionally
would fail. I can't see that being a good thing.
--
Steven D'Aprano
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
