From: John (EBo) David (ebo_at_[hidden])
Date: 2000-11-28 16:19:31
I was out sick for a couple of days and I came back to what 100+
messages and a good bit of them on the rationals initialization bug...
What did I start? 8-0
hmmm... There are so many things that I would like to respond to, but to
cut down on the bandwidth I'll put it in a single message.
Lutz Kettner points are well taken and appreciated. The one thing that
I would add to counter this is: many real world measurements are made in
floating point measurements not rationals. I agree that
exact->inexact->exact conversion is not a wise thing, but as most if not
all of my original input data comes to me as floating point I need
something to get the data in the first time. From there I'll keep it
rational. But then most of the people *using* my results want/need them
in back in floating point. So, for myself I see little choice with
regards to floating point I/O.
As an aside, I was apparently asleep at the keys when I posted my
original note on conversions, and apologies for not thinking before
sending, but I am glad for the lively discussion.
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:245850922/78256779 = 3.14159 f = 0.328678
approximating:817696623/260280919 = 3.14159 f = 0.0424948
approximating:1873004067/1769750620 = 1.05834 f = 0.532265
after this point a1 goes negative...
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk