|
Mehran,
Let me consider your [1, 3] - [1, 3] example.
The standard is defining how the subtraction operator should behave. The subtraction operator sees
SUBTRACT(X, Y), with X happening to be [1, 3], and Y happening to be [1, 3].
It has no way of knowing whether X and Y happen to come from the same source, e.g.,
A = [1, 3];
B = A;
C = A - B;
To exploit context knowledge of the _expression_ in which “-“ appears requires MUCH more sophisticated machinery, akin to full symbolic _expression_ analysis, and the re-write rules one should use are not well understood, even by human experts.
What interval arithmetic due to Moore and others guarantees is containment, enclosure, or inclusion: The mathematically correct answer is guaranteed to be contained in the interval computed by any sequence of interval arithmetic operation. There
is no guarantee of coverage, that is: No no over-estimation guarantee.
In this standardization process, we are having enough trouble agreeing on the details of how individual operators should behave. I suggest we leave the much harder problem of optimal (with respect to width) _expression_ simplification for another
day.
I ABSOLUTELY encourage research into optimal (or even good) re-write rules for complex expressions in which variables appear multiple times.
Dear John, Vladik, Michel, and IC members
Thank you for your kind reply.
I am writing to you regarding the previous emails about that section in Std. 1788 which deals with operations for interval arithmetic.
As I mentioned, based on the Std. 1788-2015 we may obtain results which lead to values that are not possible actually.
Michel told that it is because of dependency issue, and that Moore's arithmetic is indeed a worst-case arithmetic -- but this allows it to *guarantee* that the computed result encloses
any possible actual result.
Then, he told When an interval programmer writes a program to compute a particular
function, which could (in the point-function context) be written as an
algebraic _expression_ where certain variables may appear multiple times,
the programmer may take advantage of specific knowledge --
in particular,
monotonicity properties -- to compute a tighter enclosure than blindly
evaluating the _expression_ using Moore arithmetic.
1. Using Moore's approach leads to obtain values which may not be possible, i.e. impossible values. So, it makes us to analyze, decide, and design systems and processes with too high costs and probably too complex. That all of these are because of values which
are impossible, i.e. they will not happen.
2. The standard should be based on an approach which makes us be assured in at least some future development. This is while as you can see the attachment, using advantage of specific knowledge we get to what I termed it
Restoration issue.
Additionally, we are just considering very simple cases, because the
cases themselves have their own issues of obtaining real possible results/values, let alone problems related to differential equations and defining derivatives.
I recommend to rethink about the section of Std. 1788-2015 which deals with fourth basic operations in order to avoiding what will mislead us in so many problems.
Comments are welcome.
Thank you so much for your kind attention and consideration.
Warmest regards,
<IC-1.pdf>
|