Re: [boost] Re: rationals initialization bug

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-28 21:26:11

----- Original Message -----
From: "John (EBo) David" <ebo_at_[hidden]>

> Next, I too like Dave's algorithm using continued fractions, and look
> forward to Paul handling the underflow problem.  I have a lead on a
> solution and will post it if I have time to work it up before Paul
> does... As another note, the f==0 condition is not in and of itself
> sufficient.  Try approximating PI and watch the values of f.  This is
> what I got:
>
> ...
> approximating[12]:245850922/78256779 = 3.14159 f = 0.328678
> approximating[13]:817696623/260280919 = 3.14159 f = 0.0424948
> approximating[14]:1873004067/1769750620 = 1.05834 f = 0.532265
>
> after this point a1 goes negative...

Of course it's not sufficient to check for f == 0. I think it has to do with
the relative precision of floats and longs. After one iteration of the
algorithm run on 1.0/3.0, it has approximated 1/3 to within the precision
representable in a double, so it stops. When you try the same with pi, it
runs out of precision in the long before it reaches that point.

> Since it appears to be the general consensus not to put an implicit
> conversion into the rationals class (and at this point I whol hartedly
> agree), is it reasonable to define a rational_cast<> or something to
> just get the float data in initially...  What do you all feel is the
> best solution to getting data in?

The traditional answer (e.g. on lisp systems) has been a function called
"rationalize".

P.S. The precedent on most systems I can find has also been to do an exact
conversion (with unlimited-precision integers where neccessary) when a
rational is constructed from a float. I have the algorithm for that, if you
want it.