Question

This question refers to the IEEE standard floating point numbers used on C/x86.

Is it possible to represent any numeric (i.e. excluding special values such as NaN) float or double as a decimal string such that converting that string back to a float/double will always yield exactly the original number?

If not, what algorithm tells me whether a given number will suffer a conversion error?

If so, consider this: some decimal fractions, when converted to binary, will not be numerically the same as the original decimal value, but the reverse is not true (because the binary has bounded precision so any decimal expansion is finite and perfect if not truncated), so here’s another question…

Is it ever necessary to introduce deliberate errors into the decimal representation in order to trick the atof (or other) function into yielding the exact original number, or will a naive, non-truncating toString function be adequate (assuming exact conversion is possible in general)?

Answer 1

According to this page:

Actually, the IEEE754-1985 standard says that 17 decimal digits is
enough in all cases. However, it seems that the standard is a little
vague on whether conforming implementations must guarantee lossless
conversion when 17 digits are used.

So storing a double as a decimal string with at least 17 digits (correctly rounded) will guarantee that it can be converted back to binary double without any data loss.

In other words, if every single possible double-precision value were to be converted to a decimal string of 17 digits (correctly rounded), they will all map to different values. Thus there is no data-loss.

---

I’m not sure on the minimum cut-off for single-precision though. But I’d suspect that it will be 8 or 9 digits.