Sage: Ticket #10552: Allow more elementwise simplifications for symbolic matrices
https://trac.sagemath.org/ticket/10552
<p>
As with <a class="ext-link" href="http://ask.sagemath.org/question/211/is-there-a-way-to-simplify_full-and-trig_reduce-a"><span class="icon"></span>several</a> <a class="ext-link" href="http://ask.sagemath.org/question/273/reduce_trig-for-matrices"><span class="icon"></span>questions</a> at ask.sagemath. Mike Hansen's answer at the first one seems like a good start:
</p>
<pre class="wiki">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]
</pre><p>
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.
</p>
<p>
Open to suggestions on how that might be accomplished without creating a myriad of special methods, but by somehow piggybacking on <code>symbolic.expression.Expression</code> methods done elementwise...
</p>
<p>
Putting this under symbolics because it isn't really linear algebra, but that doesn't seem right either.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/10552
Trac 1.1.6jvkerschMon, 16 May 2011 06:18:21 GMTstatus changed
https://trac.sagemath.org/ticket/10552#comment:1
https://trac.sagemath.org/ticket/10552#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
In the code written for <a class="closed ticket" href="https://trac.sagemath.org/ticket/10132" title="enhancement: Parametrization of (metric) surfaces in 3D euclidean space (closed: fixed)">#10132</a> (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 <code>simplify_full</code> to the symbolic matrix class, which simply calls the same method on each of the matrix elements.
</p>
TicketkcrismanMon, 16 May 2011 12:36:56 GMTauthor set
https://trac.sagemath.org/ticket/10552#comment:2
https://trac.sagemath.org/ticket/10552#comment:2
<ul>
<li><strong>author</strong>
set to <em>Joris Vankerschaver</em>
</li>
</ul>
<p>
Thanks for the patch! I am not in a position to review it right now, but it seems fine at a glance.
</p>
<p>
Two comments:
</p>
<ul><li>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.)
</li><li>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.
</li></ul>
TicketjvkerschMon, 16 May 2011 17:56:33 GMTstatus changed
https://trac.sagemath.org/ticket/10552#comment:3
https://trac.sagemath.org/ticket/10552#comment:3
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Ah, sorry to overlook the other simplification methods! I'll get onto it. Also, the code for vectors is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/11335" title="enhancement: Allow symbolic vectors to be simplified elementwise (closed: fixed)">#11335</a>, and I'll update that patch in tandem with this one.
</p>
<p>
One thing that I noticed in the symbolic matrix class is that (for instance) the <code></code>simplify_trig<code></code> 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.
</p>
TicketkcrismanMon, 16 May 2011 19:24:37 GMTsummary changed
https://trac.sagemath.org/ticket/10552#comment:4
https://trac.sagemath.org/ticket/10552#comment:4
<ul>
<li><strong>summary</strong>
changed from <em>Allow symbolic matrices to be simplified elementwise</em> to <em>Allow more elementwise simplifications for symbolic matrices</em>
</li>
</ul>
<p>
Huh, I didn't even notice that these already existed - I should have, and probably even helped review it... sigh.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
So this ticket really is asking to increase the number of methods available. <code>simplify_full</code> is a notable missing method, but notice that while <code>simplify_trig</code> is available, <code>trig_reduce</code> and <code>reduce_trig</code> are not. Though I guess those are technically different, looking at the underlying code...
</p>
TicketjvkerschMon, 16 May 2011 22:01:42 GMT
https://trac.sagemath.org/ticket/10552#comment:5
https://trac.sagemath.org/ticket/10552#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10552#comment:4" title="Comment 4">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
TicketjvkerschTue, 31 May 2011 02:11:44 GMTstatus changed
https://trac.sagemath.org/ticket/10552#comment:6
https://trac.sagemath.org/ticket/10552#comment:6
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Robert Bradshaw proposed a nice way at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11381" title="enhancement: Add more simplification methods to symbolic vectors. (closed: fixed)">#11381</a> of implementing elementwise methods by using the corresponding functionality in <code></code>Expression<code></code> 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...
</p>
TicketjvkerschTue, 31 May 2011 02:13:12 GMTattachment set
https://trac.sagemath.org/ticket/10552
https://trac.sagemath.org/ticket/10552
<ul>
<li><strong>attachment</strong>
set to <em>sage-symb-matrices.patch</em>
</li>
</ul>
<p>
Simplification methods for matrices
</p>
TicketkcrismanThu, 16 Jun 2011 04:43:47 GMT
https://trac.sagemath.org/ticket/10552#comment:7
https://trac.sagemath.org/ticket/10552#comment:7
<p>
We can probably open another ticket for all the expand methods...
</p>
TicketkcrismanThu, 16 Jun 2011 04:47:31 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/10552#comment:8
https://trac.sagemath.org/ticket/10552#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
</ul>
<p>
Good examples, good methods, comprehensive. Passes tests.
</p>
<p>
<strong>But</strong> there are optional arguments to some of these, which we might as well allow now. For instance <code>simplify_trig</code> has an <code>expand=True</code> option. These should all be added, just for completeness.
</p>
<p>
Otherwise, really nice.
</p>
TicketjvkerschFri, 17 Jun 2011 00:29:24 GMT
https://trac.sagemath.org/ticket/10552#comment:9
https://trac.sagemath.org/ticket/10552#comment:9
<p>
Thanks a lot for agreeing to review this!
</p>
<p>
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 <code>Expression</code>. 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.
</p>
<p>
Secondly, I can easily add <em>all</em> 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 <code></code>Expression<code></code> directly (similar to <a class="closed ticket" href="https://trac.sagemath.org/ticket/11381" title="enhancement: Add more simplification methods to symbolic vectors. (closed: fixed)">#11381</a> but this doesn't work for cdef classes).
</p>
TicketburcinFri, 17 Jun 2011 01:20:34 GMT
https://trac.sagemath.org/ticket/10552#comment:10
https://trac.sagemath.org/ticket/10552#comment:10
<p>
Instead of duplicating code, it would be better to move the simplification code in <code>expression.pyx</code> to the relevant class in the maxima interface. For example move it to a method <code>MaximaElement</code>, 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.
</p>
TicketkcrismanFri, 17 Jun 2011 01:41:42 GMT
https://trac.sagemath.org/ticket/10552#comment:11
https://trac.sagemath.org/ticket/10552#comment:11
<p>
Yes, that's a good idea, but how does Maxima simplify these guys? Do they do it elementwise?
</p>
TicketjvkerschSun, 19 Jun 2011 04:18:28 GMTattachment set
https://trac.sagemath.org/ticket/10552
https://trac.sagemath.org/ticket/10552
<ul>
<li><strong>attachment</strong>
set to <em>trac-10552-symbolic-matrices.patch</em>
</li>
</ul>
<p>
New version of simplify patch
</p>
TicketjvkerschSun, 19 Jun 2011 04:23:07 GMT
https://trac.sagemath.org/ticket/10552#comment:12
https://trac.sagemath.org/ticket/10552#comment:12
<p>
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.
</p>
<p>
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 <code>expand=True</code> parameter to <code>simplify_trig</code> 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 <code>symbolic.expression.Expression</code> or calling the methods element-wise. Hopefully the proposed change to the maxima interface will resolve this...
</p>
TicketburcinSun, 19 Jun 2011 08:46:23 GMTmilestone set
https://trac.sagemath.org/ticket/10552#comment:13
https://trac.sagemath.org/ticket/10552#comment:13
<ul>
<li><strong>milestone</strong>
set to <em>sage-4.7.1</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10552#comment:12" title="Comment 12">jvkersch</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
IIRC, Nils Bruin did this for integration, summation, limits, etc. in the library interface to maxima. You can look in the file <code>sage/interfaces/maxima_lib.py</code> for examples.
</p>
TicketkcrismanWed, 13 Mar 2013 15:52:41 GMT
https://trac.sagemath.org/ticket/10552#comment:14
https://trac.sagemath.org/ticket/10552#comment:14
<p>
See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/12162" title="enhancement: simplify_full for matrix (closed: fixed)">#12162</a>. Perhaps this should supersede that.
</p>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/10552#comment:15
https://trac.sagemath.org/ticket/10552#comment:15
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/10552#comment:16
https://trac.sagemath.org/ticket/10552#comment:16
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/10552#comment:17
https://trac.sagemath.org/ticket/10552#comment:17
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/10552#comment:18
https://trac.sagemath.org/ticket/10552#comment:18
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
Ticket