Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Definition of intervals as subsets of R - the bad news



On Thu, 19 Feb 2009 10:17:00 -0100, Sylvain Pion <Sylvain.Pion@xxxxxxxxxxxxxxx> 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".



Dear Sylvain,

indeed, this is not unusual. For example, Fortran defines what is
a correct program and its semantics - implying that the behavior
of an incorrect program is not defined.

In the current version of INTLAB there are such situations:

infsup(1,inf) - inf
intval ans =
       NaN

Interpret an answer "NaN" as "not known" for the sake of speed.
In fact the above is computed in the obvious way as you see by
looking at the left and right bound:

infsup(ans)
intval ans =
[     - Inf,       NaN]

So the right bound NaN gives less information than would be possible.
However, imagine I have to compute A-B for interval matrices A,B. For
the best possible result I would have to check for NaNs in A and B,
thus doubling the computing time for cases which rarely occur.

I know it is not perfect, but I don't intend to change it.
In fact it seems not of much interest to people working with INTLAB.
The above behavior is so since the beginning in 1998, and out of the
several thousand users nobody ever complained.

Best wishes

Siegfried





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 ?




--
=====================================================
Prof. Dr. Siegfried M. Rump
Institute for Reliable Computing
Hamburg University of Technology
Schwarzenbergstr. 95
21071 Hamburg
Germany
phone  +49 40 42878 3027
fax    +49 40 42878 2489
http://www.ti3.tu-harburg.de

and

Visiting Professor at Waseda University
Faculty of Science and Engineering
Shinjuku Lambdax Bldg. 902
2-4-12 Okubo, Shinjuku-ku
Tokyo 169-0072
Japan
phone/fax in Japan  +81 3 5286 3414