Re: Motion 6
Dear Arnold,
> > How about a different motion that would generalize Motion 6 to
> > support midrad and other interval sets? (But some concepts, such
> > as the tightest FF-interval, would no longer exist.)
>
> I'd prefer a motion to exclude midrad from consideration.
> We have more than enough to do for infsup, and most considerations for
> midrad are completely different than those for infsup, so that virtually
> everything done for infsup would need to be reconsidered carefully.
> As a result, the work load would nearly double.
>
> Nobody in practice uses midrad as a basic representation,
> except for input/output, where only the conversion behavior
> needs to be specified, but not the arithmetic.
this is wrong. The iRRAM package (http://www.informatik.uni-trier.de/iRRAM/)
uses the midrad representation with 'mid' in arbitrary precision and 'rad'
in fixed precision. See Section 5 (Simplified Interval Representation) from
http://www.informatik.uni-trier.de/iRRAM/irram.ps.
> Midrad arithmeitc is used only (in Intlab) as a speedup mechanism
> on the BLAS3 level, and doesn't need special standardization.
> Moreover, putting BLAS2 and BLAS3 considerations into the standard
> seems to me inappropriate.
>
> Arnold Neumaier
I agree that in fixed (say double) precision, midrad might not be superior.
But in arbitrary precision, you get a speedup >1 by using different precisions
for 'mid' and 'rad'. Thus excluding midrad from P1788 might exclude de facto
efficient applications using arbitrary precision arithmetic.
Paul Zimmermann