
Boost : 
From: helmut.zeisel_at_[hidden]
Date: 20011022 04:23:49
 In boost_at_y..., brianjparker_at_h... wrote:
>  In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
I uploaded a first version of the rational approximation:
http://groups.yahoo.com/group/boost/files/big_int/farey_20011022.zip
The prototype is
template<class Int, class Float>
boost::rational<Int> farey(const Float& v, const Int& lim);
> >
> > Maybe we should have both.
>
> Yes, that is my conclusion as well.
This would be no problem for me  I would appreciate
to have different options.
> It may be possible to overload
> the function based on the error term type double or float for
> relative error and integer for max. denominator, although this may
be
> too fragile and separate function names may be better.
Do not try to be too clever.
Since there are different options for rational approximation,
it will be difficult to find a single interface
for all of them.
I chose the name "farey" to point out
that it is just one algorithm
and not the only solution for rational approximation.
> An advantage of the relative error approach is that a default small
> value close to the epsilon of the floating point representation
could
> be specified, so that the error argument could be ignored in many
> cases.
If you just want to control the relative error,
there is a simple rule how to specify the max. denominator.
You can find it in my preliminary documentation.
Observe that the return type is rational<Int>,
so we need one way to secify the integer type to be used.
Specifying it by the type of the second parameter
is IMHO the most convenient solution.
> Also, as was pointed out in a previous posting, the Netlib code
needs
> to have two defines updated for IEEE754 floating point I will look
> into this in the future.
>
IMHO updating for IEEE754 is not enough 
the algorithm should also work for some future
high precision floating point type.
A better solution would be to choose these
values from std::numeric_limits.
I fear, however, that this will not be possible
without deeper understanding of the algorithm used there,
and this (thanks to the gotos) will not be possible
without a look into the book referenced there.
Helmut
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk