NH> intervals with "overflown" compact intervals. In practice, there is not
NH> really a difference between the two. For example, +INF and -INF are
NH> replaced by +OVR and -OVR in all compuations, where OVR is some unknown
NH> finite real number larger than the magnitude of the largest
NH> floating-point number. In this way, intervals such as [1,+OVR] remain
NH> compact intervals and are not unbounded like the interval [1,+INF].
NH> Arithmetic operations on the endpoints of compact overflown intervals is
NH> the same as in Motion 5, i.e., (-OVR) + (-OVR) = -OVR, 0 * OVR = 0, etc.
AN> But then OVR has a different meaning in different places, which is
AN> unacceptable from a mathematical point of view. It is just INF in
AN> duisguise, and it hides mathematical propoerties of the limit under
AN> the carpet. One cannot use it in a mathematical argument....
AN>
AN> To argue for existence, one _needs_ in certain case the unbounded case.
AN> Mathematical programming had once a tradition for using big M (which is
AN> about the same as your OVR), and it is now deprecated (though still used
AN> by a few who don't like unbounded variables) since it behaves poorly not
AN> only mathematically but also algorithmically.
I did suggest Overflow (OVR) as a better floating point value than Infinity to represent an overflowed value, and that it would be very often more useful as an interval endpoint.
In doing that I did not mean it to totally replace Infinity, and I did not mean they would have the same semantics. The whole point is to distinguish their semantics.
In IEEE floating point, you can get Infinity two ways. One is by dividing a nonzero by zero. The other is by overflow. The following mostly ignores signs for brevity:
IEEE nonzero / 0 = Infinity
IEEE overflow on any operation = Infinity
One problem with that is that you don't know whether you're dealing with an infinite value or with an overflowed value. You need to know to get the semantics of subsequent operations correct.
IEEE Infinity * 0 = NaNQ
NaNQ is the right answer for Infinity resulting from nonzero/0, but should be 0 if the Infinity was the result of an overflow instead. Clearly the two meanings of Infinity need to be distinguished.
Proposed nonzero / 0 = Infinity
Proposed overflow on any operation = Overflow
Proposed Infinity * 0 = NaNQ
Proposed Overflow * 0 = 0
Most of the other rules are straightforward. One mustn't be tempted to think that subtracting Overflow from itself gives 0 though. In floating point
Proposed Infinity - Infinity = NaNQ
Proposed Overflow - Overflow = NaNQ
while in Interval Arithmetic
Proposed (+Infinity, +Infinity) - (+Infinity, +Infinity) = (-Infinity, +Infinity) (assuming Real* to allow Infinity - if not then ignore this line)
Proposed (+Overflow, +Overflow) - (+Overflow, +Overflow) = (-Overflow, +Overflow)
and multiplying that by 0 gives
Proposed (-Overflow, +Overflow) * (0, 0) = (0, 0)
If Interval Arithmetic was based on IEEE 754 with Overflow added, some of the operations would be simplified because they would not have to handle special cases.
I think that IEEE and others before them, including CDC and Cray, erred in combining two concepts that must be kept separate for correctness. (Note the operations creating them do have separate exceptions.) Simplicity is essential, but oversimplification is trouble.
With this clarification that Overflow is not Infinity, and our agreement that Infinity (which I think you mean by the unbounded case) is also needed, do we actually disagree? Overflow simply means a finite value that's larger than the largest representable in the chosen precision, while Infinity means the mathematical infinity. They are both infinite sets. They are disjoint sets. In some contexts you could treat them the same way, in others you can benefit by distinguishing them. Maybe most importantly, adding Overflow to floating point not only improves floating point, it lets it be a better more meaningful representation for interval end points.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Arnold Neumaier ---09/19/2010 02:47:40 PM---Nate Hayes wrote: > Arnold Neumaier wrote: