A question Re: Level 1 <---> level 2 mappings; arithmetic versus applications
Dan,
On 6/30/2010 02:38, Dan Zuras Intervals wrote:
From: "Nate Hayes"<nh@xxxxxxxxxxxxxxxxx>
To: "Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx>,
"Christian Keil"<c.keil@xxxxxxxxxxxxx>
.
.
.
Let the mapping from level 1 to level 2 be defined by the
narrowest mapping possible. That is, of all the objects
that exist in your representation that represent supersets
of a given level 1 interval, let the mapping be to some
object which is a subset of all of them. There may be
many such mappings. And the are all, of course, equal in
the above sense.
I am wondering whether or not there may actually be "many such
mappings," or whether specifying the object which is "a subset of all
of them" specifies the mapping uniquely. For example, in the
inf-sup representation and 754 arithmetic, rounding the lower bound
down and rounding the upper bound up gives a uniquely defined interval,
it represents one such mapping, so any such object will have to
include the object so obtained, and there are no proper subsets constructed
from machine numbers that contain that object. Therefore, the
mapping in the context of inf-sup and 754 is unique (and hence would
lead to an arithmetic that is reproducible across implementations).
I suspect a similar uniqueness holds for various mid-rad schemes, or
is the interplay between the midpoint and radius a sticking point?
Now, with mappings back& forth we can define arithmetic.
Let any operation be defined by mapping its operand(s) to
level 1, applying that operation there, finding the
contiguous hull of the result there& mapping that result
back into your format in the tightest sense as defined
above.
By the way, I've also been wondering about whether or not
discussing whether or not Intlab's use of mid-rad is a bit
of a red herring. In particular, we are defining arithmetic
operations and conversions. Intlab's matrix multiplication is
a kind of "application" in which the result of a large number
of operations is returned. Just as in floating point computations
based on 754, error can accumulate beyond the unit roundoff
error specified by 754, the resulting intervals from a string
of computations cannot be expected to obey accuracy or other
properties specified by an interval arithmetic standard, except
for (if we so decide) conversion from its lower level representation
to a higher-level one (or visa versa, for input). (This is, of
course, assuming we do not define the function value(s) computed in
the application as a required or recommended function in our
standard.) The one
thing that such an application must obey, to satisfy the "proof"
philosophy of interval computations, is that it include
the exact result. Thus,
whether or not Intlab used mid-rad, inf-sup, or some weird
elliptical arithmetic such as mid-mid-rad-rad, would seem to be irrelevant.
(However, one goal of our standard is to make the writing of such
applications easier, more portable, and easier to debug or see their
correctness -- I'll review our PAR.)
Best regards,
Baker
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------