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,
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,