Re: intval(X.sup))
comments.txtSiegfried M. Rump schrieb:
On Thu, 13 Nov 2008 23:05:00 -0100, Michel Hack <hack@xxxxxxxxxxxxxx>
wrote:
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]
hull(intval(1e-1),intval(1e-1)) gives in both cases a useless result
not containing 0.1.
Why should an operation that leads to unavoidable errors in most cases
be patched in an ad hoc way just to accoomodate a few rare cases where
the user can get off without problems?
Should we write the following into the standard??
''The use of intval(1e-1), intval(1e-400), and intval(1e308)
must be avoided since it is leads to intervals not containing the
intended result; however, you are free to use intval(1e309)
and intval(1e400) since the standard has been artificially
adapted to take account for such cases.''
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).
Semantic errors always happen without notice.
intval(inf) is meaningless, since inf is not a real number.
If floating-point operations or conversions generate non-real values,
and the user does not check for that, it is a semantic error.
No standard should enable people to program sloppily in a few
exceptional cases, while they need to take care in the typical case...
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).
Infinite bounds must be handled separately anyway for most monotone
functions, since interval operations rarely provide the required limits.
Looking at the monotone test case
f(x)=(x-1)/(x+1), X=[0,inf],
where one would like to see [-1,1] as result, we get with
intval(inf)=[realmax,inf] the useless result [-inf,inf].
Similarly, the monotone test case
f(x)=x^2-x, X=[1,inf]
gives [-inf,inf] instead of [0,inf].
I think that a definition should under no circumstances yield an incorrect
result where something meaningful can be expected.
If you want to get something meaningful in all cases, you are better
off by asking for
intval(inf)=Entire.
Only this is fool-proof, according to the past discussion.
And it leads to the sdame correct results in the above cases as your
recipe
intval(inf)=[realmax,inf].
By the way, the latter has another so far unnoticed anomaly.
For interval arithmetic implemented in double precision, realmax
is about 1e308. But in Fortran, 1e100 is a single precision number
which already overflows to inf, hence
intval(1e100) = [1e308,inf],
which is very strange.
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?
Yes. Your recipe
intval(inf)=[realmax,inf].
has another so far unnoticed anomaly.
For interval arithmetic implemented in double precision, realmax
is about 1e308. But in Fortran, 1e100 is a single precision number
which already overflows to inf, hence
intval(1e100) = [1e308,inf],
which is very strange.
Also, there is still the incorrect behavior of intval(1e-1).
It makes no sense to patch up an unreliable constructor which
must anyway be used with care to enable a few exceptions to
yield more plausible results.
Rather the user must know that mixing floats and intervals is a
dangerous operation whose effects must be considered in each case.
Arnold Neumaier