For purposes of given math module (that performs some statistical computations) it's sufficient to store reals in IEEE754 floating point format. I'm considering to migrate to SQLLite as persistent storage. But documentation of SQLLite doesn't clearly state what standard it supports. SQLLite wiki says it supports REAL:
REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number.
But there are two different IEEE standards for floating-point computation. IEEE 754 (b = 2) and IEEE 854(b = 2 or b = 10). I need to store IEEE 754 single precision float or double in SQLLite column and later read this value into variable with original precision (single or double) in IEEE 754 format (no need any arithmetic).
Two sub-problems appear: one about storing doubles and another about storing single precision values in target unknown 8-byte floating point number.
storing doubles: can I be confident that I will read the same binary value (754 has unique binary representation), including all kinds of NaN, pos/neg infinity, etc. (in other words: is SQLLite lossless with regard to IEEE754 doubles)?
storing single float to double: is this conversion reversible? This problem is about IEEE754 standard in general and doesn't relate to any specific software.
This question is not only about math-software and SQLLite - it's about representation of floats in different formats and losses related to conversions. Useful introduction article about this topic here - What Every Computer Scientist Should Know About Floating-Point Arithmetic
The answer is, you have encountered a documentation deficiency in the SQLLite wiki. They should have specified an 8-byte IEEE floating point number following the standard of IEEE 754 for double precision numbers. This is how all the data bases behave; implementers just assumed that this was the behavior dictated by the standard, and indeed the "standard" writers meant this behavior.
Don't think harshly of the writers of the wiki. I've been involved in the C++ standard, and OMG it is hard to get everything perfectly right!
But the answer to your real question, concerning NANs and there brethren, is that implementers will have felt free to ignore that issue or invent their own way of comping with division by zero and the like. So I would not count, for example, on reproducing the NAN you have sent into the database.