Re: MidRad and reproducibility
On 2009-09-21 14:15:45 +0200, Arnold Neumaier wrote:
> Vincent Lefevre wrote:
> >Well, not so obvious as some interval arithmetic packages don't
> >guarantee this property. An example in Maple + evalr. IMHO such
> >implementations must not be called interval arithmetic, but one
> >can't stop people from using wrong terms unless there's a standard
> >that makes everything clear.
>
> One can still call an implementation interval arithmetic if one does
> not claim to conform to the standard. A user needs to read the
> claims made, whether the claim is for rigorous enclosure or for
> conformance
> to a standard.
People are often inaccurate about their claims. Having a standard
allows one to avoid such inaccuracies.
> >I recall that I do not seek to require reproducible results.
> >It is not clear that infsup will require that either anyway.
>
> The Vienna Proposal implies reproducibility for any computation
> using only operations that are declared as tight.
Yes. However, for an obvious reason (lack of tightest interval),
there would not be a tight accuracy mode for midrad. Then, about
the other accuracy modes...
> If allowance is made for extra-tight interval operations using
> internal higher precision, this would be another data type, and
> again conformance to the standard would imply reproducibility for
> such results.
I didn't mean that. For the 'accurate' accuracy mode, think of the
same algorithm implemented over two different FP arithmetics, one
with extended precision and one without. So, midrad would allow
different results, just like the 'accurate' accuracy mode.
> Can you please give an example of what beyond enclosure you want to
> require from an implementation of midrad multiplication?
1. Something about the accuracy (i.e. an accuracy mode 'accurate',
which would have some additional requirements, and an accuracy
mode 'valid').
2. Something about the midpoint of an interval. If you evaluate
yy = f(xx), what's the relation between mid(yy) and f(mid(xx))?
Do we have correct rounding or some error bound?
3. Possibly a specification of the exceptions (like this will be
done for infsup). Could be optional.
I think that since midrad is more targeted at performance-critical
applications [in multiple precision] (if performance doesn't matter,
infsup should be better), the representation should be left to the
implementation.
> >But it is not true that IEEE 754 does not standardize multiprecision.
> >It doesn't mention multiprecision explicitly, but it doesn't exclude
> >it either. Multiprecision can be seen as supported via the section
> >on the extended and extendable precisions (the binary representation
> >is left to the implementation). And this is better than nothing.
> >
> >So, why shouldn't something similar be done for interval arithmetic?
>
> We have that in Motion 6. And by not explicitly mentioning midrad in
> the standard, we do the same as does IEEE 754 with multiprecision.
No, Motion 6 excludes midrad (see 3.5.2 and 3.6.2 for instance,
and since most of the motion depends on them, there's almost
nothing left applicable to midrad).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)