Re: Edge case conversions, exceptions to IEEE FPA
----- Original Message -----
From: "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx>
To: <Van.Snyder@xxxxxxxxxxxx>
Cc: "Siegfried M. Rump" <rump@xxxxxxxxxxxxx>; "stds-1788"
<stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Monday, November 10, 2008 11:48 AM
Subject: Re: Edge case conversions, exceptions to IEEE FPA
Van Snyder schrieb:
On Fri, 2008-11-07 at 08:50 -0800, Arnold Neumaier wrote:
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]
I find myself defending a mere suggestion before it has been commented
on by Siegfried, who
The reason would be to ensure that mixed computations with floats and
nonempty intervals always give nonempty intervals. This is a reasonable
though debatable requirement; I'd prefer to convert bad floats to Empty.
Arnold, I understand your point of view, so it seems we agree to disagree.
The statement
X = intval(1e400)
divides into two steps: First, 1e400 is converted into inf, then intval(inf)
is called.
You look only at the second step, so you define X is empty.
I am looking at both steps.
Furthermore you argue that following my point of view, then EVERY input must
be
interpreted as uncertain, so that
Y = intval(1)
should transform into [pred(1),succ(1)]. You prefer NO input is uncertain.
Sorry, I can't follow that.
In fl-pt the input argument 1e400 MUST be transformed into ONE fl-pt number,
and the best choice is inf. In interval arithmetic this is not mandatory, we
CAN
transform it into [realmax,inf] thus obtaining some reasonable result.
As I wrote before there is a difference in quality for me in the (small)
error we
perform in intval(.1) and moving intval(1e400) into empty.
It is a matter of interpretation; yours is the set of extended reals
(including inf)
although interval do not contain inf as an element. For me you adopt the
fl-pt
initerpretation to the interval standard.
My interpretation of the input inf is a huge number, so that
1e400 * intval(0)
yields [0,0] while your definition yields the empty set. Maybe I am biased
by
INTLAB. It would be strange for me that
1e400 * intval(0) = empty
Converting 1e400 into [realmax,realmax] would also be strange to me because,
e.g.,
intval(1e500) / 1e400 = [1,1]
in this definition. In your (original) definition it would be empty, in mine
[1,inf].
Bost interpretations are consistent, one has to be chosen.
Best wishes
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