Re: Table 4 proposal version 0.1...
On 02/29/2012 03:23 PM, Vincent Lefevre wrote:
On 2012-02-21 17:20:47 -0800, 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 than by introducing errors into a
potentially error free standard. That goal is worth the
occasional arbitrary choice, IMHO.
I wouldn't regard NaN as an error, not more than +inf and -inf.
----------
Level 1: mid(X) = for non-empty X only: if (X==Entire) then 0
else (inf(X) + sup(X))/2
Property: X \subset Y ==> if (inf(X)==inf(Y)) then mid(X)<= mid(Y)&
if (sup(X)==sup(Y)) then mid(X)>= mid(Y)
Coercion: mid_F(X) = if (abs_F(round2Nearest_F(mid(X))) = +inf)
then roundToZero_F(mid(X))
else round2Nearest_F(mid(X))
For X = [0,+inf], this would give:
* mid(X) = +inf
* abs_F(round2Nearest_F(mid(X))) = +inf
* roundToZero_F(mid(X)) = roundToZero_F(+inf) = +inf
After all this discussion, I think that mid(X) should be NaN whenever
X is unbounded or empty. This is consistent with the usage of NaN in
floating-point for a mathematically not well-determined case of an
otherwise standard operation. No other assignment of midpoints is
appropriate for level 1 (where ad hoc decisions should be avoided).
Users in a branch and bound can catch the NaN and do something sensible
in the context of their particular method. The best choice is
user-dependent ans hence should be left to the user, which the result
NaN does.
Moreover, a naive user will not be able to form the interval
[inf(X),mid(X)] if the constructors are well-designed, and hence will
notice immediately that something has been done wrongly.
Thus there is no danger at all that this compromises the standard.
On the other hand, a function split(X) [if provided by the standard]
should return a sensible splitting point if one exist, and NaN
otherwise, i.e., if X contains at most two machine numbers. What is
most sensible would have to be discussed. I thought for some time that
returning the median of the machine numbers is good but this would
split the interval [0,1] at an extremely tiny number, which is not
warranted. It seems that there is no ''natural'' such function, thus
the standard should not provide one.
Instead, I propose to provide a function flmedian(X) that provided the
median, so that users can make their own split routine based on mid,
flmedian, and scaling considerations.