Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Balance

Dear George and others,
thank you for your mail. This is a mail I really enjoy! An interval arithmetic standard should be as simple as possible.
The plenty of mail I am getting every day exceeds my capacity. So I cannot comment on everything as I perhaps should. Sorry for that. 

Let me first comment on a few minor things.
1. I remember several mails where simultaneously 'inf' is used as an abbreviation for infinity as well as for infimum (the greatest lower bound). Can't we avoid this? infty or +oo would be better abbreviations for infinity. 2. Frequently intervals like [-inf, a], [b, +inf] or [-inf, -inf], [+inf, +inf] appear, immediately followed by the sentence that "the bounds -inf or +inf are not elements of the set". I think in such cases it would be much better to use parantheses instead of brackets. This is fully consistent with IEEE P754. The intervals then would be written as: (-oo, a], [b, +oo), or (-oo, -oo), (+oo, +oo) respectively. The latter two notations would naturally indicate that the set is empty. 
3.Formulations like:
"NaN, -inf, +inf, and 0 denote any floating-point number x such that value(x) is undefined, -inf, +inf, and 0, respectively; it is assumed that such floating-point numbers exist. inf and +inf are used synomymously." should be avoided. NaN is not a number and consequently not a floating-point number. IEEE P754 distinguishes between floating-point numbers and floating-point data. Every floating-point number is a real number! 4. Can anybody tell me whether the Hausdorff metric can be defined for extended intervals?
Of course computing with result verification often makes use of floating-point computations. If executed in IEEE P754 this may result in an exception. So the question remains how exceptions like -oo, +oo, NaN, -0, +0 can be reasonably maped on floating-point intervals.
I personally have no preferences. But I think the following would be reasonable. -0 and +0 can only mean 0. Since NaN is not a real number it should be mapped on the empty set and since -oo and +oo are also not real numbers I think their image should also be the empty set independetly of how they have been obtained.
The reason for a lot of confusion seems to be that a number of colleagues believe that the question is asked how interval arithmetic can be defined within or upon IEEE P754. This is the wrong way to consider the problem. Interval arithmetic (over the real numbers) is part of pure mathematics. All conceptes like arithmetic operations, comparison relations, distances, convergence, etc. are clearly defined terms of pure mathematics. The development of a standard should start with these concepts.
This pure interval arithmetic can be approximated with no exceptions on the set of floating-point numbers. The resulting arithmetic operations and comparison relations are summarized and hardware circuitries for these are developed in the Kirchner/Kulisch paper. I talked about this paper at the SCAN meeting at Fukuoka in 2004. The paper was later published in 'Reliable Computing'. I attach a copy of that paper to this mail.
I am deeply convinced that a future interval arithmetic standard must require hardware support for interval arithmetic. If we do not explicitely require this we will not get it. If we don't get hardware support for interval arithmetic large interval computations will get lost in case selections for multiplications and divisions and in simulations of the rounding mode. There is no similar situation to be compared with in floating-point arithmetic. In a letter to IEEE 754R the IFIP Working Group 2.5 on Numerical Software also has required hardware support fo interval airhtmetic. I attach a copy of that letter to this mail.
Success of interval mathematics is based on two arithmetical features: One is double precision interval arithmetic. The second is variable precision interval arithmetic. This is another rquirement in the letter of the IFIP Working Group 2.5 on Numerical Software to IEEE 754R. An exact scalar product for the data format dopuble precision is the basic tool to achieve high speed variable (dynamic) precision arithmetic for real and interval data. Pipelining gives it high speed and exactitude brings very high accuracy into computation. With operator overloading multiple precision interval arithmetic is very easy to use.
With a variable precision interval arithmetic, for instance, highly accurate enclosures of orbits of dynamical systems have been obtained for considerable long durations. Iterated defect correction is another important class of applications. The method can be applied to compute enclosures of arithmetic expressions or of polynomials with very high accuracy. The result is an enclosure as a long precision interval. Verified solution of badly conditioned systems of linear equations by use of the Rump-operator is another large class of important applications. All these and other applications of an exact dot product come with very high speed.
For convinience I also attach the paper I prepared for the proceedings of the Dagstuhl meeting (held in January 2008). See also my new book on "Computer Arithmetic and Validity". 

Best regards
Ulrich Kulisch

--
****************************************************
Ulrich Kulisch
Universitaet Karlsruhe
Institut fuer Angewandte und Numerische Mathematik
D-76128 Karlsruhe, Germany
****************************************************




Corliss, George schrieb:
Friends, 
To be successful, the standard must reflect
   Theoretical understandings of the academicians
   Practical trade-offs of those who will implement it
   Needs of practitioners who will use it

It should be based on a relatively easy-to-explain model, but it may have
some inconsistencies.

It should be mostly straightforward to implement, with a few features that
require thought and care.

It should not violate the Principle of Least Astonishment for practicing
scientists and engineers, although some features may require learning.

These should be present in roughly equal measure.  So far, I mostly see the
academicians.  I fear some proposals might be impractical to build and less
than helpful for the practicing scientist and engineer.  If the experts
struggle to understand, how will the undergraduate engineering students
suffering through a required class react?

Dr. George F. Corliss
Electrical & Computer Engineering
Haggerty Engineering #296
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee WI 53201-1881
George.Corliss@xxxxxxxxxxxxx
414-288-6599; -288-4400 (GasDay); -288-5579 (Fax)
Www.eng.mu.edu/corlissg

Attachment: paper.pdf
Description: Adobe PDF document

Attachment: IFIPWG-IEEE754R.pdf
Description: Adobe PDF document

Attachment: ARITHYY.pdf
Description: Adobe PDF document