From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-09-05 08:02:04
> -----Original Message-----
> From: jmaurer [mailto:jmaurer]On Behalf Of Jens Maurer
> Sent: Tuesday, September 04, 2001 10:45 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math Functions
> > 1 My instinct is to only produce a double version(64 bit reals),
> > rather than template versions.
> > This is because the polynomial coefficients and algorithms
> > are only readily available for double.
> > Most people will use these.
> Is you implementation extensible? Can I later add a "long double"
> or "my_really_long_double" version of the respective function?
> Is it documented how I can compute the coefficients with some
> unlimited-precision tool?
No my implementation is NOT extensible. Doing this is a MAJOR task,
needing an unlimited precision tool, and probably some new algorithms.
Perhaps NIST will do it with their stated program to update A & S printed
However the current, even urgent, need is for double (64bit) precision,
which is enough for most purposes.
> > 3 Handling math errors like overflow/underflow.
> If you go the "exception" route, appropriate overflow_error
> and underflow_error exception classes are at your disposal
> in the standard library.
I don't see how to check for underflow and overflow PORTABLY.
No, the result is always "false". This is a defining property
> of NaNs, they are the only quantities where x == x is false.
> Thus, for IEEE numerics, you can say
> if(x != x)
> throw "x is NaN";
(I'll try to NaN check suggested - perhaps this is enough?)
> Do make sure to put your compiler into "strict IEEE conformance mode",
> otherwise a greedy optimizer may throw away the "x != x" and replace
> it by "false".
Will check this out.
> > 5 When checking for an argument value like zero or unity,
> > should I also allow within an espilon of it?
> > if (p <= 0) ...
> > or
> > if (p <= 0 + standard::numeric_limits<double>::epsilon() ) ...
> I'd say no. If you have a rounding error, you should pass it on
> and not try to be clever. In particular since the "epsilon" sized
> quantity could be there on purpose. Also note that epsilon() is a
> very large quantity (about 10^-16), so your check above flattens
> all values between min() ( = 10^-308 ) and epsilon() ( = 10^-16 ).
> Very surprising.
Not so surprising if range is 0 to 1 - like probability?
Would this case
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk