QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?That's an orthogonal issue: the specific cause of the error (i.e., not a real number vs. not a valid 64-bit floating point number) may be independent of the response to the error (i.e., quiet vs. signaling).design by contractThat's what we are missing.Exactly!Yet are there contracts that are detailed enough to cover all these cases of not-a-real-number, not-a-float-number, etc.? Moreover, in a complex library, how does one ensure that ALL library items share the same contract patterns so there's no misinterpretation of what qNaN, sNaN, ±INF, etc. mean.From David Goldberg's seminal articleQuoteUnfortunately, the IEEE standard does not guarantee that the same program will deliver identical results on all conforming systems. Most programs will actually produce different results on different systems for a variety of reasons. For one, most programs involve the conversion of numbers between decimal and binary formats, and the IEEE standard does not completely specify the accuracy with which such conversions must be performed. For another, many programs use elementary functions supplied by a system library, and the standard doesn't specify these functions at all. Of course, most programmers know that these features lie beyond the scope of the IEEE standard. Many programmers may not realize that even a program that uses only the numeric formats and operations prescribed by the IEEE standard can compute different results on different systems. In fact, the authors of the standard intended to allow different implementations to obtain different results. Their intent is evident in the definition of the term destination in the IEEE 754 standard: "A destination may be either explicitly designated by the user or implicitly supplied by the system (for example, intermediate results in subexpressions or arguments for procedures). Some languages place the results of intermediate calculations in destinations beyond the user's control.