# 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
```
```
```