Re: Siegfrieds recent paper
Am Do 05.01.2012 12:37 schrieb Vincent Lefevre <vincent@xxxxxxxxxx>:
>
> But what if you have:
>
> A = infsup(0,1000);
> B = exp(A);
> C = 1/B;
> D = C-1;
> E = infsup(-1,-1);
> F = intersect(C,D);
>
Yes, in my arithmetic
A = infsup(0,1000); % [0,1000]
B = exp(A); % [1,inf]
C = 1/B; % [T,1]
D = C-1; % [-1,0]
E = infsup(-1,-1); % [-1,-1]
F = intersect(C,D); % [-1,-1]
It is not a panacea, but it smoothes and improves the
important case of underflow. Like an unbounded right
bound covers overflow, my "T" covers underflow.
> > In P1788
> >
> > A = infsup(0,1000); % [0,1000]
> > B = exp(A); % [1,inf]
> > C = 1/B; % [0,1]
> > D = infsup(0,0); % [0,0]
> > E = intersect(C,D); % [0,0]
>
> IMHO, the main problem here is that only closed intervals are
> supported in P1788. But this choice was made on purpose to have
> a simpler arithmetic, if I understand correctly.
Agreed. I do not suggest half-open or open intervals. I introduced
a certain symmetry between overflow and underflow. Basically
1/inf gives T and 1/T gives inf, in a mathematically sound way.
>
> I think that since we have decorations, two bits could be stored
> for free (in the same byte or some other padding byte if any) to
> give the information whether the bounds are in the interval or
> not. This could be an extension.
Yes, a possibility, but for my taste the arithmetic becomes
too complicated.
> If you do not assume incorrect conclusions, there would not be any
> problem.
Correct. But definitions should be as people expect.
> In a similar way, you shouldn't assume that every element
> of the returned interval is in the image of the function.
However, this is the usual way of thinking of people using interval
arithmetic,
interval arithmetic has been used this way for years.
If the result is meaningful (i.e. not NaI or alike), then the underlying
function is well-defined and the range enclosed.
>
> The default assumption here should be that the function is *not*
> necessarily well-defined. If you want more information about the
> function, just check the decorations.
In many cases functions are well-defined. Since users are not used to
check flags to ensure that a result is correct, it may be forgotten.
For example, in measure theory people are used to define inf-inf=0. In
IEEE754 the choice was inf-inf=NaN. One could also have defined
inf-inf=0 with a flag; but the majority of numerical analysts would
prefer (or expect) inf-inf=NaN.
>
> > This cannot happen with my definition.
>
> But your definition has drawbacks: your arithmetic can return NaI
> due to overestimation in the intermediate computations, while one
> would want a more meaningful result.
>
Agreed. I propose to define as default what the majority expects. And I
think occasional as well as expert users of interval arithmetic would
expect that a proper result interval implies a well-defined function.
IMHO a good way is to define an expert mode including decorations. For
the occasional and even for many expert users decorations are a
dangerous trap.
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