MaplePrimes - answers and comments on Question, Problems finding the inverse of an algebraic 12x12 matrix

Simplification with the size option is helpful

Markiyan Hirnyk — Thu, 07 Jul 2011 12:56:09 Z

Calculating the determinant of C, I obtained
> Determinant(C);

[Length of output exceeds limit of 1000000]
However, the simplify command helps: the output of
>simplify(Determinant(C), size);

is reviewed (see Matrix.mw)
Now try to execute
>for i to 12 do
for j to 12 do A[i, j] := (-1)^(i+j)*simplify(Minor(C, i, j, output = 'determinant'), size)
end do
end do

Normalizer and Testzero

epostma — Thu, 07 Jul 2011 18:39:20 Z

One way that you can sometimes attack these problems is by reducing the amount of normalization that Maple does. For matrix inversion, for example, every potential pivot has to be checked for being equal to 0, which is by default done by converting to a factored normal form. The method of normalization used in LinearAlgebra is configurable, however, as is the method of zero testing, and that can sometimes lead to a solution in a case like this. However, the result, since it is not normalized as much as you would like, is generally not very useful.

In this case, we define C as above and then do:

Normalizer := x -> x; # No normalization at all.
Testzero := testeq; # Fast heuristic zero testing - still extremely reliable.
inv := LinearAlgebra:-MatrixInverse(C):

The computation is now actually pretty fast. But note that I put a colon after that last statement, not a semicolon. That's very much intentional, since Maple can't possibly print any of the entries of the matrix - they are much too big! For example,

length(inv[1, 1]);

returns 1611432722. That is, writing out the [1, 1] entry would require around 10^10 words of memory! The reason Maple can deal with such expressions at all is that it uses a DAG structure for representing expressions, in which repeating subexpressions use memory only once.

So can you use inv at all? Yes, you can. You can, for example, evaluate inv at a point in (x1, ..., y4)-space by substituting numbers in. However, it's not certain that this is actually faster than substituting the values into C and then inverting the matrix numerically. I only did a preliminary test, as follows:

variables := convert(indets(C), list):
mypoint := map(v -> v = RandomTools:-Generate(float(range=0..1, method=uniform)), variables);
CodeTools:-Usage(eval(inv, mypoint), iterations=1000):
# memory used=0.54MiB, alloc change=0 bytes, cpu time=3.88ms, real time=3.89ms
CodeTools:-Usage(eval(C, mypoint)^(-1), iterations=1000):
# memory used=63.66KiB, alloc change=0 bytes, cpu time=890.00us, real time=892.00us

This test is unfair, since the matrix inversion happens in a BLAS (in optimized external code) whereas evaluating inv happens in interpreted Maple code. So maybe the evaluation of inv could be improved by setting things up so that you can use evalhf or even Compiler:-Compile, but that would take some work.

All in all, I think in this case you're better off substituting the values first.

Hope this helps,

Erik Postma
Maplesoft.

M[1,1] and timing

Markiyan Hirnyk — Thu, 07 Jul 2011 19:15:18 Z

Take look at the calculation of M[1,1] and its timing Edit.=46.516 in Minor.mw

comments

acer — Thu, 07 Jul 2011 21:03:06 Z

A few more comments might be added, if I may. The next two paragraphs are other suggestions to support the idea that symbolic inversion is not a good idea here.

The purely numerical floating-point computation (of the inverse, or of solving a linear system) whether done in Maple or Matlab will be careful about selection of pivots. That is, the floating-point implementation use the specific numeric values during pivot selection. Symbolically inverting the Matrix will remove this carefulness, regardless of whether the symbolic pivots are chosen according to symbolic length, or by no scheme. Only a scheme of symbolic pivot selection that could qualify the relative magnitude of the pivot choices under assumptions on the unknowns would have a hope of regaining this care. But it could be difficult and might require a case-split solution, and it would add to the symbolic processing overhead. And the symbolic LU (or inversion) doesn't allow for a custom pivot selection strategy in the symbolic case.

Even if you keep some form of Testzero, it's still only checking whether the pivots are symbolically identical to zero or not. It doesn't provide for any safety that, given particular numeric values for the unknowns, some pivot might not attain a zero value. If that happens then the whole approach breaks with division by zero.

Perhaps there is some other way to improve the performance of the Matlab code. Do you compute the inverse in order to solve linear equations like A.x=b? It wasn't clear from your post whether you might be solving at different instances for various different RHSs `b`, for the same numeric instance of Matrix `A`. If you will have to solve for different RHSs `b`, for the very same numeric values of the unknowns, then you could consider doing the numeric LU factorization of `A` just once for the given numeric values of the variables, and then using just forward- and backward-substitution for each distinct RHS instance. This isn't going to help, if you solve for just one single RHS instance for any particular set of values of the variables.

acer

Auch!

KajkagenDK — Fri, 08 Jul 2011 11:16:34 Z

Hi Erik,

Thank you very much for your help, that makes sense! It's breathtaking though, that the inversion of the matrix is getting HUGE like that!

Your argument is very clear, and given this argument I think you're right, that I have to substitute the values first.

You have been very helpful :)

Have a nice weekend, and once again, thanks for your time!

Kind regards

Dennis