Re: >>: Exceptions vs NaN/NaI
Dmitry
On 20 Apr 2012, at 16:15, Dmitry Nadezhin wrote:
> Now ExtendedRational is total-ordered type (it implements Java interface Comparable).
> I don't like an idea to add NaN to ExtendedRational, because it will loose total order.
> And now I try to understand if I will be forced to add NaN.
I appreciate adding NaN to your ExtendedRational type seems to entail making some rather annoying changes. But I feel that for the benefit of interval computation as a whole, NaN should be mandatory rather than optional (as a value that numeric functions of intervals can return).
754 has faced this problem of course: the non-NaN values of any FP type could be thought of as implementing the Comparable interface, and NaN spoils that.
However IEEE754-2008 §5.10 defines the *totalOrder* predicate:
"totalOrder(x, y) imposes a total ordering on canonical members of the format of x and y".
For non-NaN values it is roughly the same as the normal order <=. Could you take a leaf out of 754's book? E.g. if you wish to just have one NaN datum at Level 2, you could define a totalOrder(x, y) which is the same as x <= y for numeric datums, and makes x < NaN for all numeric x. This would be the one that implements Comparable.
John Pryce