Re: Exceptions vs NaN/NaI
Yes, I know about "totalOrder" predicate.
Moreover, current JDK methods
class java.lang.Float {
int compareTo(FLoat anotherFloat);
static int compare(float f1, float f2);
}
class java.lang.Double {
int compareTo(Double anotherFloat);
static int compare(double d1, double d2);
}
are consistent with "totalOrder" relation.
Unfortunately, such compareTo is inconsistent
with comparison operations "==", "<", ">", "<=", ">=" :
d == Double.NaN is always false;
d < Double.NaN is always false;
but
compare(Double.NaN, Double.NaN) == 0;
compare(0.0, Double.NaN) == -1 .
This inconsistence is unavoidable with 754-types.
It explains why I resist to add NaNs to ExtendedRational .
The P1788 standard doesn't depend much on NaNs .
Possible it will be used in numeric functions only.
JVM binding of numeric functions could produce NaN results
by "throw new ArithmeticException();" statements if it can't produce it
by "return" satetemnt (when result type doesn't contain NaNs).
I understand that such implementation will not be 754-conforming,
but I would be happy if NaN was not mandatory in P1788 ,
and such implementation could be considered simply conforming .
Perhaps, my goal to keep my interval library P1788-conforming is a wrong goal.
Perhaps, the scope of P1788 is to specify intervals that
will be supported by hardware in the future.
The ExtendedRational surely is software-only implementation.
P1788, please say this to me, if you believe that
discussion of software-only arbitry precision libraries
shouldn't distract the group from development of P1788 hardware-implementable standard.
I can stop to produce arbitrary-precision noise here,
and narrow the scope of my future posts.
-Dima
----- Исходное сообщение -----
От: j.d.pryce@xxxxxxxxxxxx
Кому: dmitry.nadezhin@xxxxxxxxxx
Копия: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Понедельник, 7 Май 2012 г 21:05:35 GMT +04:00 Абу-Даби, Маскат
Тема: 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