I created a function to read floats (IEEE 754 binary 32-bit) from strings, for developers. I have everything finished and working perfectly, except i'm wondering if a user/or programmer enters a string such as "NaN" that does not specify QNaN or SNaN, what should it be considered? or should "NaN" be considered an invalid input and only accept "QNaN" or "SNaN"?

  • 3
    That's going to depend on the context. Which one do the users most likely want? What are the possible consequences of them getting the one they don't want, without realising? Could you provide options for them to decide?
    – jonrsharpe
    May 21, 2019 at 7:57
  • So long as the caller has a means to determine that you passed QNaN or SNaN, then they have everything necessary to convert as needed. Pick the one they will most likely need, and provide adequate documentation.
    – Neil
    May 21, 2019 at 8:05
  • @jonrsharpe Well, the function is for the general public of programmers. A library that anyone can use, so its not for any specific purpose other than what someone else might decide. there will definitely be documentation of the function. Providing an option to switch the behavior doesn't seem necessary to me. Perhaps someone has an opinion on that? May 21, 2019 at 19:04

1 Answer 1


First of all you should note that the signaling NaN (SNAN) is behaving the same as the quiet NAN (QNAN) when floating point exceptions are disabled. Usually they are disabled.

If "NaN" in your file is supposed to mean "missing data" then use QNAN.

If "NaN" is your file is supposed to mean "this must be initialized with proper data later" the use SNAN.

In the latter case an exception would be generated (if enabled, of course) in case the data is (accidentally) read and fed into a computation. However, when doing it this way (exceptions enabled) you must ensure that all your other FP computations do not generate NaN during regular computation and/or you need to implement proper exception handling. There of course you loose the advantage of FP math of being algebraically closed, i.e. be able to work in an exception free manner.

One problem with FP exceptions is also that in most programming languages the exceptions are non-continuable, whereas in the FP world this is not necessary (after exceptions the code can be continued). This is a bit too restrictive.

Personally I would suggest you to use QNAN.

  • "Personally I would suggest you to use QNAN." Do you prefer that over "NaN" being considered invalid and enforcing ether QNAN or SNAN strings? May 21, 2019 at 21:26
  • I would not distinguish SNAN and QNAN in a text format, just "NaN" which gets parsed as QNAN. One could add the feature that also the text strings "QNAN" and "SNAN" are parsed, but in any case I would read them as QNAN symbols. I cant think of any use-case that needs the user to enter a signaling NaN in the data. So I would ignore this. It might have unwanted side effects
    – Andreas H.
    May 22, 2019 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.