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.