On 26 Mar 2010, at 18:40 , Casey Duncan wrote: > > > On Mar 25, 2010, at 7:19 PM, P.J. Eby wrote: > >> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote: >>> But they're not -- they're *signals* for "your calculation has gone screwy >>> and the result you get is garbage", so to speak. You shouldn't even think >>> of a specific NAN as a piece of specific garbage, but merely a label on the >>> *kind* of garbage you've got (the payload): INF-INF is, in some sense, a >>> different kind of error to log(-1). In the same way you might say "INF-INF >>> could be any number at all, therefore we return NAN", you might say "since >>> INF-INF could be anything, there's no reason to think that INF-INF == >>> INF-INF." >> >> So, are you suggesting that maybe the Pythonic thing to do in that case >> would be to cause any operation on a NAN (including perhaps comparison) to >> fail, rather than allowing garbage to silently propagate? >> >> In other words, if NAN is only a signal that you have garbage, is there >> really any reason to keep it as an *object*, instead of simply raising an >> exception? Then, you could at least identify what calculation created the >> garbage, instead of it percolating up through other calculations. >> >> In low-level languages like C or Fortran, it obviously makes sense to >> represent NAN as a value, because there's no other way to represent it. But >> in a language with exceptions, is there a use case for it existing as a >> value? > > If a NaN object is allowed to exist, that is a float operation that does not > return a real number does not itself raise an exception immediately, then it > will always be possible to get (seemingly) nonsensical behavior when it is > used in containers that do not themselves "operate" on their elements. How about raising an exception instead of creating nans in the first place, except maybe within specific contexts (so that the IEEE-754 minded can get their nans working as they currently do)?
That way, there cannot be any nan-induced seemingly nonsensical behavior except within known scopes. _______________________________________________ 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
