Re: Comment on "undefined" behavior Re: Definition of intervals as subsets of R - the bad news
Ralph Baker Kearfott a écrit :
Everything else being equal, we should try to avoid
undefined behavior. The goal of the standardization process
is to define the behavior so things are predictable. We should
also try to avoid multiple alternatives, unless absolutely
necessary.
I only partially agree with this statement in general.
Concerning "avoid multiple alternatives", I disagree that we should
aim at necessarily suppressing them. For example, I find it a good
goal for the standard to support several kinds of implementations :
fast ones, some helping debugging, or some others that apply some
rewriting rules to improve the width of intervals, etc.
In this particular case, unless there is a better proposal that solves
this problem, I consider "undefined behavior" an acceptable solution
(see my rationale below), so it should not be quickly discarded a priori
by general statements like the one you wrote above.
We haven't formally considered "infinity as a number" yet, although
we've discussed it extensively. We can weigh the system, using
IEEE 754R and infinity as a number, and without exceptions, against
the perceived elegance mathematical of interpreting intervals to be
composed only
of finite real numbers, but with associated inefficiencies or
weakening of the standard. This would be a simple motion to formulate,
and we're probably ready to formally discuss it and vote.
My high-level take on this is that floating-point and intervals are two
different models for computing with approximations of reals.
The floating-point model is fine by itself, and went into refinements
(inf, nans) to make the system consistent, closed under some operations,
and repeatable.
Repeatability is critical for floating-point because floating-point
operations lose a lot of information at each operation due to rounding.
This lost information in a sequence of operations has to be represented
externally: in brains and papers. Repeatability simplifies the
brain/paper part.
For intervals, this problem is way less critical, and different, since
the information they represent is exactly the information about the
history of computations.
The interval model therefore does not have the exact same repeatability
constraints: would anybody ever complain to obtain tighter intervals than
what the standard requires (provided the inclusion property has been
kept of course)? I guess no.
So, the interval model is different, and there is no reason why the
refinements introduced for floating-point would be easily retrofittable
in the interval model.
An important aspect is the cost of compromises to be introduced
in the model to make it satisfy some compatibility with the details
of a different model.
( Run-time cost is one thing, but the cost of degrading the simplicity
of the formalism must not be neglected : they would make it harder to
reason about it. )
So, as far as I'm concerned, I'm definitely ready to accept some undefined
behavior as far as the interoperability with the floating-point model of
reals is concerned.
But I agree, if we can make them more interoperable, all the better!
Let's see other proposals, and vote on them based on their merits!
Baker
On 2/19/2009 5:17 AM, Sylvain Pion wrote:
Siegfried M. Rump wrote :
In a nutshell, defining interval to consist only of finite
numbers is a nice concept, but various exceptional operations
such as 0*inf or inf-inf have to be identified and redefined.
For example, this slows down addition by about a factor 2.
I am afraid, a penalty might also apply to a C- or Fortran
implementation.
Dear Siegfried,
What we ended up doing in the draft proposal for C++ was to invoke
"undefined behavior" in such situations (e.g. when constructing
an interval from a non-finite value). "Undefined behavior" is
defined in the C++ standard and means "anything can happen".
In particular, this allows to have the following two sensible
behaviors:
- raise an error in any way is prefered
- remove all checks completely, assuming everything is OK,
hence getting optimal speed.
In practice, what can be done is to have 2 "modes" of an implementation,
one including checks, and the other with the checks removed.
Both are then conformant to the standard specifications.
It is quite common to do that, for example, the standard library
shipped with GCC has a "debug" mode offering many such additional
checks, and this mode can be selected by specifying a macro on
the command line (the default is the fast mode).
Other compiled languages (e.g. C, Fortran) can probably easily
provide something similar.
I'm not familiar enough with Matlab, but maybe something similar
could be envisioned ?
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/