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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4