Re: [OctDev] control-2.3.51 released in package forum - please upload

[Lukas Reichlin]

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