Opened 11 years ago

# Allow more elementwise simplifications for symbolic matrices

Reported by: Owned by: kcrisman burcin minor sage-6.4 symbolics matrix symbolic simplify expand jason, rbeezer Joris Vankerschaver Karl-Dieter Crisman N/A

### Description

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.

### comment:1 Changed 11 years ago by jvkersch

• Status changed from new to needs_review

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.

### comment:2 Changed 11 years ago by kcrisman

• Authors set to Joris Vankerschaver

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

• 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.

### comment:3 Changed 11 years ago by jvkersch

• Status changed from needs_review to needs_work

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.

### comment:4 follow-up: ↓ 5 Changed 11 years ago by kcrisman

• Summary changed from Allow symbolic matrices to be simplified elementwise to Allow more elementwise simplifications for symbolic matrices

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

### comment:5 in reply to: ↑ 4 Changed 11 years ago by jvkersch

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.

### comment:6 Changed 11 years ago by jvkersch

• Status changed from needs_work to needs_review

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

### Changed 11 years ago by jvkersch

Simplification methods for matrices

### comment:7 Changed 10 years ago by kcrisman

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

### comment:8 Changed 10 years ago by kcrisman

• Reviewers set to Karl-Dieter Crisman
• Status changed from needs_review to needs_work

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.

### comment:9 Changed 10 years ago by jvkersch

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).

### comment:10 Changed 10 years ago by burcin

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.

### comment:11 Changed 10 years ago by kcrisman

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

### Changed 10 years ago by jvkersch

New version of simplify patch

### comment:12 follow-up: ↓ 13 Changed 10 years ago by 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.

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

### comment:13 in reply to: ↑ 12 Changed 10 years ago by burcin

• Milestone set to sage-4.7.1

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.

### comment:14 Changed 9 years ago by kcrisman

See also #12162. Perhaps this should supersede that.

### comment:15 Changed 8 years ago by jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

### comment:16 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:17 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:18 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4
Note: See TracTickets for help on using tickets.