Re: mid-rad, inf-sup, a caution...

[Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>]

Ralph Baker Kearfott wrote:
> Arnold,
>
> Thank you for your input and clarification.  Are there
> additional comments concerning this?  Should mid-rad be
> standardized as an optional type?

My recommendations are known for more than a year; they are part
of the Vienna proposal. The subsequent discussion has not altered
my views.

Mid-rad should be supported in in/out conversion, and by providing
routines for computing the closest approximate midpoint and the
radius as the smallest representable upper bound on the distance
from the approximate midpoint.


More is not needed, and more should not be supported.

This also conforms exactly with what is in Intlab in terms
of user-accessible support.


On the other hand, not supporting infsup (i.e., making it optional)
is disastrous for applications in global optimization where the ability
to represent and manipulate intervals such as [0,inf] without
overestimation is essential!


Midrad has no advantage over infsup, except for multi-precision
calculations of exactly representable problems (without any input
uncertaimty), and in the latter case, a triplex implementation
(with multiprecision midpoint and a standard interval remainder)
is far superior with respect to ease of implementability (given
infsup arithmetic) and speed.

In particular, I have never seen an implementation of midrad
arithmetic that is safe in finite precision arithmetic and
as fast as infsup arithmetic, and I doubt that such an
implementation exists. If one exists, it should be pointed out
by the proponents of midrad arithmetic.

I even doubt whether any existing implementation of midrad
arithmetic has been applied to more than demonstration examples.

I bet that 99.9% of all applications work with infsup intervals,
and nobody ever complained about their limitations.


Arnold Neumaier