Safe to combine boost asinh and boost interval?
From what I can make out of their respective implementations, the interval
Hi, 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? Thanks, Antony Searle antony.searle@anu.edu.au
Le mar 18/05/2004 à 03:52, Antony Searle a écrit :
Hi,
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?
Thanks,
Antony Searle antony.searle@anu.edu.au
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 correctly. 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, Guillaume
Thanks for the detailed answer. I'll investigate my options re external libraries. Best, Antony Searle antony.searle@anu.edu.au -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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 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?
Thanks,
Antony Searle antony.searle@anu.edu.au
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 correctly. 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, Guillaume _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Paris (U.E.), le 24/05/2004 Bonjour 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"... :-< ). Merci Hubert Holin In article <CONTINUITYH71yEXUIE0000001a@continuity>, "Antony Searle" <antony.searle@anu.edu.au> wrote:
Thanks for the detailed answer. I'll investigate my options re external libraries.
Best,
Antony Searle antony.searle@anu.edu.au
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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 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?
Thanks,
Antony Searle antony.searle@anu.edu.au
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 correctly.
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,
Guillaume
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Antony Searle -
Guillaume Melquiond -
Hubert Holin