why is inv of matlab not working like numeric::inverse of mupad?

S = Sylvester matrix

ARK = Vector with 12 elements

Theta = numeric::inverse(S)*ARK

THIS works fine!

But in matlab the equation

Theta = inv(S)*ARK or Theta = S\ARK

doesn't work! Has anybody an idea why?

Thank you very much

[Steven Lord]

In this context, what does "doesn't work" mean? Does it throw an error (and if so what is the full text of the error, everything displayed in red text?) Does it issue a warning (and if so post the full warning message, everything in orange?) Does it take a long time to run? Does it give you a different result than you expected?

How did you build S and ARK, does it contain numbers or symbolic variables/expressions?

[Pietro]

Hello Steven,

thank you for your comment! :-)

The matrix S and the vector ARK contains numbers. It doesn't work means, i get a different result and the one from mupad is right. The matlab warning is:

Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 1.880981e-43.

I think the mupad command is doing a scaling first, is this right?

Thank you!

[Walter Roberson]

What is class(S) ? What is rank(S) ? Your reference to numeric::inverse suggests that S might be numeric.

[David Wilson]

If this is from a control application, then make sure you don have any common factors in your A and B polynomials. If you do, then S is known to be singular.

Answer 1

[Walter Roberson]

numeric::inverse processes the numbers symbolically. The default conversion is floating point to nearby algebraic numbers or pi. The calculations then proceed as rational. Even if you converted to symbolic floating point it would use 32 digits by default.

[Walter Roberson]

It is not uncommon that when you convert floating point to rational, that the determinant can be calculated as being slightly different than zero, allowing you to find the inverse of the matrix. It just isn't necessarily numerically stable: if the inputs had been different by even 1 bit of roundoff then the answers might have been different.

Likewise, when you convert from double precision to software floating point and use the default 32 significant digits (plus 3 to 5 guard digits), it is not uncommon for you to be able to use calculations that do not cancel out down to the last digits, and so allow you to calculate something . But again, if the original numbers had changed even slightly then the answers might have been completely different.

When I see an rcond that small, 1e-43, I would tend to think it very likely that there is a true singularity in the calculations and that the numeric solutions you get are probably not of any value -- or that they are only one of a solution family.