Re: Motion P1788/M0002.01_ProcessStructure YES
> Date: Mon, 23 Mar 2009 11:07:18 +0100
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0002.01_ProcessStructure YES
>
> On 2009-03-22 23:17:47 -0700, Dan Zuras Intervals wrote:
> > Clauses 3.4 through 3.7 define floating-point datasets &
> > formats that may be used for fixed or arbitrary precision
> > floating-point datatypes. And, clause 3.7 defines two
> > classes of arbitrary precision datatypes: Extended, which
> > are presumed to be available to either the implementation
> > or the language to provide higher precisions than were
> > available in 754-1985 & Extendable, which are designed
> > to give the programmer direct control over the range &
> > precision of both binary & decimal datatypes.
>
> I think that these extendable precision formats are designed to be
> used as fixed formats in rather small precision.
Vincent,
As one of the designers :-) I think I can safely say that
this is not so.
Extended is intended to be used as fixed formats for
precisions that are rather small by your standards.
But extendable is intended for the user to have access to
just the sort of arbitrary precision that researchers such
as you enjoy. The only real constraint is that the
arithmetic be standardized in the same manner as the rest
of 754.
>
> 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.
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.
We wanted to permit systems such as yours to be conforming.
The only reason the emax >= 1000*p constraint is in there
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.
The reason emax >= 1000*p was chosen (& I must admit it
was my choice) is that I observed that emax/p increases
gradually with increasing precision (to permit increased
range in the 'double' of a given precision). Further,
to two largest fixed precisions defined (Binary128 &
Decimal128) already had emax/p ~ 144.98 & 180.71,
respectively.
The next two datatypes in the series of doubled types
(which would be Binary256 & Decimal256) would have
emax/p = 1106.09 & 22469.49, respectively.
Since these styles of datatypes are really intended for
the needs of, as you say, small fixed precisions, this
property means that the exponent is already more than it
generally needs to be &, if allowed to continue, would
grow much too fast for very large precisions. Especially
decimal.
Therefore, we wanted to remove the constraint that the
exponent continues to grow with increasing precision.
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.
The value of that constant was somewhat arbitrary &,
as I mentioned, the others left the choice up to me.
I chose c = 1000 on the grounds that it fits neatly
between the existing datatypes & any new ones that might
come along. I could have chosen c anywhere in about 200
to 1100 & been OK. I chose 1000 because it is 3 decimal
digits & 10 bits.
Perhaps that was a silly reason but it allowed me to sell
the choice to the others &, as I said, it was not intended
as a real constraint.
The constraint only kicks in when p >= 237 bits in binary
or p >= 51 digits in decimal. See 3.7. That is, the
'constraint' is actually the loosening of the defined
format constraint on emax which would exceed 1000 at those
two points.
Further, it allows a constant choice of emax = 2^31 - 1
up to quite large precisions. Larger than even you go
most of the time, I'll wager.
It is a compromise. It is my fault. If it causes pain
to future generations I'll bequeath to you the location
of my grave as recompense. :-)
Still it was my hope that more people would be helped
than hurt.
Time will tell,
Dan
>
> > . . .
>
> --
> 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)