[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Reproducibility of minNum() and maxNum() for decimal
Here is something that we should have noticed months ago... but I
only realised this when David Hough wrote "except for minNum() ..."
in a draft of a possible revision of Clause 10.
The definition allows either operand to be returned when both are
numeric and compare equal, i.e. have the same value.
I feel it would be preferable to return the operand with the maximum
quantum. In this way, these functions are commutative. Returning the
operand with the maximum quantum avoids attaching undeserved precision
to the result.
min/max are the only operations in clause 5 that could be, but aren't,
specified to be
commutative in the usual 754r way (which respects signs of zeros and quanta but
ignores the signs and payloads of NaNs - signs of zeros makes it an issue in
binary as well as in decimal).
The originally commutative specification was relaxed to accommodate performance
of
implementations with existing hardware, on the theory that anybody that cared
about a total ordering would use the totalorder predicates instead.
This is an archetypal discussion: does one match the spec to some existing
hardware
or match the spec to programmer expectations in
hope that some future hardware will match the spec?
If a specified operation is too slow on some or most implementations compared to
a readily available alternative that is often satisfactory, it might not be used
at all, and hence will never generate the benchmark pressure to go into
hardware.
From the point of view of making the entire standard understandable, I tend to
react
negatively when I must write a statement that is generally true and then list
a bunch of specific gratuitous exclusions.
While we can't make a floating-point standard as compact as
the axioms of the real numbers, we don't want it to look like the internal
revenue
code either.
This discussion suggests to me that min/max should be either be made commutative
for signed zeros and quanta in clause 5 or moved to the optional clause 9 where
the other less-strictly-specified operations are defined, that violate some of
the generalizations about clause 5 operations. Most of the BRC members,
thinking their work is done, will not be keen for either change.