Hacker News Reader

Comment by nine_k | Hacker News Reader

If NaN is nonsense, what would you have 1/0 or acos(2) to produce? (An exception is the same NaN, only less convenientlying packaged.)

View on HN

Ideally I would restrict all functions to their natural domain using refinement types. This ways 1/0 simply doesn't type check and you don't have to bother assigning it some nonsensical value. However I can see something like this becoming much more a hassle than a benefit when things get complicated enough.

I'm not very familiar with refinement types. How would that work?

For example, how would you write a function that answers the mean value of an array of numbers? You could define Array.Length to be of type NonNegativeInteger, but that still includes 0. Alternatively, you'd have to define a NonEmptyArray type that excludes arrays of length 0, but that seems less than useful.

Yes, that's exactly how it works. See this article for an example: http://nikita-volkov.github.io/refined/

The thing is that, instead of redefining everything yourself, you could use a library that provides you with a set of predicates to compose and build the refinement you need. There are also much sophisticated ways to do this, like Liquid Haskell.

> Alternatively, you'd have to define a NonEmptyArray type that excludes arrays of length 0, but that seems less than useful.

I think the usefulness of a specific NonEmptyArray type is controversial, and I would say such types could be extremely useful. AFAIK there have been discussions if Haskell's Prelude (part of the standard library providing a name space for convenient functions and types, similar to the functions you get in e.g. Python like map, zip, filter, range, etc.) should be more save by not advocating too generic types and functions like the standard `map`, `head` and `tail` implementations.

Functions like `head` and `tail` can be seen as problematic as they can fail and cause runtime errors (the head and tail of an empty list cause a runtime error), but I do not think they already changed that (or if it's even a topic of discussion at the moment).

It's a little bit a matter of taste. Think about Unix' "head" program that by default prints maximal 10 lines of a file. How should we deal with the following?

    $ touch empty.txt
    $ head -n1 empty.txt

Currently this works - you do not get output and $? == 0, but one could also say "head" should panic here.

There no reason to "panic" about perfectly reasonable, valid use cases. `head` and `tail` in Haskell are badly designed (to address one of your examples), which is why every SO question about them and every question on haskell-beginners ends with the same answer: don't use them, pattern match instead.

I wonder how this could be done on hadware level.

You can look at the NaN value as an implementation of Option / Maybe, where it means None. It even behaves like it should, short-circuiting any normal operations with it to also produce NaN. Too bad Fortran and C lack sum types to surface that properly on the type level.

Agreed, NaN can be very useful indeed in certain circumstances. If nothing else, a NaN is still a floating point primitive, and can be stored in a large array with other floating point numbers, whereas an exception cannot. If you want an exception, just test Double.isNaN(), and throw one.

NaNs should not be scary.

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

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.

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

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.

For floats, 1.0 / 0.0 produces Infinity according to the IEEE standard. I prefer it that way because it perfectly makes sense for the algorithms I usually deal with and having to check whether the denominator is zero or not makes code slower, which isn't an option if you're crunching tens of millions of numbers a second. It also unnecessarely bloats code.

Whatever you choose for that, if it doesn't throw an exception, then given x = 1/0 (or x = something else NaNish) we really should have x == x. Basic equality really needs to be reflexive, or else you're asking for trouble.

you throw an error and stop the calculation, and let the programmer decide what to do.

"Throw an error" makes no sense at the hardware level. That's like saying a NIC should "throw an error" when it loses link. It's up to languages and libraries to turn signals/registers/flags into higher-level concepts like structured exceptions.

The IEEE standard contains a signalling NaN which is intended to throw an error when it is attempted to be used. It is not the result of any calculation, however, so typically it's only used as a marker to indicate that code is improperly attempting to access uninitialized data. There are such things as hardware exceptions and hardware interrupts on exceptions; and these things will trigger on sNaN in a (compliant) hardware FPU implementation.

My contention is that all NaN-resulting operations (Inf * 0, sqrt(-), e.g.) should halt the program instead of propagating a silent, dud value. When you reach them, it means usually there is something wrong with your algorithm (or less commonly, your data) and it is better to know that sooner than later.

Reply on news.ycombinator.com