|
Boost : |
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[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...
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?
EBo --
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk