Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: IEEE Std.1788, inner operations, MD-RDM-IA, the Laws of Motion



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.
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.
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.
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?

I can certainly find formulas which will bring RDM beyond its limits too.
You are very welcome, and I am all ears.

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:
1. In that software is mul(x,y) equal to sqr(x) whenever x=y?
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]


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

Are the results obtained using your way conforming IEEE std.1788? Are they correct?

Regards,

P.S. I appreciate your valuable effort for developing GNU Octave.



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@xxxxxxxx











On Tue, Oct 20, 2015 at 9:50 AM, Oliver Heimlich <oliver@xxxxxxxxxxxxxxxxxxx> wrote:
On 19.10.2015 22:55, Mehran Mazandarani wrote:
> Dear Std.1788 members and IC members
> First of all let me thank John, Walter, Evgenija, and Svetoslav for kind
> attentions and advice.
> My workload was too high and I couldn't reply earlier, so sorry for that.
> John and others told that what I sent - *IC-2[corrected version].pdf
> <http://grouper.ieee.org/groups/1788/email/pdfgOOF1CFv5a.pdf>* -  for
> explaining differences between approaches was not clearly. That's why I
> prepared another one for clarifying the matter, and put on the table .
> Please bear in mind what Isaac Newton figured out more than 300 years
> ago - *The Laws of Motion*.
> I guess we should take a glance to the nature for almost whatever we do
> in mathematics.
> I mean the mathematics and its theories or discoveries should have
> emerged in real world or in the nature.
> In the new presentation, the file *IC-3.mp4* , the three approaches,
> *IEEE Std.1788 2015*, *Inner operations*, and *Multidimensional RDM
> interval arithmetic* are examined by the laws of motion. Simply put, the
> approaches are examined using the nature/real world. Please see the
> attachment.
> As is seen, the IEEE Std.1788 is in violation of the third law of
> motion, and Inner operations are in violation of second law of motion,
> whereas the Multidimensional RDM interval arithmetic preserves the Laws
> of motion.
> Indeed, the *cancelMinus/cancelPlus* approach could not either handle
> the limitations of Inner operations.
>
> In the next step I am going to show that how capable MD-RDM-IA is of
> dealing with Newton's method for solving a 1-D nonlinear system.
>
> I appreciate you kind consideration in advance.
>
> Comments are welcome.

Mehran,

I haven't heard of RDM before. For others who are interested, paper [1]
gives a basic introduction. From what I have found out, RDM is just
another variant of affine arithmetic, but the errors are written as α ∈
[0, 1] instead of ε ∈ [-1, 1] and error variables are accumulated as
polynomials to some extend (I didn't look so much into detail).

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. You can
reduce the dependency problem to some extend by carrying over symbolic
computations like you do in RDM, but I can certainly find formulas which
will bring RDM beyond its limits too (e.g. with exponential or
trigonometric functions).

Apropos symbolic computations: Since IEEE Std 1788-2015 distinguishes
between the point function and its interval extension, you can always
use some symbolic math on the point function before evaluation. To give
an example, I compute a2 from your slides in Octave:

>> pkg load symbolic interval
>> # Symbolic simplification of the point function
>> syms F_A F_B m
>> a2 = (F_B - F_A + F_A) ./ m;
>> a2 = simplify (a2);
>> # Interval extension of the simplification
>> Ia2 = function_handle (a2, 'vars', [F_A, F_B, m]) ...
         (infsupdec ('[1, 3]'), infsupdec ('[1, 3]'), 1)
Ia2 = [1, 3]_com

Of course, this also has its limits.

Best regards,
Oliver

[1] http://www.jtacs.org/archive/2012/2/3/JTACS_2012_02_03.pdf