Re: Multi-precision (was...Please give me advice)
Paul, P1788
On 12 Oct 2010, at 13:58, Paul Zimmermann wrote:
> ...As Dan said, this motion is a
> hard one, where people on the list have strong opposite opinions. An extended
> discussion period would be welcome, and the revised motion --- if any ---
> should clarify what are the exact consequences for the standard. In particular:
>
> * would a multiple-precision implementation that only implements mid-rad be
> compliant? (With a multiple-precision 'mid' and a fixed precision 'rad'.)
>
> * would a multiple-precision implementation that only implements the triple
> representation (x, inf_err, sup_err) mentioned in P1788_MAIN.pdf, paragraph
> 6.1, be compliant? (With multiple-precision x and fixed precision inf_err
> and sup_err.)
>
> For example the iRRAM package (http://www.informatik.uni-trier.de/iRRAM/)
> is using a mid-rad representation (see Section 5 of
> http://www.informatik.uni-trier.de/iRRAM/irram.ps).
An important question. But my gut feeling is that, rather than this being a determining factor in how multi-precision people vote on motions 19.02 or 23, we should be looking at:
Can one regard a multiple-precision interval package (MPIP)
as being inf-sup, de facto if not de jure?
And possibly with small tweaks to how it operates?
I'm definitely no expert, but here's my £0.02.
1. In the context of iRRAM, don't consider whether its whole exact-real-computation system can be conforming (it seems pretty clear it can't, without changing P1788 drastically), but whether its MPIP infrastructure can be conforming.
2. I regard the existence of a hull() operation, for any i-datatype, as crucial. Hence, IMO MPIPs *must* be regarded as defining a (potentially infinite) sequence of i-datatypes IDbar_p, p=1,2,..., where each one is a *finite* set of intervals, with increasing precision as p increases; not as a single i-datatype that is the union of these sets.
Then conversion from an interval xx of some other i-datatype to the MPIP is "to some specified precision p", i.e. take hull_p(xx) where hull_p() is the hull belonging to IDbar_p. This makes sense once one has agreed point 1 above.
3. From a quick look at the iRRAM documentation, its MPIP can conform if motion 19 passes, provided it provides a couple of things it may not have at present: representations for Entire and Empty.
4. If we end up supporting only inf-sup, then a conforming MPIP, de facto, must conform to an inf-sup spec. This is surely possible, and natural, for the (x, inf_err, sup_err) representation. E.g. suppose we have Pi enclosed in
[3.14159265358979mmm, 3.14159265358979nnn]
where mmm and nnn are each 3 digits. Store this economically as
x = 3.14159265358979
inf_err = mmm
sup_err = nnn
with the interpretation that inf_err and sup_err actually mean 0.mmm and 0.nnn, in units of one ULP (unit in last place) of x. This implements an (18 decimal digit FP in this case) inf-sup format. One needs care when straddling a power of the radix, but that's a minor point.
iRRAM doesn't quite do that, but looking at the documentation it seems to use mid-rad m+-r in a somewhat similar way. Is it possible to restrict the r values chosen, so that they are related to an ULP of m? If that were done, would one effectively have an inf-sup representation? I would be interested in an answer.
I'm fairly sure Dan Zuras made a similar argument about mid-rad a while back.
John Pryce