Re: Up-to date Interval Arithmetic
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.
> 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 floaqating-point computation. In IEEE
> P1788, however, they appear like a cuckoo's egg. It unnecessarily
> complicates the implementation of interval arithmetic
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.
> and the understanding of it for every user.
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:
> It carries the potential of preventing interval arithmetic from wide
> spread usage.
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.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)