Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Multi-precision (was...Please give me advice)

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