 # Boost :

From: Matthew Austern (austern_at_[hidden])
Date: 2000-11-28 13:59:37

I agree that conversion from double is a tricky issue.

On a typical system, double is 64 bits with a 52-bit mantissa.
We actually get 53 bits in the mantissa, because the first
one bit is implied. So 1/10 lies between these two numbers:
1.1001100110011001100110011001100110011001100110011001 * 2^-4
1.1001100110011001100110011001100110011001100110011010 * 2^-4.

These are rational numbers, 7205759403792793/72057594037927936
and 3602879701896397/36028797018963968.

(Aside: there's no requirement that a system choose the closest
possible floating-point number when doing radix conversion.
That's partly because there's no constant-space radix conversion
algorithm that always gets the best possible result.)

It seems to me that what people are really asking for is an
algorithm, given a rational number p and an integer N, for
finding the closest rational number q whose denominator is
no greater than N. That's a generally useful algorithm; it
shouldn't be hidden away inside a constructor, and there
should never be an implied value for N. (Because only the
user knows what the appropriate value for N is.)

On the other hand, conversion from a string doesn't strike me
as such a bad idea. Radix conversion is easy; it's parsing that's
hard. If you're looking at a decimal string, it's easy to see
that "0.1" is 1*10^-1.

If people are interested, I can extract the floating-point parsing
code from the SGI I/O library.

--Matt