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.
> 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.
> 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)?
> 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.
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.
[...]
> 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).
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)