NXC: float / int bug

[HaWe]

weird:
by this program it calcuates correctly 0:

Code: Select all

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);
}

[mspall]

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.

[HaWe]

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

[mspall]

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.

[HaWe]

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