Sage: Ticket #6882: bugs in conversion of variable names from Maxima to Sage
https://trac.sagemath.org/ticket/6882
<pre class="wiki">-----------
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string
sage: symbolic_expression_from_maxima_string('%i')
I
sage: symbolic_expression_from_maxima_string('i')
I
sage: symbolic_expression_from_maxima_string('%inf')
Inf
-----------
So as you see, we are converting both '%i' and 'i' to imaginary 'I' !!!!
</pre><p>
The ticket should implement <code>multi_word_replace()</code> in <code>sage.misc.multireplace</code> and use that on a symtable with additional entries <code>'e':'_e', 'i':'_i', 'I':'_I'</code>.
</p>
<p>
We do not want to be surprised when some new Maxima variable starting %i is introduced. At the moment it's really just a string replace from %i to I, without sense of word boundaries.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/6882
Trac 1.2Karl-Dieter CrismanFri, 23 Oct 2009 23:57:48 GMT
https://trac.sagemath.org/ticket/6882#comment:1
https://trac.sagemath.org/ticket/6882#comment:1
<p>
Here is the relevant <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/93713a7c32100625/31b2cd361def53b0?show_docid=31b2cd361def53b0#"><span class="icon"></span>discussion</a>.
</p>
TicketKarl-Dieter CrismanSat, 24 Oct 2009 00:04:01 GMT
https://trac.sagemath.org/ticket/6882#comment:2
https://trac.sagemath.org/ticket/6882#comment:2
<p>
This will also happen with %e and e, and any other similar pairs, so a fix should take care of all of them.
</p>
TicketRobert MarikTue, 23 Mar 2010 21:34:44 GMTupstream set
https://trac.sagemath.org/ticket/6882#comment:3
https://trac.sagemath.org/ticket/6882#comment:3
<ul>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
</ul>
<p>
As another consequence, solving of ode y'=c*x is not correct, the free variable is messed up with a parameter, see <a class="ext-link" href="http://groups.google.cz/group/sage-devel/browse_thread/thread/e04cbc547095f2ac"><span class="icon"></span>sage-devel</a> - thanks for
Yuri Karadzhov
</p>
<pre class="wiki">[marik@um-bc107 /opt/sage-4.3.4]$ ./sage
----------------------------------------------------------------------
| Sage Version 4.3.4, Release Date: 2010-03-19 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string
sage: symbolic_expression_from_maxima_string('%c')
c
sage: c=var('c'); y=function('y',x); eq=diff(y,x)==c*x; eq
D[0](y)(x) == c*x
sage: desolve(eq,y,ivar=x)
1/2*c*x^2 + c
</pre><p>
the answer should be something like 1/2*c*x<sup>2 + c1
</sup></p>
TicketJason GroutMon, 03 May 2010 17:35:13 GMT
https://trac.sagemath.org/ticket/6882#comment:4
https://trac.sagemath.org/ticket/6882#comment:4
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> for what I think is a "needs work" solution.
</p>
TicketJason GroutMon, 03 May 2010 17:36:52 GMT
https://trac.sagemath.org/ticket/6882#comment:5
https://trac.sagemath.org/ticket/6882#comment:5
<p>
Actually, I guess the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> will *help* with the solution, but may not totally solve the problem.
</p>
TicketRobert MarikSun, 04 Jul 2010 15:53:31 GMTcc set
https://trac.sagemath.org/ticket/6882#comment:6
https://trac.sagemath.org/ticket/6882#comment:6
<ul>
<li><strong>cc</strong>
<em>Robert Marik</em> added
</li>
</ul>
<p>
This should fix also <a class="closed ticket" href="https://trac.sagemath.org/ticket/9421" title="#9421: defect: desolve mixes user parameters and integration constants (closed: duplicate)">#9421</a>.
</p>
TicketKarl-Dieter CrismanThu, 26 Jul 2012 15:04:53 GMT
https://trac.sagemath.org/ticket/6882#comment:7
https://trac.sagemath.org/ticket/6882#comment:7
<p>
Also, in a situation where we <em>don't</em> have the duplication of constants, we get
</p>
<pre class="wiki">sage: c
Traceback (click to the left of this block for traceback)
...
NameError: name 'c' is not defined
</pre><p>
which isn't good either, though apparently that part of the expression still has type SymbolicExpression.
</p>
TicketJeroen DemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/6882#comment:8
https://trac.sagemath.org/ticket/6882#comment:8
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketFor batch modificationsThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/6882#comment:9
https://trac.sagemath.org/ticket/6882#comment:9
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketRalf StephanTue, 18 Feb 2014 07:39:57 GMTpriority changed
https://trac.sagemath.org/ticket/6882#comment:10
https://trac.sagemath.org/ticket/6882#comment:10
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>critical</em>
</li>
</ul>
<p>
Set to critical due to dependent tickets.
</p>
TicketRalf StephanSat, 08 Mar 2014 08:23:39 GMT
https://trac.sagemath.org/ticket/6882#comment:11
https://trac.sagemath.org/ticket/6882#comment:11TicketRalf StephanMon, 24 Mar 2014 17:59:05 GMT
https://trac.sagemath.org/ticket/6882#comment:12
https://trac.sagemath.org/ticket/6882#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:5" title="Comment 5">jason</a>:
</p>
<blockquote class="citation">
<p>
Actually, I guess the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> will *help* with the solution, but may not totally solve the problem.
</p>
</blockquote>
<p>
Indeed, because the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> (needing review) only is about vars, and it will only help with the problem in <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:3" title="Comment 3">comment:3</a> if the then marked sage vars are renamed to some other specific string before output in desolve...().
</p>
TicketRalf StephanMon, 24 Mar 2014 17:59:31 GMTdependencies set
https://trac.sagemath.org/ticket/6882#comment:13
https://trac.sagemath.org/ticket/6882#comment:13
<ul>
<li><strong>dependencies</strong>
set to <em>#8734</em>
</li>
</ul>
TicketRalf StephanWed, 26 Mar 2014 16:07:04 GMTdependencies changed
https://trac.sagemath.org/ticket/6882#comment:14
https://trac.sagemath.org/ticket/6882#comment:14
<ul>
<li><strong>dependencies</strong>
changed from <em>#8734</em> to <em>#8734, #16007</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:3" title="Comment 3">robert.marik</a>:
</p>
<blockquote class="citation">
<p>
As another consequence, solving of ode y'=c*x is not correct
...
the answer should be something like 1/2*c*x<sup>2 + c1
</sup></p>
</blockquote>
<p>
This one is resolved in <a class="closed ticket" href="https://trac.sagemath.org/ticket/16007" title="#16007: defect: give solution constants of ODEs unique names (closed: fixed)">#16007</a>. So it seems only variables are left (<a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a>).
</p>
TicketKarl-Dieter CrismanThu, 27 Mar 2014 16:43:23 GMT
https://trac.sagemath.org/ticket/6882#comment:15
https://trac.sagemath.org/ticket/6882#comment:15
<p>
Yes, variables are all that's left, but the other way around! (Don't forget the initial examples of this ticket.) We need to disambiguate Maxima variables like <code>i</code> and <code>e</code> from the things that become those in Sage - <code>%i</code> and <code>%e</code>. I suppose one could take the Maxima variables <code>i</code> and <code>I</code> and turn them into <code>_i</code> and <code>_I</code>, and likewise for e, as at <a class="closed ticket" href="https://trac.sagemath.org/ticket/16007" title="#16007: defect: give solution constants of ODEs unique names (closed: fixed)">#16007</a>, but I'm not sure if that's ideal or not. Thoughts?
</p>
TicketFor batch modificationsTue, 06 May 2014 15:19:32 GMTmilestone changed
https://trac.sagemath.org/ticket/6882#comment:16
https://trac.sagemath.org/ticket/6882#comment:16
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketRalf StephanFri, 06 Jun 2014 13:41:33 GMTpriority changed
https://trac.sagemath.org/ticket/6882#comment:17
https://trac.sagemath.org/ticket/6882#comment:17
<ul>
<li><strong>priority</strong>
changed from <em>critical</em> to <em>minor</em>
</li>
</ul>
<p>
Priority changed as the more important fixes were outsourced to other tickets.
</p>
TicketKarl-Dieter CrismanTue, 10 Jun 2014 00:19:11 GMT
https://trac.sagemath.org/ticket/6882#comment:18
https://trac.sagemath.org/ticket/6882#comment:18
<blockquote class="citation">
<p>
Priority changed as the more important fixes were outsourced to other tickets.
</p>
</blockquote>
<p>
Hmm, though the BDFL originally reported this with the comment
</p>
<pre class="wiki">I think my email must have not been clear. I think it's an instance
of a *HUGE BUG* in Sage. No more, no less.
</pre>
TicketKarl-Dieter CrismanTue, 24 Jun 2014 15:47:55 GMTpriority changed
https://trac.sagemath.org/ticket/6882#comment:19
https://trac.sagemath.org/ticket/6882#comment:19
<ul>
<li><strong>priority</strong>
changed from <em>minor</em> to <em>major</em>
</li>
</ul>
<p>
Maybe we can change the Maxima <code>i</code> and <code>e</code> to Sage <code>_i</code> and <code>_e</code>, leaving <code>%i</code> and <code>%e</code> to become <code>i</code> and <code>e</code> as currently, and then taking advantage of the last changes at <a class="closed ticket" href="https://trac.sagemath.org/ticket/16007" title="#16007: defect: give solution constants of ODEs unique names (closed: fixed)">#16007</a> for typesetting more-or-less properly.
</p>
TicketRalf StephanThu, 26 Jun 2014 09:39:30 GMTstatus changed
https://trac.sagemath.org/ticket/6882#comment:20
https://trac.sagemath.org/ticket/6882#comment:20
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
</ul>
<p>
The original bug report on sage-devel had:
</p>
<pre class="wiki">sage: var('i')
i
sage: i
i
sage: a = i^2
sage: a.simplify_full()
-1
</pre><p>
However, with develop I get <code>i^2</code>. Is this ticket still valid?
</p>
TicketKarl-Dieter CrismanThu, 26 Jun 2014 12:55:18 GMT
https://trac.sagemath.org/ticket/6882#comment:21
https://trac.sagemath.org/ticket/6882#comment:21
<p>
And indeed,
</p>
<pre class="wiki">sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string
sage: symbolic_expression_from_maxima_string('i')
i
sage: symbolic_expression_from_maxima_string('%i')
I
</pre><p>
And the original solving case William reported is also fixed.
</p>
<p>
Huh. Is this before or after <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a>? (I would imagine that one would have an impact.) Anyway, I would say we add some doctests (for both the <code>sefms</code> and <code>i^2</code> cases) and call it a day, regardless of which ticket it depends on. Good work, since ideally one wouldn't be creating a Maxima <code>i</code> and then trying to bring it to Sage.
</p>
TicketRalf StephanThu, 26 Jun 2014 16:48:28 GMTstatus changed
https://trac.sagemath.org/ticket/6882#comment:22
https://trac.sagemath.org/ticket/6882#comment:22
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_work</em>
</li>
</ul>
<p>
With develop:
</p>
<pre class="wiki">sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string
sage: symbolic_expression_from_maxima_string('t')
t
sage: symbolic_expression_from_maxima_string('i')
I
sage: var('i')
i
sage: symbolic_expression_from_maxima_string('i')
i
</pre><p>
So that example is a different animal than the ticket case.
</p>
TicketKarl-Dieter CrismanThu, 26 Jun 2014 19:50:30 GMT
https://trac.sagemath.org/ticket/6882#comment:23
https://trac.sagemath.org/ticket/6882#comment:23
<p>
Okay, I see. But the thing is that, in principle, we should never get <code>i</code> inside Maxima without asking for it via Sage having a variable <code>i</code>; we should only get <code>%i</code> the imaginary in Maxima, which translates differently (and correctly) now. Does that make sense, or do you think this is still worth fixing? (We should check what happens with <code>e</code> as well, maybe via <code>ln(e)</code>.)
</p>
TicketRalf StephanThu, 26 Jun 2014 20:48:09 GMT
https://trac.sagemath.org/ticket/6882#comment:24
https://trac.sagemath.org/ticket/6882#comment:24
<p>
With <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> <code>I</code> can result from a Sage <code>I</code> variable, from Maxima <code>%i</code>, or from Maxima <code>i</code> which is only creatable from Sage via the Maxima interface. But not from any trick involving the Sage variable <code>i</code> due to the protection via <code>_SAGE_VAR_</code>. The <code>i</code> case is why Jason said <a class="closed ticket" href="https://trac.sagemath.org/ticket/8734" title="#8734: defect: make sage variables unique in maxima (closed: fixed)">#8734</a> will help, but not totally solve the problem.
</p>
<p>
I don't know why the <code>i^2</code> example failed at all, and when exactly it stopped failing. Maybe it didn't fail; certainly nobody posted a confirmation message. And certainly we all confirmed the sefms snippet because that's what the ticket presented.
</p>
TicketKarl-Dieter CrismanThu, 26 Jun 2014 21:10:59 GMT
https://trac.sagemath.org/ticket/6882#comment:25
https://trac.sagemath.org/ticket/6882#comment:25
<p>
Yeah, even in Sage 4.4.4 (which I have lying around due to some custom fixes I use for research I'm too lazy to update)
</p>
<pre class="wiki">sage: var('i')
i
sage: i
i
sage: a = i^2
sage: a
i^2
sage: a.simplify_full()
i^2
</pre><p>
Your thoughts on a resolution? The thing that was a bug is not there any more, and the only potential bug is from 'user error', in some sense.
</p>
TicketRalf StephanFri, 27 Jun 2014 09:18:56 GMTowner, description, summary changed
https://trac.sagemath.org/ticket/6882#comment:26
https://trac.sagemath.org/ticket/6882#comment:26
<ul>
<li><strong>owner</strong>
changed from <em>Burcin Erocal</em> to <em>Ralf Stephan</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/6882?action=diff&version=26">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>bug in conversion of "i" from Maxima to Sage</em> to <em>bugs in conversion of variable names from Maxima to Sage</em>
</li>
</ul>
<p>
At the moment we also get behaviour like
</p>
<pre class="wiki">sage: symbolic_expression_from_maxima_string('%inf')
Inf
</pre><p>
so I think the ticket should implement <code>multi_word_replace()</code> in <code>sage.misc.multireplace</code> and use that on a symtable with additional entries <code>'e':'_e', 'i':'_i', 'I':'_I'</code>.
</p>
TicketKarl-Dieter CrismanFri, 27 Jun 2014 12:25:40 GMT
https://trac.sagemath.org/ticket/6882#comment:27
https://trac.sagemath.org/ticket/6882#comment:27
<blockquote class="citation">
<p>
At the moment we also get behaviour like
</p>
<pre class="wiki">sage: symbolic_expression_from_maxima_string('%inf')
Inf
</pre></blockquote>
<p>
Is <code>%inf</code> a normal Maxima expression, though? They just use <code>inf</code> and <code>minf</code>, I believe, which we replace correctly.
</p>
<blockquote class="citation">
<p>
so I think the ticket should implement <code>multi_word_replace()</code> in <code>sage.misc.multireplace</code> and use that on a symtable with additional entries <code>'e':'_e', 'i':'_i', 'I':'_I'</code>.
</p>
</blockquote>
<p>
I guess one could do so... I'm just trying to imagine cases in which this would be necessary due only to Sage usage. If someone uses Maxima to create variables it's quite different.
</p>
TicketRalf StephanFri, 27 Jun 2014 14:34:25 GMT
https://trac.sagemath.org/ticket/6882#comment:28
https://trac.sagemath.org/ticket/6882#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:27" title="Comment 27">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Is <code>%inf</code> a normal Maxima expression, though? They just use <code>inf</code> and <code>minf</code>, I believe, which we replace correctly.
</p>
</blockquote>
<p>
No but we do not want to be surprised when some new Maxima variable starting <code>%i</code> is introduced. At the moment it's really just a string replace from <code>%i</code> to <code>I</code>, without sense of word boundaries.
</p>
TicketRalf StephanFri, 27 Jun 2014 14:35:51 GMTdescription changed
https://trac.sagemath.org/ticket/6882#comment:29
https://trac.sagemath.org/ticket/6882#comment:29
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/6882?action=diff&version=29">diff</a>)
</li>
</ul>
TicketKarl-Dieter CrismanFri, 27 Jun 2014 14:44:44 GMT
https://trac.sagemath.org/ticket/6882#comment:30
https://trac.sagemath.org/ticket/6882#comment:30
<blockquote class="citation">
<blockquote class="citation">
<p>
Is <code>%inf</code> a normal Maxima expression, though? They just use <code>inf</code> and <code>minf</code>, I believe, which we replace correctly.
</p>
</blockquote>
<p>
No but we do not want to be surprised when some new Maxima variable starting <code>%i</code> is introduced. At the moment it's really just a string replace from <code>%i</code> to <code>I</code>, without sense of word boundaries.
</p>
</blockquote>
<p>
Aha! I didn't catch that was the reason. I don't think Maxima introduces many new constants with <code>%</code> but I see your point.
</p>
TicketRalf StephanSat, 28 Jun 2014 16:20:53 GMTbranch set
https://trac.sagemath.org/ticket/6882#comment:31
https://trac.sagemath.org/ticket/6882#comment:31
<ul>
<li><strong>branch</strong>
set to <em>u/rws/bugs_in_conversion_of_variable_names_from_maxima_to_sage</em>
</li>
</ul>
TicketRalf StephanSat, 28 Jun 2014 16:27:04 GMTstatus changed; commit, author set; dependencies deleted
https://trac.sagemath.org/ticket/6882#comment:32
https://trac.sagemath.org/ticket/6882#comment:32
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
set to <em>518de3e62533cd209997107f903192f1a31d118c</em>
</li>
<li><strong>dependencies</strong>
<em>#8734, #16007</em> deleted
</li>
<li><strong>author</strong>
set to <em>Ralf Stephan</em>
</li>
</ul>
<p>
I also found an error in the definition for maxima variable, because it didn't allow variable names without '%' or the '%' not at the beginning. Now the mentioned rules can be expressed as simple entries in symtable.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=4e0738355f228ea068bea927f3025dcccb955b1c"><span class="icon"></span>4e07383</a></td><td><code>6882: add rules for e, i, I</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e5a53435bde170e774c4e1dafba8f333a9653330"><span class="icon"></span>e5a5343</a></td><td><code>6882: do word search/replace for symtable keys</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=4c1b0eb5d6ff4b2b95487440c27c9879edb0131e"><span class="icon"></span>4c1b0eb</a></td><td><code>6882: correction to previous commit</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=518de3e62533cd209997107f903192f1a31d118c"><span class="icon"></span>518de3e</a></td><td><code>6882: add symable rules for e,i,I; fix maxima_var; add doctests</code>
</td></tr></table>
TicketRalf StephanSat, 28 Jun 2014 16:33:18 GMTdescription changed
https://trac.sagemath.org/ticket/6882#comment:33
https://trac.sagemath.org/ticket/6882#comment:33
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/6882?action=diff&version=33">diff</a>)
</li>
</ul>
TicketKarl-Dieter CrismanMon, 30 Jun 2014 14:36:27 GMT
https://trac.sagemath.org/ticket/6882#comment:34
https://trac.sagemath.org/ticket/6882#comment:34
<blockquote class="citation">
<p>
I also found an error in the definition for maxima variable, because it didn't allow variable names without '%' or the '%' not at the beginning. Now the mentioned rules can be expressed as simple entries in symtable.
</p>
</blockquote>
<p>
You'll note that <code>maxima_var</code> was never currently used in the codebase, so it wasn't a problem, more of just old code - <a class="ext-link" href="http://git.sagemath.org/sage.git/tree/src/sage/calculus/calculus.py#n1792"><span class="icon"></span>here</a> is where the <code>%</code> were all replaced. If you wanted I guess you could just replace that with <code>_</code> and it would be much more efficient than doing this whole loop every time, or so it seems to me. How does this do with <code>timeit</code> for long expressions one gets in 'real life'? (See sage/symbolic/random_tests.py.) Also note that usually we end up having to special-case things with <code>%</code> anyway - e.g., <code>%ilt</code> (inverse Laplace transform) gets handled somewhere else, I'd have to look up where.
</p>
TicketRalf StephanMon, 30 Jun 2014 15:30:47 GMT
https://trac.sagemath.org/ticket/6882#comment:35
https://trac.sagemath.org/ticket/6882#comment:35
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:34" title="Comment 34">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
How does this do with <code>timeit</code> for long expressions one gets in 'real life'? (See sage/symbolic/random_tests.py.)
</p>
</blockquote>
<p>
It's within the measurement error:
</p>
<pre class="wiki">sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string as sefms
sage: var('v1,v2,v3')
(v1, v2, v3)
sage: ex=-1/3*(pi + 1)*(3*(euler_gamma - e)*(pi - 3*v1 - v1/arcsech(1) + e^(-1)/pi) - 6*v3^2*arcsinh(-v1 + e)/v2 - v2 - 3*log_gamma(v1*v3)/v2 - 3*e^(-254) + 3)*(-catalan/v3)^(twinprime*pi - 1/2*v1 - 1/2*v2)*inverse_jacobi_cs(1, v3)/jacobi_sc(1/arccos(-1/(v1*csc(v3))), v3/v1 + e) - 1/4*(2*v3^2*(e + 1) + ((e*log_integral(arcsech(exp_integral_e1(v2^mertens - 1) - 4)) + 15*v1 + jacobi_dn(v2, pi))*v1*e^(-1) + golden_ratio*pi^v1*(1/v3^12 + jacobi_ds(-10, csc(v3^2)))^(v2 - 1/2/v2)*sinh(v2*e)/((v1 + v2 + v3 + 1)*v2))/(v1^2*inverse_jacobi_nc(v1, -e)) - 2*bessel_Y(v3, v2))/v2 + v3/inverse_jacobi_sc(1, v2) - (v1 + 1)/((v2 + v3)*(2*(v1 + e)*(v3 - 1)/(pi + v1) + (-v3*sech(v1*v3)/v2)^(-e/v1))) + inverse_jacobi_cn(pi + v1*v3, pi - v3) + jacobi_sn(e, arctanh(-(-log_integral(2) + log_integral(jacobi_ds(-1, v3)))^v2*e)^(1/7*(18*v2 - v3)*(14*v2 + e)/(v3*arctan(1/v2)*kronecker_delta(v1, v3))))
sage: timeit('sefms(str(ex))')
5 loops, best of 3: 2.19/2.14/2.15 s per loop (without #6882)
5 loops, best of 3: 2.13/2.11/2.12 s per loop (with #6882)
</pre><p>
Obviously the whole routine takes so long that the loop doesn't signify. That may be worth an optimization ticket alone.
</p>
<blockquote class="citation">
<p>
Also note that usually we end up having to special-case things with <code>%</code> anyway - e.g., <code>%ilt</code> (inverse Laplace transform) gets handled somewhere else, I'd have to look up where.
</p>
</blockquote>
<p>
Just put it in <code>symtable</code>, give it a special value, and ask for that value within the new loop. Having it all in the loop is more efficient than find every time.
</p>
TicketRalf StephanMon, 30 Jun 2014 16:06:17 GMT
https://trac.sagemath.org/ticket/6882#comment:36
https://trac.sagemath.org/ticket/6882#comment:36
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/6882#comment:35" title="Comment 35">rws</a>:
</p>
<blockquote class="citation">
<pre class="wiki">sage: timeit('sefms(str(ex))')
5 loops, best of 3: 2.19/2.14/2.15 s per loop (without #6882)
5 loops, best of 3: 2.13/2.11/2.12 s per loop (with #6882)
</pre></blockquote>
<p>
It calls 120 times the function <code>MaximaLib._eval_line()</code> which takes 17ms in average = 2 seconds. 17 ms is an eternity.
</p>
TicketKarl-Dieter CrismanMon, 30 Jun 2014 16:10:19 GMT
https://trac.sagemath.org/ticket/6882#comment:37
https://trac.sagemath.org/ticket/6882#comment:37
<blockquote class="citation">
<blockquote class="citation">
<pre class="wiki">sage: timeit('sefms(str(ex))')
5 loops, best of 3: 2.19/2.14/2.15 s per loop (without #6882)
5 loops, best of 3: 2.13/2.11/2.12 s per loop (with #6882)
</pre></blockquote>
</blockquote>
<p>
Wow, those timings are indeed an eternity, though presumably not for shorter expressions. I'll put this ticket in my "finally finish reviewing" queue, then, for sure.
</p>
TicketKarl-Dieter CrismanWed, 02 Jul 2014 02:44:01 GMTreviewer set
https://trac.sagemath.org/ticket/6882#comment:38
https://trac.sagemath.org/ticket/6882#comment:38
<ul>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
</ul>
<p>
Well, it's an improvement, though still not perfect:
</p>
<pre class="wiki"># Before
sage: sefms('%inf')
Inf
sage: sefms('%minf')
-Infinity
# After
sage: sefms('%inf')
+Infinity
sage: sefms('%minf')
-Infinity
</pre><p>
Neither of these are infinity in Maxima, of course. And indeed here is what the <a class="ext-link" href="http://maxima.sourceforge.net/docs/manual/en/maxima_6.html#SEC32"><span class="icon"></span>Maxima manual</a> says about identifiers:
</p>
<pre class="wiki">(%i1) %an_ordinary_identifier42;
(%o1) %an_ordinary_identifier42
</pre><p>
"A numeral may be the first character of an identifier if it is preceded by a backslash. " But I don't know that we need to translate all identifiers in Maxima to Sage here... I guess I'm torn about that.
</p>
<pre class="wiki">sage: timeit('sefms(str(ex))')
5 loops, best of 3: 2.19/2.14/2.15 s per loop (without #6882)
5 loops, best of 3: 2.13/2.11/2.12 s per loop (with #6882)
</pre><p>
Of course, thinking about it, that string is a Sage string, not a Maxima string, so <code>%time R = random_expr(50,nvars=2); sefms(repr(R._maxima_()))</code> is probably more accurate, but that is also wildly variant on the expression.
</p>
<p>
Okay, as far as I can tell this will not break anything (let's really hope!) and fixes the actual problem without slowing down what is already a very slow process (even for <code>random_expr(5,nvars=2)</code> it's 2-3 milliseconds either way). Step in right direction, and again most people should not be affected in the slightest. If passes tests, let's get it in.
</p>
TicketKarl-Dieter CrismanWed, 02 Jul 2014 03:03:09 GMTstatus changed
https://trac.sagemath.org/ticket/6882#comment:39
https://trac.sagemath.org/ticket/6882#comment:39
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketVolker BraunThu, 03 Jul 2014 12:41:31 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/6882#comment:40
https://trac.sagemath.org/ticket/6882#comment:40
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/rws/bugs_in_conversion_of_variable_names_from_maxima_to_sage</em> to <em>518de3e62533cd209997107f903192f1a31d118c</em>
</li>
</ul>
Ticket