Opened 9 years ago
Last modified 5 years ago
#10552 needs_work enhancement
Allow more elementwise simplifications for symbolic matrices
Reported by: | kcrisman | Owned by: | burcin |
---|---|---|---|
Priority: | minor | Milestone: | sage-6.4 |
Component: | symbolics | Keywords: | matrix symbolic simplify expand |
Cc: | jason, rbeezer | Merged in: | |
Authors: | Joris Vankerschaver | Reviewers: | Karl-Dieter Crisman |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
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.
Attachments (2)
Change History (20)
comment:1 Changed 9 years ago by
- Status changed from new to needs_review
comment:2 Changed 9 years ago by
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.
comment:3 Changed 9 years ago by
- 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 9 years ago by
- 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 9 years ago by
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.
comment:6 Changed 9 years ago by
- 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...
comment:7 Changed 8 years ago by
We can probably open another ticket for all the expand methods...
comment:8 Changed 8 years ago by
- 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 8 years ago by
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 8 years ago by
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 8 years ago by
Yes, that's a good idea, but how does Maxima simplify these guys? Do they do it elementwise?
comment:12 follow-up: ↓ 13 Changed 8 years ago by
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 8 years ago by
- Milestone set to sage-4.7.1
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.
comment:14 Changed 7 years ago by
See also #12162. Perhaps this should supersede that.
comment:15 Changed 6 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:16 Changed 6 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:17 Changed 6 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:18 Changed 5 years ago by
- Milestone changed from sage-6.3 to sage-6.4
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.