| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
As you see the latter is incorrect, and the first and second ways are giving the over-estimated result. Then, What you stated is not true, and the symbolic computation is not a tighter enclosure of the exact values. Moreover, one can obtain the incorrect result.f1= mul([10 10], x);third wayf=[-11 11]which reads:f=f1-f2f2=mul(x,x);f1= mul([10 10], x);second waywhich reads f=[-11 11]f=mul(x,f1);Dear OliverIf someone would like to use Octave, then they have to do one of the following:
This is a reply to your previous email.
Q1.
> 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.
Oliver told:
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.
Please notice that, in control theory, that the dynamical system is stable or not is very crucial when an expert is designing a controller for the system. When we have over-estimated results and they contain stable solutions as well as unstable solutions, means that it is possible that the system is unstable. As a result, the decision maker/the expert has to consider this bad situation and has to design a controller for stabilizing the system before doing anything else. This issue leads to so many problems and efforts which are not in fact needed. Because over-estimated results contain pieces of information which are not possible, and don't happen in fact. These pieces of information are misleading the analyzer and that expert.
Q2.
> /I can certainly find formulas which will bring RDM beyond its limits too.
> /
> You are very welcome, and I am all ears.
Oliver told:
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?
A) Your calculation is not correct. Please see carefully that paper you found and mentioned before concerning RDM. The solution is as follows:
F1 = -1 + 2α₁ , F2 = 1 - 2α₁
F1+F2=(-1 + 2α₁)+(1 - 2α₁)=0
which is exactly zero.
so no laws are violated.
Q3. Very important
1. In that software is mul(x,y) equal to sqr(x) whenever x=y?
Oliver told:
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.
You told that symbolic computation in Octave gives better results, because it is a tighter enclosure of the exact values. Yes you're right, but please bear in mind that symbolic computation is not the same as RDM, in general. That's, one can obtain two different solution based on RDM and symbolic computation, indeed, RDM gives us better solution. see the following example.
A) Please consider the following example which shows based on IEEE Std.1788 we have over-estimated result, and based on symbolic computation (your suggestion) we have a result different from RDM.
let f(x)=x(10-x), where x=[-1 1];
IEEE Std.1788 reads
f=[-11 11]
if we expand f(x) as f(x)=10x-x^2, then based on IEEE Std.1788 one can also get the following: f=[-10 10]-[0 1]=[-11 10]. However, the exact result is [-11 9].first way:f1= 10-x;
f2=sqr(x);
f=f1-f2
which reads:
f=[-11 10]MD-RDM-IA reads:x= -1 + 2α₁f=(-1 + 2α₁)*(11- 2α₁) whose span is [-11 9] which is very the exact result.Moreover, let me express a claim: No one can present a well definition of derivative for interval functions based on IEEE Std.1788, which can be a generalization of certain (non-interval) functions.Best wishes,Mehran Mazandarani
Department of Electrical Engineering
Ferdowsi University of Mashhad, Mashhad, Iran.
homepage:http://mehran.mazandarani.fumblog.um.ac.ir/
http://works.bepress.com/mehran_mazandarani
IEEE Member, me.mazandarani@xxxxxxxxOn Wed, Oct 21, 2015 at 7:32 PM, Oliver Heimlich <oliver@xxxxxxxxxxxxxxxxxxx> wrote: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