Yes, agreed, one or both of a) and b is/are the implied assumption.
I also should have mentioned in my original post where I got the idea for all this from:
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2006/n2005.pdf
So if I understand this correctly, for step 2) there is a certain number of digits (max_digits10 in
the paper) that express the original value in "equal or higher precision" than was in the original
float.
OK, so let's play with numbers:
The number D of digits needed to represent a number N in
base 10 notation is
D = ceil(log10(N)).
For a single-precision floating-point number, there are some
20 bits in the mantissa, so the number of digits D to represent
the mantissa becomes
D = ceil(log10(2^20))
= ceil(20*log10(2))
> 20*floor(log10(2))
> 20*3
> 60.
So one needs *at*least* 60 digits to represent the number.
Of course, a similar argument is used for the exponent.
Compare these >60 digits to the 6-8 significant digits of
the floating-point number: 10% of the digits in the exact
representation represent everything except the last bit,
while the remaining 90% of the digits are spent on getting
that last bit right.
Of course, most parsers stop parsing after the remainder
of the parsed literal becomes less than the relative
accuracy of the number, so you would have to write a
dedicated parser for the stream.
So to summarize:
1) You expanded the required space by at least a factor
10, compared to the binary represnetation.
2) 90% of the stored information pertains the last
bit of the binary format
3) You need to write a dedicated parser for the result
....and all of this to avoid that some person would need
to write something like
stringstream ss;
float a = 1.23;
ss << std::hex() << a;
ss >> std::hex() >> a;
std::cout << std::dec() << a;
to inspect the contents of the stream.
Rune
