# NAN: What is it good for? (programming) **URL:** \ **Category:** Factual Questions\ **Created:** [August 11, 2011, 12:35am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275 "2011-08-11T00:35:29Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [August 11, 2011, 3:02am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/21 "2011-08-11T03:02:22Z")
You could view a computation returning “NaN” as a form of returning an error message (“Error: You passed me an invalid argument!”). The fact that this error message doesn’t automatically crash the whole program down could then be viewed as providing the calling context an opportunity for exception handling (i.e., it can check the returned error message and react as it would like to it, including dying/propagating some error message upwards if it feels that is appropriate or carrying out some other form of damage-control more to its liking). The fact that future computations with “NaN” also return “NaN” is just more (appropriate) error messages (“You passed me an invalid argument”). From that perspective, NaN is not an unreasonable design choice; it’s the programming culture of not checking for or thinking about how to respond to such error messages which is the problem. [But, then, perhaps a better design choice would find a way to enforce, or sidestep the need for, a more careful programming culture…] ---
**Author:** ![Keeve](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@Keeve](https://boards.straightdope.com/u/Keeve)\ **Post date:** [August 11, 2011, 3:02am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/22 "2011-08-11T03:02:29Z")
> [@Indistinguishable](#): > > I don’t prefer the latter option. I am of a similar philosophy as the OP and you. Oh. Sorry. **engineer\_comp\_geek** and **Bytegeist** : Excellent examples. Exactly the sort of stuff I was asking for. Thank you very much. I can go to bed now. Good night! ---
**Author:** ![leahcim](https://avatars.discourse-cdn.com/v4/letter/l/b4bc9f/32.png) [@leahcim](https://boards.straightdope.com/u/leahcim)\ **Post date:** [August 11, 2011, 3:05am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/23 "2011-08-11T03:05:56Z")
> [@Chronos](#): > > Quoth **tellyworth** :And then, when that later programmer tries to run the incorrect code, it’ll crash and give him an error message like “Invalid argument for sqrt”, and he’ll be forced to go back and fix his mistake. But it might not. If a is larger than one most of the time, the code will silently succeed most of the time. If 0 \< a \< 1 is a very rare case, QA testing will not discover it, but it will turn up in the field. If this incorrect code is buried very deep in a system, (e.g. as a precompiled library) it may stop being obvious what is causing the error, and it may be seen as a “every once in a while the thing just fails” error. ---
**Author:** ![Keeve](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@Keeve](https://boards.straightdope.com/u/Keeve)\ **Post date:** [August 11, 2011, 3:06am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/24 "2011-08-11T03:06:33Z")
> [@Indistinguishable](#): > > You could view a computation returning “NaN” as a form of returning an error message (“You passed me an invalid argument”). The fact that this error message doesn’t automatically crash the whole program down could then be viewed as providing the calling context an opportunity for exception handling (i.e., it can check the returned error message and react as it would like to it). The fact that future computations with “NaN” also return “NaN” is just more (appropriate) error messages (“You passed me an invalid argument”). Yeah. Unfortunately, far too few of these routines allow you to pass these messages up and down the chain. Without them, it’s very difficult to figure out where the problem lies. But each programmer thought his routine was bulletproof and wouldn’t need to pass along any error messages. Aargh! ---
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [August 11, 2011, 3:08am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/25 "2011-08-11T03:08:27Z")
Indeed (you appear to have caught me mid-edit, though, to be fair, that’s not hard to do :)) ---
**Author:** ![Keeve](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@Keeve](https://boards.straightdope.com/u/Keeve)\ **Post date:** [August 11, 2011, 3:11am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/26 "2011-08-11T03:11:38Z")
> [@leahcim](#): > > But it might not. If a is larger than one most of the time, the code will silently succeed most of the time. If 0 \< a \< 1 is a very rare case, QA testing will not discover it, but it will turn up in the field. Here’s something I learned as a programmer: “Almost never”, “rarely”, “sometimes”, and “usually” all mean the exact same thing: “Yes, it does happen, and the code had better be able to handle it.” > [@leahcim](#): > > … it may stop being obvious what is causing the error, and it may be seen as a “every once in a while the thing just fails” error. Those are the sort of errors that made me grateful that my code (or rather, the code that my bosses rushed through) was used by business, and not by healthcare. ---
**Author:** ![leahcim](https://avatars.discourse-cdn.com/v4/letter/l/b4bc9f/32.png) [@leahcim](https://boards.straightdope.com/u/leahcim)\ **Post date:** [August 11, 2011, 3:14am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/27 "2011-08-11T03:14:03Z")
> [@Indistinguishable](#): > > … it’s the programming culture of not checking for or thinking about how to respond to such error messages which is the problem. [But, then, perhaps a better design choice would find a way to enforce, or sidestep the need for, a more careful programming culture…] This is the philosophy that Java’s checked exceptions is based on. A function can declare that it throws a certain exception, and the user of that function \*\*must \*\* either handle that exception, or declare that his function might throw that exception as well. This enforces linguistically an obligation to handle the edge cases. Checked exceptions are a bit unwieldy for math though. I’d hate to have to enclose every division with a try { … } catch (DivideByZeroException) { System.out.println(“You Suck!”); } ---
**Author:** ![tim314](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/tim314/32/3468_2.png) [@tim314](https://boards.straightdope.com/u/tim314)\ **Post date:** [August 11, 2011, 3:37am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/28 "2011-08-11T03:37:39Z")
> [@Chronos](#): > > Quoth **tellyworth** :And then, when that later programmer tries to run the incorrect code, it’ll crash and give him an error message like “Invalid argument for sqrt”, and he’ll be forced to go back and fix his mistake. Only if he runs it with the particular input that produces the error. For sqrt, it’s pretty obvious, but what if it’s “x = foobar(a,b,c)”? ---
**Author:** ![Bytegeist](https://avatars.discourse-cdn.com/v4/letter/b/9dc877/32.png) [@Bytegeist](https://boards.straightdope.com/u/Bytegeist)\ **Post date:** [August 11, 2011, 4:32am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/29 "2011-08-11T04:32:46Z")
> [@leahcim](#): > > This is the philosophy that Java’s checked exceptions is based on. … Checked exceptions are a bit unwieldy for math though. I’d hate to have to enclose every division with a try { … } catch (DivideByZeroException) { System.out.println(“You Suck!”); } Then worry no longer. Under Java 7, division is accomplished as follows: [ol] [li]Request a singleton instance of the dividend via static methods in the _java.math.Dividend_ class.[/li][li]Similarly for the divisor from _java.math.Divisor_.[/li][li]Define and create an instance of an inner class that has a callback method for receiving the quotient. It should derive from _java.math.QuotientReceiver_.[/li][li]Call the dividend object’s _beginDividing_() method, passing it references to your dividend object and quotient receiver object.[/li][li]Returned from this call will be a serial number identifying your division request. Store this somewhere handy.[/li][li]When the division is complete, the quotient will be passed as an instance of _java.lang.Number_ to your quotient receiver’s _receiveQuotient_() method, along with the serial number of the originating request. By default this key-value pair will be stored in an internal hash (of type _java.util.HashMap_), but you can override this behavior. Error reporting commonly goes here.[/li][li]At some later time, if or when you need the result, call the quotient receiver’s _getQuotient_() method, passing it the serial number stored earlier. _This is your answer._[/li][li]When you’re done with the dividend and divisor singletons, call their _close_() methods. Otherwise later divisions by 6, for example, might fail.[/li][li]_Close_() can of course throw a variety of exceptions, so be sure to surround the calls with a try-block.[/li][/ol] Next week I’ll cover how to compare two Unicode strings in Java — which under SE 7 can now be achieved in under 50 lines of code. ---
**Author:** ![Dr.Strangelove](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dr.strangelove/32/6613_2.png) [@Dr.Strangelove](https://boards.straightdope.com/u/Dr.Strangelove)\ **Post date:** [August 11, 2011, 5:26am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/30 "2011-08-11T05:26:40Z")
> [@Keeve](#): > > Here’s something I learned as a programmer: “Almost never”, “rarely”, “sometimes”, and “usually” all mean the exact same thing: "Yes, it does happen, and the code had better be able to handle it. I’d go further: for programmers, the opposite of impossible is _inevitable_. If there is some finite chance of a thing failing, it _will_, if your userbase is large (millions). A small exception is where you can demonstrate mathematically that a failure is rare enough to be implausible–say, hash collisions in a 256-bit cryptographic hash. For what it’s worth, NaNs allow you to have the best of both worlds: triggering unrecoverable errors in the programming environment (so you are forced to fix them), as well as reasonable robustness against failures in the field. You can write your code so that intermediate NaNs are checked in debug code (so that you see them at the point where they occur), while in release code you just have one check at the end that allows a graceful failure in case of problems. BTW, the first Ariane 5 rocket blew up due to an unhandled numeric conversion exception. Probably would have been ok had the software clamped the final value or done something “sensible”. ---
**Author:** ![Jragon](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@Jragon](https://boards.straightdope.com/u/Jragon)\ **Post date:** [August 11, 2011, 5:53am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/31 "2011-08-11T05:53:23Z")
I don’t think it’s too much odder than having int indexOf(element) methods return -1 for a nonexistent element. Yes, it would be better to use a boolean contains(element) in many cases, but in large systems there’s always a CHANCE that something won’t be where it should be, and it limits near redundant checks. For instance, if I had to ensure an element was existing, and if so get the element’s index I could use: if(structure.contains(element){ whatever = structure.indexOf(element); } // do stuff or I could just used: whatever = structure.indexOf(element); if(whatever \>= 0){ // do stuff } Which at the very least saves me a function call (assuming the optimizer doesn’t find some automagic way of cleaning it up). Further, it’s much more acceptable to be able to pass in invalid arguments than have it crash your program with an NPE every time you try to get the index of a nonexistant object. NAN fills a similar concept, sure, you shouldn’t be passing -1 into sqrt, but in large libraries (especially ones you have no control over the source for) being able to accept a graceful notification that what you want simply can’t happen is sometimes better than throwing a temper tantrum and killing your program. This is especially true that many integral systems (i.e. ones that control precision machinery) are very fond of floating point arithmetic, and allowing the odd NAN is much safer for actual, fleshy meatbags than throwing a tantrum and dropping a bucket of slag (and much prettier than checking DivideByZeroErrors all the time). ---
**Author:** ![chorpler](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/chorpler/32/2888_2.png) [@chorpler](https://boards.straightdope.com/u/chorpler)\ **Post date:** [August 11, 2011, 6:39am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/32 "2011-08-11T06:39:40Z")
> [@Bytegeist](#): > > Then worry no longer. Under Java 7, division is accomplished as follows: > [ol] > [li]Request a singleton instance of the dividend via static methods in the _java.math.Dividend_ class.[/li][li]Similarly for the divisor from _java.math.Divisor_.[/li][li]Define and create an instance of an inner class that has a callback method for receiving the quotient. It should derive from _java.math.QuotientReceiver_.[/li][li]Call the dividend object’s _beginDividing_() method, passing it references to your dividend object and quotient receiver object.[/li][li]Returned from this call will be a serial number identifying your division request. Store this somewhere handy.[/li][li]When the division is complete, the quotient will be passed as an instance of _java.lang.Number_ to your quotient receiver’s _receiveQuotient_() method, along with the serial number of the originating request. By default this key-value pair will be stored in an internal hash (of type _java.util.HashMap_), but you can override this behavior. Error reporting commonly goes here.[/li][li]At some later time, if or when you need the result, call the quotient receiver’s _getQuotient_() method, passing it the serial number stored earlier. _This is your answer._[/li][li]When you’re done with the dividend and divisor singletons, call their _close_() methods. Otherwise later divisions by 6, for example, might fail.[/li][li]_Close_() can of course throw a variety of exceptions, so be sure to surround the calls with a try-block.[/li][/ol] > > Next week I’ll cover how to compare two Unicode strings in Java — which under SE 7 can now be achieved in under 50 lines of code. This explains why our code stopped running properly on my co-worker’s computer when she inadvertently replaced 6.0.26 with 7… ---
**Author:** ![panamajack](https://avatars.discourse-cdn.com/v4/letter/p/47e85d/32.png) [@panamajack](https://boards.straightdope.com/u/panamajack)\ **Post date:** [August 11, 2011, 7:26am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/33 "2011-08-11T07:26:42Z")
I’d recommend the lengthy but rather accessible article [What every computer scientist should know about floating-point arithmetic](http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html). It gives a pretty good explanation of why the standard was written the way it was. The first example given in the NaN section - a zero-finder for functions. If a numeric solver has to make initial guesses, it will sometimes pick invalid points for the function. But the programmer has no way of knowing in advance what function is going to be passed, so can’t just avoid testing those points (without essentially implementing multiple methods of analyzing the function). ---
**Author:** ![psychonaut](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/psychonaut/32/4655_2.png) [@psychonaut](https://boards.straightdope.com/u/psychonaut)\ **Post date:** [August 11, 2011, 8:05am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/34 "2011-08-11T08:05:27Z")
> [@Chronos](#): > > In the olden days, if you tried to perform an illegal arithmetic operation in a computer program (dividing by zero, log or sqrt of a negative number in a context that didn’t support complex numbers, etc.), the program would crash with an error message something like “Runtime error: Divide by zero”. This was good: Whenever a program was trying to do something like that, it was almost always a sign that the programmer was doing something stupid, and so it is appropriate to alert him of this as soon as possible, as well as giving some indication of what the problem was, so he would notice and mend his sinful ways. > > Nowadays, however, due to advances in compilers, processors, or both, an attempt at such an operation no longer produces an error. Instead, it quietly returns a result of NAN, or “Not a Number”, and the program continues on its merry way, propagating that NAN all over the place, and thrashing the internals of the program in a manner which can be extremely frustrating to track down. This is bad. I call bullshit on your entire premise. Since the 1980s almost all computer floating-point arithmetic uses the IEEE 754 standard, or some minor variation thereupon, and this standard quite clearly indicates that division by zero does _not_ result in a NaN, except for the pathological case that the dividend is also zero. ---
**Author:** ![BigT](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/bigt/32/12044_2.png) [@BigT](https://boards.straightdope.com/u/BigT)\ **Post date:** [August 11, 2011, 8:20am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/35 "2011-08-11T08:20:12Z")
> [@chorpler](#): > > This explains why our code stopped running properly on my co-worker’s computer when she inadvertently replaced 6.0.26 with 7… Which is horrible, horrible design. If you change something, you make sure to keep it where the old version works, at least for a while, or you let both versions exist simultaneously. Breaking old code when old code is still heavily in use is bad, bad programming. ---
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [August 11, 2011, 8:48am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/36 "2011-08-11T08:48:14Z")
> [@psychonaut](#): > > I call bullshit on your entire premise. Since the 1980s almost all computer floating-point arithmetic uses the IEEE 754 standard, or some minor variation thereupon, and this standard quite clearly indicates that division by zero does _not_ result in a NaN, except for the pathological case that the dividend is also zero. Division of non-zero numbers by zero is not particularly vital to the OP, is it?.. There’s still the matter of all the operations which do standardly produce NaNs. ---
**Author:** ![Jragon](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@Jragon](https://boards.straightdope.com/u/Jragon)\ **Post date:** [August 11, 2011, 9:11am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/37 "2011-08-11T09:11:42Z")
Honestly, if NAN “propagat[es] that NAN all over the place, and thrashing the internals of the program in a manner which can be extremely frustrating to track down.” then you have problems anyway. There are plenty of things that can do similar errors, NAN is probably one of the least common ones. Simple misplacing of your parens in expressions is probably more likely than a NAN to send your program in a similar, rather spectacular, failure cascade, though I suppose NANs can be caused by misplaced parens. There are tons of little, unnoticeable errors that are a complete pain to track down. NAN contributes to those, for sure, but depending on what types of data you frequently work with, it’s usually pretty uncommon. There are tons of logic errors that simply do not throw anything, the worst of which are the ones where you had something like an off by one error somewhere that makes the program work MOST of the time, return something strange, but not a complete outlier 5% of the time, and then segfaults the whole damn thing 3 months later when it finally gets the right pointer. I think NAN is just noticeable because when you get burned by it you tend to say “Not a Number!? Then why the hell is it even IN the floating point NUMBER I declared?” ---
**Author:** ![psychonaut](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/psychonaut/32/4655_2.png) [@psychonaut](https://boards.straightdope.com/u/psychonaut)\ **Post date:** [August 11, 2011, 9:17am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/38 "2011-08-11T09:17:29Z")
> [@Indistinguishable](#): > > Division of non-zero numbers by zero is not particularly vital to the OP, is it?.. There’s still the matter of all the operations which do standardly produce NaNs. I didn’t get that impression, since the only example he offered _was_ division by zero. Though if he’s arguing against NaNs in general, then his “olden days” almost predate the microcomputer era, in which case the behaviour he is talking about must have been idiosyncratic to whatever mainframe or minicomputer he happened to be using. Before floating point standardization, each computer used its own system for dealing with undefined or unrepresentable values: such a system could have thrown an error, but it could just as easily have involved setting status register bits, or even using special values like IEEE NaN. He is therefore not correct in his blanket assertion that computers in the “olden days” crashed upon encountering an undefined or unrepresentable value. Maybe they crashed on _his_ system, but certainly not on all of them (nor, I think, on even the majority). ---
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [August 11, 2011, 9:23am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/39 "2011-08-11T09:23:06Z")
> [@psychonaut](#): > > I didn’t get that impression, since the only example he offered _was_ division by zero. This is incorrect. Right after the first mention of division by zero in the OP come two other examples. ---
**Author:** ![psychonaut](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/psychonaut/32/4655_2.png) [@psychonaut](https://boards.straightdope.com/u/psychonaut)\ **Post date:** [August 11, 2011, 9:41am UTC](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275/40 "2011-08-11T09:41:21Z")
> [@Indistinguishable](#): > > This is incorrect. Right after the first mention of division by zero in the OP come two other examples. I stand corrected; my apologies. [Previous page](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275.md?page=1) [Next page](https://boards.straightdope.com/t/nan-what-is-it-good-for-programming/592275.md?page=3)