Re: DirectedInf
Nate Hayes wrote:
Arnold Neumaier wrote:
Nate Hayes wrote:
Arnold Neumaier wrote:
After carefully checking the statements in the standard,
I am sure that one can make things 754-conforming by defining the
new concept of an interval-point format, which agrees with the
floating-point format on finite reals but differs on the treatment
of inf and NaN. Then none of the constraints on floating-point data
apply for interval-point data.
But the same hardware can be used with a switch of rounding modes,
and the exceptions can be handled as required for fast interval
support.
One thing that still worries me is that in Vienna Proposal it appears
the method requires that -0 and +0 are not aliases of each-other.
Why is that an obstacle?
Because many years ago we tried developing an interval library that
followed these concepts, e.g., [-0,+0], [-0,-0], [+0,+0] were invalid
constructions and intervals like [-0,3] and [+0,3] were not equivalent
aliases of the interval [0,3].
This is a Pandora's box, and was an implementation nightmare.
You misunderstood the detailed specification in Section 7.
Of course, if [-0,3] and [+0,3] represent two different intervals, this
produces lots of troubles.
But an implementation according to Section 7 of the Vienna proposal
declares [-0,3] an invalid interval, so [0,3] has the unique
representation [+0,3], and [0,0] has the unique representation
[+0,-0].
In this way, the problems are avoided while the benefits can be reaped.
My suggestion is to try making DirectedInf depend _entirely_ on the
rounding modes and not on the signs of the zeros. If you can do this,
then I think you may have a chance at a good design.
Try again, with the new information given above, and you'll see
that the sign of zero is an advantage rather than a burden!