Re: P1788/M0014.01: 6.1_and_6.2 (compatibility with multi-precision)
> Subject: P1788/M0014.01: 6.1_and_6.2 (compatibility with multi-precision)
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Date: Sun, 2 May 2010 09:27:43 +0100
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dan, Michel, P1788
>
> So far we seem to have these conclusions about multi-precision:
>
> 1. (optimistic) Paul Zimmermann says that the MPFI system is
> based on a sequence of binary_N formats for (in principle) any
> N>1. Assuming each of these is of the required level 2 kind,
> this seems to make MPFI fit into the level 3 framework of 6.1,
> 6.2.
This also fits well with the optional formats permitted
in 754-2008. Both Paul & Vincent had a hand in making
sure this was so.
>
> 2. (optimistic) For multi-precision systems using (mid,del1,del2)
> format or the (x0,ex,ee) format mentioned in Vienna 1.6 para 3,
> what Dan and Michel say persuades me that for *narrow* intervals,
> the systems either fit into the required "sequence of formats"
> framework, or can be coerced to it by modest outward rounding with
> insignificant loss of accuracy.
Yes. This should be true for any suitable tower of
formats. It need not be so dense as to have a format
for every N of precision.
>
> 3. (dubious) Intervals like Dan's example, say xx = [10^-N,10^N]
> for "large" N. I don't think the (x0,ex,ee) form has *any*
> satisfactory exact representation. So one would have to round
> out the 10^-N to zero. Presumably there are restrictions on the
> (mid,del1,del2) form (for storage economy etc.) that make it
> similarly unsatisfactory for this kind of interval. Dan?
>
> John
I think you summarize it well, John.
(Except for the part where the example you credit
me with is actually Michel's, I believe. :-)
I think the 'exact extraction of bounds' clause of
6.1 is necessary for sensible interconvertability.
Even though this requirement puts a burden on the
entry(exit) of data into(out of) the mid-rad form.
Without it, invisible things can go on & never be
debugged.
However, we have not yet settled the issue of
exactly reproducible behavior of functions or
operations from one system to the next, either
required or optional. And, while I was once a
strong supporter of this in the absolute sense,
I now believe that the importance of the mid-rad
form requires us to be flexible in this. At least
to some degree. We must still have the option of
exact reproducibility, I believe, but perhaps we
can permit each conforming implementation to choose
its own best default. Within some reproducible &
testable constraints, of course.
As for whether or not a given (mid,del1,del2) form
is suitable for storage & computation, I think that
depends on the cleverness of the implementer. In
this case, the flexibility that the radii might be
of substantially lesser precision than the midpoint
introduces the possibility that one could package
it all up in a very useful form.
As a standards body I think our best bet is stay out
of this as much as possible & leave it largely up to
the implementer or the language standard.
The 'dubious' nature of my concerns surround the
problem that mid-rad intervals represent a quite
different subset of the Real intervals than do the
inf-sup forms. I believe that it will require us
to burden mid-rad forms further to represent these
intervals (like [1e-100,1e+100] & [3,+oo]) somehow.
Is it sufficient to represent them as say,
(5e+99,0,1e+100) & (something+3,-something,+oo)?
I don't really know.
There are better experts out there that can answer
questions like this.
Anyone want to take a stab at it?
Dan