Re: midpoint-radius representation

["Svetoslav Markov" <smarkov@xxxxxxxxxx>]

On 11 Nov 2008 at 10:18, Arnold Neumaier wrote:

 > 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).
> 

these items refer to computer implementation and could be
better discussed by Siegfried.

> (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''.
> 

The above mentioned formulas are indeed not constructive.
Simple formula is given in:

Markov, S., An Iterative Method for
Algebraic Solution to Interval Equations, Applied Numerical
Mathematics 30 (2--3), 1999, 225--239.
(see formula A3 in the appendix)

see also:

Kulpa, Z., S.  Markov, On the
inclusion properties of interval multiplication:  A
diagrammatic study, BIT Numerical Mathematics 43 (4), 741--810, 2003.

and the appended paper:

Markov S., D. Claudio: On the Interval Arithmetic in
 Midpoint-Radius Form.   Mathematics and  Education
 in Mathematics 33, 2004,  Inst. Math. and Informatics, BAS, 434-439.

Note that the formula for multiplication (12) is extremely simple and
valid for generalized (Kaucher) intervals as well. This is shown in my 
scan2006 paper (also attached, see there formula 39) and the 
presented algorithm.

> (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

Attachment: mmsc04ep.pdf
Description: Binary data

Attachment: Markov_scan06.pdf
Description: Binary data