Hacker News Reader

Comment by dlubarov | Hacker News Reader

> 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.

View on HN

Exceptions are utterly painful for vectorized operations. Goodbye Tensorflow if you say goodbye to NaNs

That'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"?

my 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.

I'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.

The JS behavior regarding 1/0, etc, is the same as C: http://www.gnu.org/software/libc/manual/html_node/Infinity-a...

Yes, but the issue comes up more often in JS and PHP since they don't have native integer division.

> 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.

> 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.

They 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.

> 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.

Reply on news.ycombinator.com