Re: IEEE Std.1788, inner operations, MD-RDM-IA, the Laws of Motion
On 21.10.2015 11:49, Mehran Mazandarani wrote:
> Dear Oliver
> Thank you for your reply.
> /Saying the set-based interval arithmetic *violates* Newton's laws*is
> wrong*. The *exact* result is just over-estimated (which is *correct* and
> should always be expected) because of the dependency problem./
> About this statement,
> 1. As is seen in the file IC-3.mp4, based on IEEE Std.1788-2015 the
> *third* law of motion is violated, obviously.
Mehran,
no, it is not violated. It is the user of interval arithmetic (you) who
wrongly thinks that the result is an exact enclosure of all possible
values of an arithmetic expression. In general, the result is an
overestimation of the exact result. The exact result is either an
element or a subset of the interval result (if a solution exists).
The result from your slides contains the exact solution, so everything
works as specified.
> 2. That you believe what is obtained based on Std.1788 is the *exact*
> result is right, but please notice how true/reliable the exact result
> is. To illustrate, consider the the well-known motion of a car on the
> ground formulated by x=v*t where x is the distance, v is the velocity
> and t is time. Now, if someone modifies it as x=v*t+2, well what does
> happen? using the latter for computing the distance by v=1 and t=1
> results in x=3 and the former says x=1. Both of them are the exact
> result, however the modified formula does not give us a reliable result
> and is misleading us.
The interval results (from IEEE Std 1788-2015) are reliable to the
extend that they will contain exact results. No more and no less is
guaranteed.
Of course, there are accuracy requirements for basic operations, but
these will not save you from dependency problems or accumulated roundoff
errors.
The RDM approach can model polynomial dependency errors to some extend
and can therefore give better results for your examples (at the cost of
additional memory and CPU cycles).
> 3. About /which is *correct* and should always be expected:
> /Unfortunately, it is not correct.
> Why is not it correct? To illustrate, assume we are going to analyze the
> stability of a system such as a satellite, airplane, etc. using this
> kind of over-estimated approach, we may obtain that the system is
> unstable whereas the system is not actually unstable and just over
> estimation is blame.
If you conclude that the system is unstable, your conclusion is wrong.
When you have over-estimated results and they contain stable solutions
as well as unstable solutions, you cannot conclude whether the system is
unstable.
> 4. what does mean when we obtain x-x=[-2 2] where x=[1 3], x=[1 3]? it
> means that whole elements from -2 to 2 is possible whereas it is not the
> case. over estimation is showing impossible results as possible results
> which is wrong.
> Now, here a question arises, why should we emphasize on an approach
> which may mislead us in so many analyzes?
As stated above, the result is not wrong (containment is assured) and is
not misleading if you understand the semantics of set-based interval
arithmetic.
> /I can certainly find formulas which will bring RDM beyond its limits too.
> /
> You are very welcome, and I am all ears.
a1 = F1 / m
a2 = F2 / m
Both forces are uncertain, but equal with inverse direction
F1 = -F2 = -1 + 2α₁
m = 3
Now we compute a1+a2 (which should equal zero). Since we have
intermediate results, we will probably have to do outward rounding for
the computation of a1 and a2 (1/3 and 2/3 cannot be stored in a finite
binary number format). Then the sum will not equal zero, but be some
kind of uncertainty around zero.
Would you say that Newton laws are violated by the computation?
> I haven't had Octave, and used it yet, - Indeed I couldn't get it there
> was a problem to download it - but two points looks interesting for me:
You can find download instructions here:
http://www.gnu.org/software/octave/download.html The extra packages have
to be installed seperately.
> 1. In that software is mul(x,y) equal to sqr(x) whenever x=y?
The sqr (square) function comes from IEEE Std 1788-2015. You can use it
to compute x². mul(x, x) will give a different result, because both
parameters are considered independent of each other, which may lead to
overestimation.
> 2. What you did for computing the a2, is not logic, and does not result
> in correct solution/result always. To illustrate, would you please
> calculate the following case in the same way you did in your previous email:
> Z1=A+A-A
> where A= [-1 1]
> or
> Z2=A-A+B
> where A=[-1 1], B=[1 1].
>
> *Answers:
> *
> *Z1= [-3 3], Z2=[-1 3]*
These would be the results that you get when you use set-based interval
arithmetic.
> however, if you do in the same way you chose, you get the following results:
>
>>> pkg load symbolic interval
>>> # Symbolic simplification of the point function
>>> syms A B
>>> Z1 = A+A-A;
>>> Z1 = simplify (Z1);
>>> # Interval extension of the simplification
>>> IZ1 = function_handle (Z1, 'vars', [A]) ...
> (infsupdec ('[-1, 1]'))
> IZ1 = [-1, 1]_com
>
>>> pkg load symbolic interval
>>> # Symbolic simplification of the point function
>>> syms A B
>>> Z2 = B+A-A;
>>> Z2 = simplify (Z1);
>>> # Interval extension of the simplification
>>> IZ2 = function_handle (Z2, 'vars', [A, B]) ...
> (infsupdec ('[-1, 1]'),infsupdec ('[1]'))
> IZ2 = [1, 1]_com
You get these results because Z1 and Z2 are used as symbolic formulas
and the term “A-A” is removed before the interval computation in each case.
> Are the results obtained using your way conforming IEEE std.1788? Are
> they correct?
Both ways of computation are correct (see above what “correct” means).
The latter gives better results, because it is a tighter enclosure of
the exact values.
Apropos better results, there is a great talk by Gerald Sussman about
narrowing interval results by using different kinds of computation and
propagation of information:
http://dustycloud.org/blog/sussman-on-ai/
Best regards
Oliver