Re: Motion P1788/M0002.01_ProcessStructure YES
> Date: Tue, 24 Mar 2009 04:22:48 +0100
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0002.01_ProcessStructure YES
>
> On 2009-03-23 10:27:37 -0700, Dan Zuras Intervals wrote:
> > > Also in traditional arbitrary precision models, the range normally
> > > doesn't change, only the precision, whereas Section 3.7 requires
> > > emax >= 1000 p (which may not be a good idea in high precisions,
> > > e.g. if one wants to provide faithful rounding on functions like
> > > sin and cos).
> >
> > Given that, this is not intended as a "real constraint".
> >
> > You will notice (in 3.7) that when asked for an extendable
> > datatype of a given p & emax it is sufficient for a
> > conforming system to return a datatype of p' & emax' such
> > that p' >= p & emax' >= emax.
>
> Still, emax isn't bounded.
Correct. Fixed but not bounded.
>
> > As you say, in most arbitrary precision packages the range
> > is fixed to something like emax >= 2^31 - 1 = 2147483647.
> > So for precisions all the way up to p = 2,147,483 digits
> > just one emax is possible.
>
> Users go beyond this precision.
Yep. Most of the time, no, but it DOES happen.
>
> > 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.
>
> > is to prevent users not familiar with how to design a good
> > floating-point datatype from asking for something like
> > p = 1,000,000 digits & emax = 4. This would cause the
> > creation of a datatype that had silly properties that
> > would confuse results with unwanted overflows & underflows.
>
> Well, in MPFR it is even possible to have a negative emax. We haven't
> heard of users having problem with the exponent range.
It is possible in 754 as well. (Well, not negative but
small.) But you have to call it out. We don't want
users to run into it by accident or carelessness.
>
> But Section 3.7 says:
>
> Language standards should define mechanisms supporting extendable
> precision for each supported radix. Language standards supporting
> extendable precision shall permit users to specify p and emax.
> Language standards shall also allow the specification of an
> extendable precision by specifying p alone; in this case emax shall
> be defined by the language standard to be at least 1000 Ã? p when p
> is â?¥ 237 bits in a binary format or p is â?¥ 51 digits in a decimal
> format.
>
> So, the constraint on emax is used only when the user doesn't specify
> an emax.
Yep, exactly. If they want to call out p = 10^6 & emax = 4
we won't stop them. The responsibility is then theirs.
>
> [...]
> > But we also did not want to permit the user to define
> > those silly datatypes that would cause trouble of a kind
> > that can easily be avoided. This implied that we should
> > continue to demand that emax/p >= c for some constant c.
>
> IMHO, a formal datatype with an unbounded precision and a bounded
> exponent range isn't a silly datatype (it can be useful that the
> ulp is exactly representable, even without subnormals, but this
> doesn't seem to really be necessary in practice).
Well, as I said, they can have it if they ask for it.
>
> Now, I'd say that the main problem is that the format should have a
> fixed width, and the standard seems to disallow complex structures
> (for which the concept of width does not make sense).
>
> --
> 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)
This last is true. Prof Kahan insisted on fixed widths
on the grounds that arrays weren't easily addressed
without it. Arguments that arrays of pointers were
easily addressed did not sway him. And with no MPFR
people in the room the rest of us didn't really form
an interest group against it.
Yours,
Dan