Re: Motion P1788/M0002.01_ProcessStructure YES
On 2009-03-24 03:53:56 -0700, Dan Zuras Intervals wrote:
> What do you do on MPFR now? Do you not have a rather large
> fixed emax for the precisions you currently define in MPFR?
> Is it not difficult to compute sin(2^emax) on your current
> system correctly or even realiably?
The exponent range can be changed by the user of the library. So,
if the user knows that he may need to do things like sin(2^emax),
a solution is to reduce the exponent range. For instance, this
can be useful for an online calculator, in particular because
the author of the calculator doesn't necessarily control what
its user will do (he can still wrap the sin and cos functions
e.g. to return NaN in such cases, but the user of the calculator
may wonder why he gets such results). Otherwise MPFR may abort
(this can happen for smaller numbers, because of lack of memory).
In MPFR, the default emax is 2^30 - 2, and the maximum allowed
precision is at least 2^31 - 1 (and should be 2^63 - 1 on 64-bit
machines). So, I don't think there's any problem *by default*
except the lack of memory.
> At least 754-2008 provides you with several 'outs' to this
> problem. You can fix emax to something suitably small.
Unfortunately, the user won't have that with the *default* emax.
> You can compute sin(x) using arithmetic with strictly larger
> range & precision than the desired result.
But the implementation has to support that, and this is not required
by the standard.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)