Re: Midpoint paper (2012-02-08 version)
The specification of interval arithmetic operations in the Level1 draft is
Level 2 op2(x,y) is
op2(x,y)=hull_T(op1(val(x),val(y)))
val is identity map from Level 2 to Lebel 1 (b in Table1)
hull_T is a in Table1 .
Though this definition was intended for mapping TxT -> T, it is easily generailized to
mapping T1xT2 -> T .
x: T1, y: T2
op2(x,y): T = hull_T(op1(val(x),val(y))) .
It would be good to have similar definition for numeric operations that are
mappings T -> F .
mid_F(val(x))
The "mid_F" maps level 1 intervals to F. It doesn't now about datatype of T .
> When I suggested a while back that a floating point format F should be associated to T as part of its definition,
> I seem to recall this was pooh-poohed as unnecessary.
> But the current discussion shows, IMO, that it IS necessary, and might indicate some requirements for such an F.
It still seems to me that it is not necessary to associate a single format F to the definition of implicit type T.
There may be a relation between T and F "F is mid-dense for T" that says that
"mid_F(x) is contained in x for each x \in T".
But this is a relation, not function from T to F .
For example all is correct:
"Binary32 is mid-dense for infsup_Binary32"
"Binary64 is mid-dense for infsup_Binary32"
"Rational is mid-dense for infsup_Binary32"
==============
Another question is how much mid_F((u,v]) and rad_F([u,v]) are related to hull_T([u,v]) of midrad type derived from F T=midrad_F
The level 2 draft defines datatype T with minimal requirements (Empty, Entire, hull),
but it mentions infsup_F and midrad_F datatypes. What can we say about their hull_T operation.
When T=infsup_F, the hull_T is unique and it is defined by standard. It can be expressed by inf_F and sup_F numeriv functionx.
Let x=[u,v] - nonempty level 1 interval.
hull_T(x)=[ inf_F(x) , sup_F(x) ] .
When T=midrad_F={<m,r>=[m-r,m+r] | m \in F, r \in F, m and r are finite, r >= 0} + {Empty,Entire} + {[u,+oo[ | u \in F } + {]-oo,v] | v \in F }
the hull_T can be defined in different way. Standard doesn't specify it now.
What about such a suggestion:
Standard specifies hull_T for T=midrad_F datatypes and the standard definition of hull_T for T=midrad_F
is related to definition of numeric operations mid_F and rad_F:
hull_T(x)=[ mid_F(x)-rad_F(x) , mid_F(x)+rad_F(x) ] .
The formula for rad_F([u,v]) from "Midpoint paper" can be derived from the requirement
that [ mid_F(x)-rad_F(x) , mid_F(x)+rad_F(x) ] is a hull.
Definitions of mid_F([u,v]) and rad_F([u,v]) for finite [u,v] from "Midpoint paper" are sufficient
to the interval [ mid_F(x)-rad_F(x) , mid_F(x)+rad_F(x) ] to be a hull.
The hull requirement implies that rad_F([u,+oo[) is +oo for semi-infinite and infinite intervals,
but it doen't imply much aboout the mid_F([u,v]).
-Dima
----- Исходное сообщение -----
От: j.d.pryce@xxxxxxxxxxxx
Кому: dmitry.nadezhin@xxxxxxxxxx
Копия: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Вторник, 14 Февраль 2012 г 16:28:04 GMT +03:00 Москва, Санкт-Петербург, Волгоград
Тема: Re: Midpoint paper (2012-02-08 version)
Dmitry and other participants in this discussion
On 10 Feb 2012, at 19:06, Dmitry Nadezhin wrote:
> So the question that bothers me is:
> What properties do we expect from width(X)/midpoint(X)/radius(X) when
> X is of implicit interval type or X is of explicit interval type of wider number format ?
Remember that a general implicit type has essentially NO structure. It is an arbitrary finite set T of mathematical intervals that includes Entire and Empty. I don't think anyone would object if we restricted attention to symmetric types (X in T implies -X in T) so feel free to assume that. And, probably relevant to the present discussion, it has a hull operation as part of the definition.
But AT PRESENT it has no Level 2 number system associated, whether fixed point or floating point, or Aztec (was it?) quipus of knotted string.
When I suggested a while back that a floating point format F should be associated to T as part of its definition, I seem to recall this was pooh-poohed as unnecessary. But the current discussion shows, IMO, that it IS necessary, and might indicate some requirements for such an F.
John Pryce