Re:
On Thu, 13 Nov 2008 23:05:00 -0100, Michel Hack <hack@xxxxxxxxxxxxxx>
wrote:
On (Fri, 14 Nov 2008 21:05:30 -0100), Siegfried Rump wrote:
- some computation is performed,
- maybe flags are cleared,
- some variable x is computed, and
- now x is transformed into an interval variable y by type cast.
Ok, we are indeed "on the same page" now.
I can easily believe that your approach works in (nearly?) all
practical cases, as the situations I have described as "possible"
may not been seen in practice -- or lead to much more severe
problems so that the fine point under discussion here is the
least of the troubles.
I am however of the persuasion that even edge cases never seen in
practice have to be covered by a proper interface design, and that
is the issue here.
Yes, I agree 100 %, see below.
You did not comment on Arnold's new realHull(x,x) vs intval(x), where
the programmer will have a choice. As I said earlier, that only leaves
the issue of implicit conversion.
Yes, realHull(x,x) is nice; I expect this behaviour from the type cast
intval.
But, there is more than implicit conversion, see below.
I was indeed careless here; Arnold Neumaier put it much better:
xx = number2interval(x) implies isIn(x,xx)=!isEmpty(xx).
I agree that this works for finite floats under your model too,
but the implication above holds for Inf and NaN as well.
Yes, nice, and maybe of theoretical interest, but practically not very
useful.
I don't like flags. I think any arithmetic including IA should be
usable for casual users - who may not even know about the existence
of such a flag.
That's a valid concern -- but strategically-placed tests for Empty
should work quite well too.
And this is exactly what I want to avoid.
I think a major issue is that Arnold uses "empty" as a flag to indicate
that something illegal happened. But the empty set has a mathematical
meaning, and subsequent use of "empty" may cause problems. I expect
X1 = hull(x,y)
X2 = hull(intval(x),intval(y))
to give the same result because hull is an interval operator. Why should
the result change when being so polite and type cast x and y to intervals?
However,
Arnold's model my model
---------------------------------------------------------
hull(3,4) [3,4] [3,4]
hull(intval(3),intval(inf)) [3,3] [3,inf]
What I am concerned about is that this happens without notice
(a flag is raised, but it can't be expected that flags are always checked).
More important, I expect that interval computations can be performed with
the bounds of an interval X, i.e. with intval(X.inf) and intval(X.sup).
In Arnold's model this may again yield incorrect results, silently raising
a flag. For example,
hull(f(intval(X.inf)),f(intval(X.sup))) (*)
should give an inclusion of f(X) for a monotone function f. Note that,
for example, the type cast intval(X.sup) is necessary to force f to
compute bounds for f(X.sup).
I think that a definition should under no circumstances yield an incorrect
result where something meaningful can be expected.
I think ony may expect that the result in (*) is correct without checking
a flag.
You mentioned for example
x = (realmax/2)*3 - (realmax)
to say that the type cast intval(x)=[realmax,inf] is a wrong result. As I
said before, this is a case where a calculation takes place BEFORE a
variable
is type casted. In this case I would not expect the result to be correct.
Are there examples where a meaningful and correct result can be expected
but my proposal yields an incorrect result?
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