RE: [boost] Math Functions

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
tables.

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