From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2004-05-19 03:00:05
Le mar 18/05/2004 à 03:52, Antony Searle a écrit :
> >From what I can make out of their respective implementations, the interval
> library assumes that asinh (when it exists) produces values consistent with
> the floating point rounding mode (i.e. rounding up or down as requested).
> The boost implementation of asinh doesn't seem to take account of the
> rounding mode like this [for x < 0 it returns -asinh(-x), which will be
> rounded the wrong way]. Does this mean that the inclusion guarantee is
> violated when combining boost interval and boost asinh?
> Antony Searle
The interval library relies on a "rounding" policy in order to do all
the computations on the base type ("float", "double", and "long double"
for the case you seem to be interested in). There is a version of this
policy that assumes the asinh function for interval can be computed by
simply setting the rounding policy and then calling the asinh function
on the base type. So, you are right, the computed values must be
consistent with the rounding mode for the interval library to work
Unfortunately, it is almost never true in real life. It is the reason
why the interval library will not use this policy by default; the user
has to explicitly set this policy in the interval type definition. As
you pointed it out, the boost asinh function does not allow to guarantee
the inclusion property: there is an obvious problem with negative
numbers, but even for positive numbers there is no guarantee the log
function will behave sanely for example.
The examples/transc.cpp file explains how to use an external library in
order to correctly compute all these strange functions. In this example
it is the MPFR library that is used, but other mathematical libraries
could be used instead.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk