Re: Motion 45
Dear Ulrich
On 2013 Aug 1, at 05:42, Ulrich Kulisch wrote:
> Well defined interval arithmetic over the real numbers (or the subset of floating-point numbers) including CA and the EDP leads to a calculus that is free of exceptions. We must not make the mistake defining interval arithmetic over all IEEE 754 datums!
I absolutely agree with the last sentence. That is why I have been so concerned to define Level 2 precisely. An interval datum is essentially a mathematical interval. An interval type is a finite set of mathematical intervals. Operations *purely* on intervals are defined by doing the mathematical operation, then mapping the Level 1 result down to Level 2 by taking the appropriate interval hull. No mention of representation, or of floating point!
But generally I disagre with the conclusions you draw, and agree with what Vincent and Juergen have written on this. You say "... many members of the group take IEEE 754 arithmetic as basic truth for scientific computing". No way! If we did then indeed "The development of IEEE P1788 [would suffer] from the fact".
Your observations about "(+oo)×0 = 0 in interval arithmetic" etc. are true & important but refer to *a particular implementation* of operations on the datums under *a particular representation* (inf-sup), not to the datums or operations themselves. i.e. they are about Level 3.
The Level 2 devil comes in -- and there is no complete cure for this -- at the interface between number datums and interval datums, including but not restricted to
- an operation on number(s) that produces an interval (a constructor);
- an operation on interval(s) that produces a number (midpoint etc).
It is to "tame" this that Vincent created Motion 33 on number formats, which aims to formalise what 1788 does and does not assume about this interface.
CA+EDP in itself is about numbers, not intervals. So is Motion 45. But in addition it is about numbers represented the IEEE 754 way, which means we must pay respect to the 754 standard. I suppose CA, when adding a whole lot of zeros, doesn't check whether they were all +0, all -0, etc? But to be consistent with 754, the Motion 45 text must take a stance on this. This will make *no* difference to the behaviour of intervals constructed as a result, but if done well should make for faster or more readable code in some extreme corner of an implementation.
There is another quirk of 754 that annoys me but we can't do anything about it. In the reduction operation clause §9.4, it says that for sumAbs and sumSquare, Inf "beats" NaN. E.g. sumAbs of the vector (1,Inf,NaN) is Inf, not NaN.
I presume this derives from an interpretation of NaN as "an extended-real number that happens to be unknown", which conflicts with the interpretation I believe appropriate in 1788 for both NaN and NaI, namely "something went wrong earlier!".
John Pryce