Re: Multi-precision (was...Please give me advice)
The listserver had rejected this, claiming I had sent it before.
But I sent this only once. Thus I try again....
John Pryce wrote:
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'.)
It should not, as it has the same problems as mid-rad in representing
intervals such as [1,inf].
* 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?
Whatever format is finally made madatory, an arbitrary-precision
arithmetic with triplex data
(x,el,eu) = [x+el,x+eu] (x arbitrary precision, el, eu double)
(as in brent's old iinterval multiprecision package)
should be allowed as a valid inf-sup idatatype. It has the accuracy
advantages of the midrad format without its weaknesses of not being able
to represent
unbounded intervals.
I am not sure, though, whether Motion 19 ensures that.
(Anyway, I am against supporting Motion 19 on grounds of complexity
and for reasons already mentioned in a previous mail.)
Arnold Neumaier