Mindboards

Posted: **11 Dec 2013, 18:39**

weird:
by this program it calcuates correctly 0:

task main() {
  int R[3][3]; int det;
  
    R[0][0]=111;  R[0][1]=444; R[0][2]=777;
    R[1][0]=222;  R[1][1]=555; R[1][2]=888;
    R[2][0]=333;  R[2][1]=666; R[2][2]=999;

    det=   R[0][0]*R[1][1]*R[2][2]
          +R[0][1]*R[1][2]*R[2][0]
          +R[0][2]*R[1][0]*R[2][1]
          -R[0][2]*R[1][1]*R[2][0]
          -R[0][1]*R[1][0]*R[2][2]
          -R[0][0]*R[1][2]*R[2][1] ;
          
    NumOut(0,0, det);

  while(1);
}

and by this strangely 24 !!!

Code: Select all

task main() {
  float R[3][3]; float det;
  
    R[0][0]=111;  R[0][1]=444; R[0][2]=777;
    R[1][0]=222;  R[1][1]=555; R[1][2]=888;
    R[2][0]=333;  R[2][1]=666; R[2][2]=999;

    det=   R[0][0]*R[1][1]*R[2][2]
          +R[0][1]*R[1][2]*R[2][0]
          +R[0][2]*R[1][0]*R[2][1]
          -R[0][2]*R[1][1]*R[2][0]
          -R[0][1]*R[1][0]*R[2][2]
          -R[0][0]*R[1][2]*R[2][1] ;
          
    NumOut(0,0, det);

  while(1);
}

Posted: **12 Dec 2013, 18:55**

Welcome to the world of Numerical Analysis. Even with code without logic or syntax errors you run into functional errors. With linear algebra problems like solving for the determinant of a matrix on a computer you run into precision problems. Often the same method that works symbolically won't work with finite precision math on computers. When working on matrices numerically, you can almost always find "degenerate" cases that break your solution method. This is why there are math libraries for these problems. GSL has been mentioned, but there is aslo BLAS, ATLSA, numpy and scipy. Easily pulling in these libraries is also a reason why people like higher level languages like python.
http://en.wikipedia.org/wiki/Comparison ... _libraries

If your code is correct logically, then print out some intermediate steps and look for where lack of precision is the problem. In your example, it could be the case that |0 - 24| < Epsilon, in other words, 24 is functionally equal to 0.

Posted: **12 Dec 2013, 19:04**

yes, meanwhile I observed that it works well using "double" instead of "float" in my C code, so this is supposed to be caused by calculation imprecision using 32 bit float arithmetics.

I know why having 64 bit "double" was my long-cherished wish for NXC, too...

Posted: **12 Dec 2013, 19:45**

But you can't rely on double to solve this. If you change the problem to R[0][0]=111111; etc., then you are back in the same boat. You will need to understand what the scale of the error value is for your problems and accept that the calculated value is equal to the true value plus some epsilon. In other words, |X -x| < epsilon and not if x == X.

Posted: **12 Dec 2013, 20:00**

yes, sure, thanks, I know about this calulation error. As I came upon this I first thought, my recursive 64bit C formula was faulty calculating "0", but then I came upon the fact, that the simple 32 bit float arithmetics have been faulty showing "24".
But NXC is (hopefully) slowly going to be used less often by me, so...

Mindboards

NXC: float / int bug

NXC: float / int bug

Re: NXC: float / int bug

Re: NXC: float / int bug

Re: NXC: float / int bug

Re: NXC: float / int bug