Re: Motion P1788/M0002.01_ProcessStructure YES
> Date: Tue, 24 Mar 2009 11:32:34 +0100
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0002.01_ProcessStructure YES
>
> On 2009-03-23 23:20:38 -0700, Dan Zuras Intervals wrote:
> > > > The only reason the emax >= 1000*p constraint is in there
> > >
> > > This constraint can be a real problem in practice. For instance,
> > > how would you compute sin(2^emax)?
> >
> > Badly. But then again sin() is not required to conform
> > to 754.
>
> You missed the point that if someone wants to implement sin() (on
> the whole domain provided by the floating-point system), it will
> be quite difficult to achieve on such a system.
>
> > > . . .
> >
> --
> 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)
No, I get the point. It is difficult. It is perhaps
VERY difficult. There is just nothing I can do about it.
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?
At least 754-2008 provides you with several 'outs' to this
problem. You can fix emax to something suitably small.
You can compute sin(x) using arithmetic with strictly larger
range & precision than the desired result. And, if all else
fails, you need not include sin(x) to conform. Your sin(x)
can behave as best as you are able to make it & that's OK.
I don't know what else to say, Vincent.
This is why you get paid the big bucks. :-)
Or euros, in your case.
Dan