On 05.06.2012, at 07:31, c. wrote: > > On 4 Jun 2012, at 23:56, Thomas Weber wrote: > >> Eh no, not quite. We usually look at the errors and decide. But here we >> are talking about a factor of 10000 between expected and actual result. >> That's a bug. > > As far as I understand from Lukas' explanation, the sign in the result is not > relevant.
Well, the sign IS relevant. But the two state-space models are equivalent if you can find a diagonal transformation matrix T with entries -1 and 1 such that Aexp = T \ Aobs * T Bexp = T \ Bobs Cexp = Cobs * T Dexp = Dobs I don't know which ATLAS routine returns different solutions and why. If there is such a T, then the result is not wrong in the sense of control engineering. Using assert (abs (Mo), abs (Me), 1e-4) i just a crutchm, we should find and test T. BTW: M = [A, B; C, D] > The failures I get are of the form: > > ***** assert (Mo, Me, 1e-4); > !!!!! test failed > assert (Mo,Me,1e-4) expected > > -0.23910 0.30720 1.16300 1.19670 -1.04970 > -2.97090 -0.23910 2.62700 3.10270 -3.70520 > 0.00000 0.00000 -0.51370 -1.28420 0.82230 > 0.00000 0.00000 0.15190 -0.51370 0.74350 > -0.44660 0.01430 -0.47800 -0.20130 0.02190 > > but got > > -0.23915 0.30723 1.16297 -1.19671 1.04965 > -2.97091 -0.23915 2.62702 -3.10273 3.70515 > 0.00000 0.00000 -0.51368 1.28421 -0.82227 > 0.00000 0.00000 -0.15189 -0.51368 0.74348 > 0.44660 -0.01427 0.47803 -0.20129 0.02190 > > maximum absolute error 7.41035 exceeds tolerance 0.0001 > > If I take the abs () of the results I have > >>> abs (Mo) - abs (Me) > ans = > > -5.0000e-05 -3.0000e-05 3.0000e-05 -1.0000e-05 5.0000e-05 > -1.0000e-05 -5.0000e-05 -2.0000e-05 -3.0000e-05 5.0000e-05 > 0.0000e+00 0.0000e+00 2.0000e-05 -1.0000e-05 3.0000e-05 > 0.0000e+00 0.0000e+00 1.0000e-05 2.0000e-05 2.0000e-05 > 0.0000e+00 3.0000e-05 -3.0000e-05 1.0000e-05 0.0000e+00 > > so results are well within the expected tolerance. > Of course if the abs is left out of the test the error looks much larger as > x - (- x) = 2 * x so I'd really prefer the assert above to be changed to > "assert (abs (Mo), abs (Me), 1e-4);" to avoid confusing error messages. > >> I also don't buy the argument that ATLAS and BLAS will produce wildly >> differing results that are both correct. Whenever the differences >> between ATLAS and BLAS were huge in the past, there was a bug in the >> library or in the calling code. > > As to why the sign of the result is not predictable, I do not know enough > about > the algorithm being implemented here to comment. Lukas, could you point to > the specific BLAS routine that is giving different results here? > > c. I fear this is quite complicated. You need to start with the SLICOT user function and see which SLICOT subroutines are called and then find the required BLAS routines. It could get as worse as this: m-file > cc-file > SLICOT routine called from cc-file > SLICOT subroutine > LAPACK > BLAS Lukas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev