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

Re: Alternate floating-point results under directed rounding



Arnold Neumaier schrieb:
Siegfried M. Rump schrieb:
On Fri, 07 Nov 2008 11:17:59 -0100, Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> wrote:

I don't understand.
 To have 0*[1,inf] = [0,0], no interpretation of inf as floating-point
is needed, since this automatically holds with the specification of
    [l,u] = set of reals between l and u.
No conversion of inf to an interval is involved here.


Consider (in Matlab notation)

   X = intval(NaN);
   Y = 0*X

The result is the empty set, in either way. We expect this.
Consider

   X = intval(0.1);
   Y = 0*X

The result is [0], in either way. We expect this.
Consider

   X = intval(1e40);
   Y = 0*X

The result is still [0], either way. We expect this.
Consider

   X = intval(1e400);
   Y = 0*X

Your result is the empty set. Strange? I think yes.

People need to be taught anyway to avoid writing any of these
to get validated results. Why then should we cater for them to
get off luckily in a few rare cases?

In my opinion, the value of the result does not matter, since in
each of the three cases, a semantic error has been made that already
invalidated the enclosure properties of interval arithmetic
and hence makes the result meaningless from a rigorous point of view.


You also forgot to consider cases like
    U=1e400;
    V=1e-800*U
    X = intval(V);
    Y = 0*X
The result is the empty set. Strange? You should think yes.


As you say, we can define everything as we wish.

Yes.


I prefer a definition so that Y is still [0].

This is why I had proposed to convert
     +inf   into the interval   [realmax,realmax],
     -inf   into the interval   [-realmax,-realmax],
      NaN   into the interval   [0,0]
(for symmetry reasons, and since 0*inf=NaN suggest that in floating-point arithmetic, NaN is a limiting form of zero),
and to raise the nonstandardNumber flag as in Section 2.1 of
my proposal (Version 2.0).

This would remove the above strangeness.

but in my opinion that proposal is strange in itself
would it mean that [x,inf] = {y|y>=x} contains inf=[realmax,realmax] = [realmax] ? yes you have the nostandardNumberflag, but I think when we want to spread intervals, we should not suggest nonstandard meanings of inf and NaN.

I'd rather prefer your original proposal with the advice that floatingpoint constants are to be entered as strings to enforce proper enclosures

Juergen WvG

Somehow, my suggestion seems to have missed your attention.
Please comment on this proposal to modify the interpretation
of +-inf and NaN.

With this interpretation, fixed operations could be handled
at about the same cost as with the interpretation in my proposal (Version 2.0).

With nonreal floating-point numbers interpreted as empty, we'd have
to convert a=+-inf to NaN before execution of formulas such as
    a+[l,u] = [a+l,a+u], etc.,
while with the above proposal, we'd convert a=+-inf to +-realmax and a=NaN to 0 before execution. And similar for formulas based on
explicit case distinctions.

Then mixed arithmetic operations with floats and intervals will
never result in the empty set.


Arnold Neumaier