Re: Table 4 proposal version 0.2...
On 02/29/2012 04:11 PM, Dan Zuras Intervals wrote:
I still have no good answer for midpoint(Empty) so that
is still not part of this proposal. However, I disagree
with some that it should be NaN on several grounds.
I believe the user would be better served by an arbitrary
choice such as 0
Could you give a concrete example how it would serve the user better?
than by introducing errors into a
potentially error free standard. That goal is worth the
occasional arbitrary choice, IMHO.
An arbitrary choice is arbitrary, and hence more error prone than the
canonical choice NaN.
Your interpretation of ''error free standard'' as ''NaN-free standard''
is arbitrary, too. NaN is anyway most natural for the bounds of the
empty set, so the midpoint comes out correct without an extra case
distinction for the empty set. The simple formula
m = inf(X)+0.5*(sup(X)-inf(X));
if isfinite(m), mid(X)=m; else mid(x)=NaN; end;
which returns the left or right closest machine number to the midpoint,
would have to be patched up by an extra case, just to introduce an
arbitrary choice in place of the natural result.
There are a number of arguments that wid/mag/rad should
all return -inf for Empty. Indeed, I use a similar line
of reasoning with inf(Empty) = +inf& sup(Empty) = -inf.
These are the standard conventions in mathematics, hence they have a
canonical status. They are _very_ natural for a mathematician, and often
useful, as they save one from extra case distinctions.
Changing long-established conventions (for the sake of a dubious quality
criterion) is never a good idea. A tiny community of interval analysts
(who isn't even unanimous about it) will never have enough weight to
undo the older, far more widespread, and usually very useful convention.
Arnold Neumaier