midpoint-radius representation
Svetoslav Markov wrote
[in '' floats and intervals, constants, 0.1, 1e400 and Inf'']:
On 10 Nov 2008 at 13:02, Arnold Neumaier wrote:
Though briefly discussed, I think nobody has shown strong emotions for
satandardizing mdpoint-radius interval representations.
I advocate against it.
I should like to declare myself as a strong supporter of
midpoint-radius interval representations.
Then let me state my arguments against including it as an intrinsic
representation of intervals in the standard.
(i) Specifying the knowledge x>=0 via mid-rad is impossible.
(ii) conversion from inf-sup to mid-rad and back imposes
a heavy loss of quality for wide intervals (as they are frequent
in applications to constrained global optimization).
(iii) Operations are awkward to define, even for addition.
In theory, midpoints and radii both add; however, the rounding error
incurred upon adding midpoints must be added to the radius.
The formulas for multiplication are messy and unduly expensive;
see Proposition 1.6.5 of my book ''Interval methods for systems
of equations''.
(iv) There is a possible accuracy advantage for mid-rad, but only
for extremely narrow intervals, which occur very rarely.
On the other hand, there is also an accuracy disatvantage for
representing narrow intervals, e.g., those whose endpoints consist
of two adjacent
(v) The standard should be as simple as possible, given the constraint
that all important applications can be performed efficiently.
The only support that I find reasonable are conversion functions
absUncertainFloatToInterval(value, abserr)
relUncertainFloatToInterval(value, relerr)
suggested yesterday by Michel Hack.
Arnold Neumaier