Re: MidRad -- and Two Different Application Domains (TDAD).
On 2009-09-21 13:22:33 +0200, Arnold Neumaier wrote:
> Vincent Lefevre wrote:
> >There's no need to have a canonical definition or fix the algorithm.
> >The most important point is to have some properties that the result
> >satisfies.
>
> The enclosing property need not be standardized since it is obvious
> that any interval type must preserve this.
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.
> Any two different algorithms for computing an enclosure of the
> midrad product of two midrad intervals are likely to give slightly
> different results. Thus standardizing more is difficult without
> tying down the algorithm.
I recall that I do not seek to require reproducible results.
It is not clear that infsup will require that either anyway.
> >This is precisely what I want to avoid. Why should there be a standard
> >for small fixed precision, but not for multiple precision?
>
> For the same reasons as IEEE 758 did not standardize multiprecision
> arithmetic.
That's IEEE 754, and the main goal was to revise the old IEEE 754-1985.
That's why there's nothing explicit about multiprecision.
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?
--
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)