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

Re: OK, now I see Re: Motion P1788/M0013.04 - Comparisons - Overflow / Infinity



Nate Hayes wrote:
Baker Kearfott wrote:

Ah, yes, now I remember.  Even though we are working only
with real numbers, an interval can be bounded or not,
and we can distinguish that with a decoration.  However,
a consequence of the fact we interpret [a,Infinity) to
be a set of real numbers is [a,Infinity)*0 = 0.  Thus,
the question of the point product Infinity*0 does not
even arise.

Right.

...although it _does_ arise when computing the endpoints of an interval. So it is relevant to the _implementation_ of interval arithmetic operations. I think this was Ian's main point (no pun intended).

For example, _if_ IEEE 754 had made a distinction between Infinity and Overflow, then our interval arithmetic implementations would already have a fast floating-point operation Overflow*0=0 in hardware, which means computing the appropriate interval endpoint of the product:
   [1,Overflow]*[0,0]=[1*0,Overflow*0]=[0,0]
would already be performed fast and cheaply in hardware.

This would be good for all of our (currently slow) software implementations of interval arithmetic.

This is in contrast to how IEEE 754 arithmetic hardware as it _actually_ exists today yields:
   [1,Infinity]*[0,0]=[1*0,Infinity*0]=[0,NaN]
which according to Motion 5 is not the correct interval result. So it requires an expensive software routine to "fix" the [0,NaN] result and turn it into the correct [0,0] interval arithmetic result.

This is why the final part of the Vienna proposal suggests how the
arithmetic could be changed profitably to better support interval arithmetic. These changes affect _only_ directed rounding, and hence are of no consequence for most current applications, since these don't use the directed modes. So there is a hope that the next floating-point standard will correct that.