Re: Up-to date Interval Arithmetic

[Ulrich Kulisch <ulrich.kulisch@xxxxxxx>]

Am 30.03.2015 um 13:13 schrieb Vincent Lefevre:

On 2015-03-29 19:53:05 +0200, Ulrich Kulisch wrote:

Am 27.03.2015 um 15:31 schrieb Vincent Lefevre:

In addition to the problem of the meaning of "rigor", I don't
understand why:

1. The open interval J is valid.
For instance, take a = [1,1] and b = [2,2].
Then I = [RNDD(1+2),RNDU(1+2)] = [3,3]
 and J = (RNDD(1+2),RNDU(1+2)) = (3,3) = Empty

Dear Vincent:

Please let me know the rules with which you get the result for J?

In the text you sent:

  aa = [a_1,a_2] and bb = [b_1,b_2]

(where "aa" means bold "a"...) are closed intervals. I choose
a_1 = a_2 = 1 and b_1 = b_2 = 2, so that aa = [1,1] and bb = [2,2].
The operation is +. With conventional interval arithmetic, aa + bb
yields [RNDD(1+2),RNDU(1+2)] = [3,3]. So, I don't understand why
you are saying J = (RNDD(1+2),RNDU(1+2)) in your text.

I really do not say this. With a wrong statement you can prove everything. In my text the data of  the operands are different from yours and in unum arithmetic the brackets of the result depend on the data and on the backets of the operands. For the data in my example the brackets of J would be open and for the data in your example they would be closed.

Unum arithmetic delivers the closed interval for J also.

Concerning rigor let me say the following:
The book /Computer Arithmetic and Validity/ considers floating-point and
interval arithmetic as distinct calculi. It requires strictly to separate
the two. Naturally in interval arithmetic the IEEE 754 exceptions do not
occur. They may be reasonable in a floating-point computation. In IEEE
P1788, however, they appear like a cuckoo's egg.  It unnecessarily
complicates the implementation of interval arithmetic and the understanding of it for every user. It carries the potential of preventing interval arithmetic from wide
spread usage.

An implementer if interval arithmetic can safely ignore IEEE 754
exceptions if he doesn't need them. And for an interval arithmetic
implementation, you can do without them in general.

The user of interval arithmetic will never see an IEEE 754 exception
(as long as he remains under this context of intervals). So, I don't
understand why you say:

Or do you have a simple example explaining what is wrong with IEEE 754
and how it could be solved with a different underlying arithmetic?

AFAIK, the only practical problem *for an implementer* is something
like [0,0] * [-inf,+inf], because with the usual formula, you'll get
NaN for every term of the formula. So, there's a test to do... IMHO,
getting NaN for 0 * infinity is safer in rounding to nearest, but if
IEEE 754 had to be redesigned, I think that getting 0 would be better
in directed rounding mode because the directed rounding modes will
already provide the needed rigor. In any case, the stds-1788 list
is not the right place to complain about that, and you do not need
a whole new number format to change this rule.
e

Adding open and half-open intervals to conventional closed intervals as done by The End of Error  is a wise completion of interval arithmetic.

But I am not talking about that in my mail above. Hoping to find consent  let me try to explain my mail above  with other words:
The set D of IEEE 754 data consists of floating-point numbers of F and the IEEE 754 exceptions E,
so D = F +E. Arithmetic in D can lead to overflow, underflow, NaN, +oo, -oo, +0, -0, and so on. Arithmetic of IEEE P1788 deals with intervals of ID.
That routines developed in ID frequently work is due to the fact that arithmetic in IF is an exception-free closed calculus, i.e., an arithmetic operation for intervals of IF leads to an interval of IF again. The IEEE 754 exceptions are definitely not needed for developing interval arithmetic. Never in the many years I am working with interval arithmetic I needed to use constructs like NaN or NaI.
They came into the business because someone had the terrible idea to develop interval arithmeic over the set ID (= IEEE P1788). It really is  like a cuckoo's egg that someone put on interval arithmetic. A standard for interval arithmetic (IR and IF) could be much simpler than the present draft of IEEE P1788 if you strictly seperate interval arithmetic form IEEE 754 floating-point arithmetic.
I very much hope Vincent that you can do something on the matter. The standard should not be a shock for potential future users of interval arithmetic. 

With best wishes
Ulrich

-- 
Karlsruher Institut für Technologie (KIT)
Institut für Angewandte und Numerische Mathematik
D-76128 Karlsruhe, Germany
Prof. Ulrich Kulisch
KIT Distinguished Senior Fellow

Telefon: +49 721 608-42680
Fax: +49 721 608-46679
E-Mail: ulrich.kulisch@xxxxxxx
www.kit.edu
www.math.kit.edu/ianm2/~kulisch/

KIT - Universität des Landes Baden-Württemberg 
und nationales Großforschungszentrum in der 
Helmholtz-Gesellschaft