I have another suggestion that I think
is simpler, more efficient, and solves other problems:
Allow
+Infinity and -Infinity as fully accepted values in intervals.
Then converting an IEEE 754 +Infinity
to an interval gives [+Infinity, +Infinity]
as it should (an interval must contain the correct value, and here the
correct value is +Infinity),
and when using IEEE binary64 (ie double precision or C double) intervals,
converting 1e400
would give [+DBL_MAX, +Infinity]
because that is the tightest interval enclosing the converted value.
That's the right and logical thing to
do.
In this example,
[1e300, 1e300] - 1e400 = [1e300, 1e300]
- [DBL_MAX, +Infinity] = [1e300, 1e300]
- [1.7976931348623158e+308, +Infinity] = [-Infinity,
(1.7976931348623158e+308-1e300)] = [-Infinity,
0] which I believe is the right answer.
If the [1e300,
1e300] was the result of a conversion
from a double, and you did the subtraction before the conversion, or if
you converted the interval to a double before doing the subtraction, then
depending on the rounding mode you used when converting "1e400"
to a double, you would have either
1e300 - 1e400 = 1e300 - +Infinity
// if rounding up = -Infinity or
1e300 - 1e400 = 1e300 - DBL_MAX
//
if rounding down = 1e300 - 1.7976931348623158e+308 = 0 So the correct value is one of those
two, and the interval should be in that range, not [NaN,
NaN].
This follows IEEE 754 semantics so can
be efficiently implemented with standard hardware, and I think is more
useful than saying that there is no answer or that you don't know what
it is.
- Ian Toronto
IBM Lab 8200 Warden D2-445 905-413-3411
----- Forwarded by Ian
McIntosh/Toronto/IBM on 19/02/2009 05:36 PM -----
"Siegfried M. Rump"
<rump@xxxxxxxxxxxxx>
19/02/2009 01:41 PM
Please respond to
"Siegfried M. Rump" <rump@xxxxxxxxxxxxx>
To
Ian McIntosh/Toronto/IBM@IBMCA
cc
Subject
Re: Definition of intervals as subsets
of R - the bad news
> On 19 Feb 2009, at 13:50, Arnold Neumaier wrote:
>> I don't see why this makes expensive alterations necessary.
>> Convert any real +-inf to NaN before doing the standard operation,
>> and you get the correct result.
>>
>> Setting x(isinf(x))=NaN before executing an operation with a
>> real argument x is cheap, vectorizes, and should do the trick.
>
> That's what I was about to propose. On the assumption (my preference)
> that any real x is regarded as [x,x] if finite, and emptyset if
> infinite, this seems to work for aa+b, aa-b, aa*b, aa/b, as well with
> the arguments swapped. What am I missing?
>
> John
A minor point is that x(isinf(x)) causes an error for large arrays
for which indices cannot be linearized. Since INTLAB is also intended
for huge matrices I have to work around this. It is done, but it is nasty
(see the INTLAB code).
Aah, it took me a while to understand. You mean
[1,2] - inf = empty
anyway, and also
[1e300,1e300] - 1e400 = empty
in double precision. It comes back to the "conversion of inf"-problem.
The behavior above is so far out of my mind that it took me a while to
understand your point.
You can write in the documentation/definition of interval arithmetic
what you want, users would not understand this. It is academic.
I think it is a BAD MISTAKE to enforce such a definition.
The behavior is perfectly documented, but it is perfectly what most users
would NOT expect. It may be correct, but it is not right.
And after a short while people forget it - if they ever knew it - and
results become incorrect: The worst what can happen in the interval arena.
As you see, I already forgot it.
I am positive my INTLAB users would grill me if I implement this.
Cheers, Siegfried
--
=====================================================
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