NH> Keep in mind, Ian McKintosh has suggested replacing unbounded closed
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