On Tue, Jul 8, 2014 at 5:53 PM, Stephen J. Turnbull <step...@xemacs.org> wrote: > But you're missing at least two alternatives that > involve raising on some calculations involving NaN, as well as the > fact that forcing inequality of two NaNs produced by equivalent > calculations is arguably just as wrong as allowing equality of two > NaNs produced by the different calculations.
This is off-topic for this thread, but still... The trouble is that your "arguably just as wrong" is an indistinguishable case. If you don't want two different calculations' NaNs to *ever* compare equal, the only solution is to have all NaNs compare unequal - otherwise, two calculations might happen to produce the same bitpattern, as there are only a finite number of them available. > That's where things get > fuzzy for me -- in Python I would expect that preserving invariants > would be more important than computational efficiency, but evidently > it's not. What invariant is being violated for efficiency? As I see it, it's one possible invariant (things should be equal to themselves) coming up against another possible invariant (one way of generating NaN is unequal to any other way of generating NaN). Raising an exception is, of course, the purpose of signalling NaNs rather than quiet NaNs, which is a separate consideration from how they compare. ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
