Allow more elementwise simplifications for symbolic matrices

[kcrisman]

As with several questions at ask.sagemath. Mike Hansen's answer at the first one seems like a good start:

age: m = matrix([[sin(x), cos(x)], [sin(x), cos(x)]]); m
[sin(x) cos(x)]
[sin(x) cos(x)]
sage: o = m*m.transpose(); o
[sin(x)^2 + cos(x)^2 sin(x)^2 + cos(x)^2]
[sin(x)^2 + cos(x)^2 sin(x)^2 + cos(x)^2]
sage: o.apply_map(lambda x: x.trig_reduce())
[1 1]
[1 1]

but it seems reasonable for matrices with symbolic elements to have some of these methods (also vectors, I suppose) without having to use any special terminology.

Open to suggestions on how that might be accomplished without creating a myriad of special methods, but by somehow piggybacking on symbolic.expression.Expression methods done elementwise...

Putting this under symbolics because it isn't really linear algebra, but that doesn't seem right either.

CC: @jasongrout @rbeezer

Component: symbolics

Keywords: matrix symbolic simplify expand

Author: Joris Vankerschaver

Reviewer: Karl-Dieter Crisman

Issue created by migration from https://trac.sagemath.org/ticket/10552

[jvkersch]

comment:1

In the code written for #10132 (metric surfaces in 3D), we compute a lot of symbolic matrices with complicated entries which eventually need to be simplified. The current patch adds a method simplify_full to the symbolic matrix class, which simply calls the same method on each of the matrix elements.

[kcrisman]

Author: Joris Vankerschaver

[kcrisman]

comment:2

Thanks for the patch! I am not in a position to review it right now, but it seems fine at a glance.

Two comments:

• The ticket actually asks for access to all simplification methods, if possible. Possibly also for vectors. It's okay if you are aiming a little lower, but then we'll want to open another ticket for the more general thing. (Or that new ticket could be connected to this one so that people fixing this one knew about it. Or whatever.)
• The commit message is a little long for that first line; we want it to be about 80 characters or less so that it looks nice in a terminal. You can add additional lines that are as long as you like, of course.

[jvkersch]

comment:3

Ah, sorry to overlook the other simplification methods! I'll get onto it. Also, the code for vectors is now #11335, and I'll update that patch in tandem with this one.

One thing that I noticed in the symbolic matrix class is that (for instance) the simplify_trig method duplicates the code from the elementwise trig simplification. Presumably we want the matrix method to call the simplification method on the elements? This doesn't result too much of a performance loss (47.4ms for elementwise calls, 32.7ms for the duplicate code), so I'll just go ahead and rewrite all of the simplification methods. However, if there's a good reason for doing things the way they are, please let me know and I'll revert.

[kcrisman]

comment:4

Huh, I didn't even notice that these already existed - I should have, and probably even helped review it... sigh.

I think the difference here is that we're using Maxima to simplify the whole matrix, instead of doing it elementwise. Maybe that would be better, since Maxima might be faster (especially once we are using the library interface). So the real question is whether there are any simplifications that are better done elementwise than all at once by Maxima.

In fact, my guess is that Maxima just does them elementwise in any case, in which case they should all look like they already do - it would be faster, as you point out.

So this ticket really is asking to increase the number of methods available. simplify_full is a notable missing method, but notice that while simplify_trig is available, trig_reduce and reduce_trig are not. Though I guess those are technically different, looking at the underlying code...

[jvkersch]

comment:5

Replying to @kcrisman:

I think the difference here is that we're using Maxima to simplify the whole matrix, instead of doing it elementwise. Maybe that would be better, since Maxima might be faster (especially once we are using the library interface). So the real question is whether there are any simplifications that are better done elementwise than all at once by Maxima.

Good point. I did some comparisons for various matrix sizes of simplify_trig elementwise versus by passing the whole matrix to Maxima, and it seems passing the matrix directly to maxima is about 50% faster. For large-ish matrices (say, 10x10) this is already considerable (1 sec. vs 450 ms. for a random matrix involving sines and cosines). I will therefore use the matrix version wherever available.

[jvkersch]

comment:6

Robert Bradshaw proposed a nice way at #11381 of implementing elementwise methods by using the corresponding functionality in Expression but I don't think this trick will work for matrices, as they are cdef classes. So I went ahead and just implemented the elementwise methods piece by piece. It's not exactly rocket science, but we can always replace these elementwise methods by something more clever later on...

[jvkersch]

Simplification methods for matrices

[kcrisman]

comment:7

Attachment: sage-symb-matrices.patch.gz

We can probably open another ticket for all the expand methods...

[kcrisman]

Reviewer: Karl-Dieter Crisman

[kcrisman]

comment:8

Good examples, good methods, comprehensive. Passes tests.

But there are optional arguments to some of these, which we might as well allow now. For instance simplify_trig has an expand=True option. These should all be added, just for completeness.

Otherwise, really nice.

[jvkersch]

comment:9

Thanks a lot for agreeing to review this!

I was going over the optional arguments, and for the element-wise methods this is easy to incorporate. However, for the methods that pass the whole matrix to Maxima, I don't know if it's feasible to have the same optional arguments, as that would amount to duplicating the code from the corresponding method in Expression. So I could either leave those methods as is, or replace them with element-wise methods that have the same calling convention but are somewhat slower.

Secondly, I can easily add all element-wise methods, but that would amount to a big increase in not-so-interesting code. As you write in the description, it would be really cool to have a mechanism for adding the corresponding methods from Expression directly (similar to #11381 but this doesn't work for cdef classes).

[burcin]

comment:10

Instead of duplicating code, it would be better to move the simplification code in expression.pyx to the relevant class in the maxima interface. For example move it to a method MaximaElement, then call that from symbolic matrices and expressions. I don't know the exact place where these should go in the maxima interface after the transition to libMaxima though.

[kcrisman]

comment:11

Yes, that's a good idea, but how does Maxima simplify these guys? Do they do it elementwise?

[jvkersch]

New version of simplify patch

[jvkersch]

comment:12

Attachment: trac-10552-symbolic-matrices.patch.gz

I really like the suggestion of moving the simplification methods to somewhere closer to the maxima interface. I would like to look into this, as it would give me a good chance of learning a more complex part of Sage.

In the meantime, I've uploaded a new version of the patch (I changed the filename to include the patch number -- the other patch can be deleted), but I'm still in two minds about optional parameters. Adding the expand=True parameter to simplify_trig was easy as it just involved one line of extra code, but for the other methods we run into the problems mentioned earlier, and we would have to choose between duplicating the code in symbolic.expression.Expression or calling the methods element-wise. Hopefully the proposed change to the maxima interface will resolve this...

[burcin]

comment:13

Replying to @jvkersch:

I really like the suggestion of moving the simplification methods to somewhere closer to the maxima interface. I would like to look into this, as it would give me a good chance of learning a more complex part of Sage.

IIRC, Nils Bruin did this for integration, summation, limits, etc. in the library interface to maxima. You can look in the file sage/interfaces/maxima_lib.py for examples.

[kcrisman]

comment:14

See also #12162. Perhaps this should supersede that.