Re: formatOfMidpoint()
On 2012-02-15 18:24:36 -0800, Dmitry Nadezhin wrote:
> > If can be interesting to introduce a notion of a number format F
> > "compatible" with an interval type T. The conditions could be:
> > * For each x in F, [x,x] is an element of T.
>
> I think it should be "For each finite x in F".
Yes, but I think that this condition should be dropped for
formatOf midpoint (in order to allow to use a more precise
format than the one of the endpoints of an inf-sup type).
> > * Each non-empty interval of T must contain an element of F
> > (or, equivalently, a point interval of T).
> >
> > In particular, for such a number format, it is possible to define
> > a midpoint operation such that the Level-2 result (element of F)
> > is in the interval. Not sure whether it should be required that
> > such a number format necessarily exists, specially if you want to
> > allow:
> >
> > > This might also be the case for some of the off-center implicit-format
> > > examples, where the issue is not range but precision: if the Level 1
> > > interval is entirely between two representable target-format values,
> > > then there is no representable midpoint, and the result should be NaN.
>
> Consider interval type T. Let's look when a format F "compatible"
> with T exists. It can be formulated without mention of F.
> (Singletons) "Each non-empty interal of T must contain a point
> interval [x,x] of T" If this condition true, then F is unique. It
> must consists of nubmers x related to all point intervals [x,x] (and
> also infinites).
If this condition is not regarded as too strict (I don't think it is),
then I agree. This means that one would have a canonical notion of
number format associated with an interval type. Any superset number
format could be regarded as compatible.
> The condition may fail for some artifical interval types.
> Consider midrad_F-like type without point intervals.
> T={[m-r,m+r] | m \in F, r \in F, m and r finite, r > 0} \union {Empty,Entire}
Yes, I think that such types are too artificial and useless.
> It seems that useful interval types satisfy the (Singletons) property.
I also think so.
> Perhaps, this property could be a part of definition of interval type.
I agree.
> However, the resulting unique number format may be unusual.
> The tripple (fromer midradrad) format <x,i,s>=[x+i,x+s] , x \in F, i \in F, s \in F
> satisfies (Singleton) property. The set of point intervals is double-F numbers
> { x + y | x \in F, y \in F }.
Not so unusual: such numbers are element of a double-double arithmetic.
Anyway IMHO, such an interval type is quite special, so that this is
not a real problem. In practice, I suppose that one can use a type
where i <= 0 and s >= 0, and the above problem disappears.
> But these numbers can be easily represented by point T-intervals.
>
> I look through some usages of numeric operations to see if they can
> be replaced by nonarithmetic interval opearations.
IMHO, one should still have the possibility to get numeric results
from a compatible type (e.g. to be able to get an exact midpoint;
see above).
> ===== split: T->(T x T)
>
> For infsup-F formats the split operation can be formed using midpoint operation from the "Midpoint paper".
> split([u,v])=([u,midpoint([u,v])], [midpoint([u,v]),v])
>
> This works also for triple formats
> split(<x,i,s>)=(<x,i,midpoint(i,s)>,<x,midpoint(i,s),s>)
>
> However, split operation can fail some intervals of midrad_F type.
I don't think this is a problem: with any interval type, if the split
interval is too small (even for inf-sup, where u and v are consecutive
numbers), splitting doesn't make much sense.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)