4 ms·
> An exception is the same NaN, only less convenientlying packaged. I prefer an exception because I'd rather have my code fail fast, and immediately point me c
by dlubarov 10y ago
> An exception is the same NaN, only less convenientlying packaged.
I prefer an exception because I'd rather have my code fail fast, and immediately point me close to the source of the bug, rather than letting a NaN or Infinity propagate through my code base and cause some harder-to-debug problems down the line.
That's the main thing I don't like about JavaScript. 1/0 is Infinity, Math.acos(2) is NaN, Object().foo is undefined, etc. I find myself wasting a lot of debugging time just figuring out where those (usually expected) values came from originally.
- mcav 10y agoThe JS behavior regarding 1/0, etc, is the same as C: http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html http://www.gnu.org/software/libc/manual/html_node/Infinity-a...
- dlubarov 10y agoYes, but the issue comes up more often in JS and PHP since they don't have native integer division.
- dbcurtis 10y agoExceptions are utterly painful for vectorized operations. Goodbye Tensorflow if you say goodbye to NaNs
- greglindahl 10y agoThat's an excellent explanation for why scientific computing has been using vectors for a long time and has traditionally faulted when hitting the first NaN. Is there something about Tensorflow that makes propagating NaNs useful? And if so, why are you generalizing from Tensorflow to all "vectorized operations"?
- rtpg 10y agomy guess is that this is a performance argument. If you don't have to check the results, your circuits to do huge vector calculations can be simpler.
- golergka 10y ago> I'd rather have my code fail fast Doesn't it depend on the product in question? In some cases, you want to fail fast and loud. In others, you want to recover at all costs. Sometimes a single calculation going 1/0 means the whole program is failing. Sometimes it's a completely ignorable, minor error, not even worth checking for. Can we please not have a "default" way of handling errors? None fit all.
- dlubarov 10y ago> Can we please not have a "default" way of handling errors? None fit all. Well language designers have to make the choice. I think overall, the best approach is Python's behavior, where both 1/0 and 1.0/0.0 trigger a ZeroDivisionError.
- detaro 10y agoThey could give options. E.g. have a "throwing float" and a "NaN float" as distinct data types, or some other way to parametrize the behaviour. Is that a good idea? I don't know.
- golergka 10y ago> Well language designers have to make the choice. Of course. I meant, no "default" that we would consider the "right way" for all the languages.
- mschuetz 10y agoI'm in favour of 1.0 / 0.0 = Infinity, as in the current IEEE floating point standard. It makes much more sense with many algorithms. Checking whether the denominator is 0 or not costs time and unnecessarely bloats the code.