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.