From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-05-24 08:49:55
Paris (U.E.), le 24/05/2004
Yes, unfortunately the implementations of a few special functions
I provided are a priory unfit for interval computations, essentially
because I did not quite know how to do so. There is demand for that
feature, so I'll add it to the to-do list (all the more so as there are
now examples of how to do so :-) ). Of course it must not conflict with
the more widespread use of these special functions, so if it gets done,
it will most likely need a not-too-broken compiler... As well, there are
a number of other things for the special function library which have a
higher priority (like "I've been meaning to do this but could not find
time in the last two years or so"... :-< ).
In article <CONTINUITYH71yEXUIE0000001a_at_continuity>,
"Antony Searle" <antony.searle_at_[hidden]> wrote:
> Thanks for the detailed answer. I'll investigate my options re external
> Antony Searle
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Guillaume Melquiond
> Sent: Wednesday, 19 May 2004 6:00 PM
> To: Boost
> Subject: [boost] Re: Safe to combine boost asinh and boost interval?
> Le mar 18/05/2004 à 03:52, Antony Searle a écrit :
> > Hi,
> > >From what I can make out of their respective implementations, the
> > library assumes that asinh (when it exists) produces values consistent
> > 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?
> > Thanks,
> > Antony Searle
> > antony.searle_at_[hidden]
> 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.
> Best regards,
> Unsubscribe & other changes:
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk