Sage: Ticket #12809: Solve does not give consistent results when a dummy variable is involved
https://trac.sagemath.org/ticket/12809
<p>
When working on another ticket (<a class="needs_work ticket" href="https://trac.sagemath.org/ticket/11201" title="#11201: enhancement: Point users of solve() to the to_poly_solve option (needs_work)">#11201</a>) that involves documentation for the solve function, doing doctests proved to be frustrating. I added to the examples section of the docstring, and then multiple tests failed. I did some manual testing in sage and noticed a problem:
</p>
<pre class="wiki">sage: var('x y')
(x, y)
sage: solve(cos(x)*sin(y)==1/2, x+y==0,x,y)
[[x == 1/4*pi + pi*z6, y == -1/4*pi - pi*z6]]
</pre><p>
This is a perfectly valid answer, except that when I tried to solve the same equations again, the answer is different:
</p>
<pre class="wiki">sage: solve(cos(x)*sin(y)==1/2, x+y==0,x,y)
[[x == 1/4*pi + pi*z14, y == -1/4*pi - pi*z14]]
</pre><p>
This is still mathematically correct.
If I solve them many more times, z's coefficient keeps going up by 8:
</p>
<pre class="wiki">sage: solve(cos(x)*sin(y)==1/2, x+y==0,x,y)
[[x == 1/4*pi + pi*z22, y == -1/4*pi - pi*z22]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z30, y == -1/4*pi - pi*z30]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z38, y == -1/4*pi - pi*z38]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z46, y == -1/4*pi - pi*z46]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z54, y == -1/4*pi - pi*z54]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z62, y == -1/4*pi - pi*z62]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z70, y == -1/4*pi - pi*z70]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z78, y == -1/4*pi - pi*z78]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z86, y == -1/4*pi - pi*z86]]
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z94, y == -1/4*pi - pi*z94]]
</pre><p>
All still mathematically correct.
</p>
<p>
This is a problem when you are trying to add examples to the documentation for solve and many doctests fail because the coefficients for the dummy variable are shifted up by some integer amount. I have included the file expressions_pyx_doctests.txt to show more of what I am talking about. To cause this, I added two examples, and the examples that I added were not complained about in the doctest. Also, z's coefficient went up by 6 this time, different than 8 in the first example.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12809
Trac 1.2Andrew FleckensteinThu, 05 Apr 2012 01:23:12 GMTattachment set
https://trac.sagemath.org/ticket/12809
https://trac.sagemath.org/ticket/12809
<ul>
<li><strong>attachment</strong>
set to <em>expression_pyx_doctest.txt</em>
</li>
</ul>
TicketKarl-Dieter CrismanThu, 05 Apr 2012 01:45:24 GMT
https://trac.sagemath.org/ticket/12809#comment:1
https://trac.sagemath.org/ticket/12809#comment:1
<p>
This is a known issue - I won't call it a problem, though some people (like the reporter) certainly have strong feelings on this. People have tried to weasel out of it in changing doctests by putting ellipses in for the variable names, but in the end it's better to show the end user reading the documentation what a likely output actually looks like. Concur that it's annoying for those writing doctests, but at least in one opinion this is not really a bug.
</p>
<p>
That said, if we can be smart enough with Maxima and how it's naming these dummy variables for this not to happen, or to return something different, that would be great. But it's probably not worth the effort, given how many actual enhancements or bugs we can fix instead :-)
</p>
TicketWilliam SteinFri, 06 Apr 2012 22:52:52 GMT
https://trac.sagemath.org/ticket/12809#comment:2
https://trac.sagemath.org/ticket/12809#comment:2
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12809#comment:1" title="Comment 1">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
This is a known issue - I won't call it a problem, though some people (like the reporter) certainly have strong feelings on this. People have tried to weasel out of it in changing doctests by putting ellipses in for the variable names, but in the end it's better to show the end user reading the documentation what a likely output actually looks like.
</p>
</blockquote>
<p>
I completely disagree with you. I think it is perfectly reasonable to replace an example like
</p>
<pre class="wiki">sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z94, y == -1/4*pi - pi*z94]]
</pre><p>
with
</p>
<pre class="wiki">sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
[[x == 1/4*pi + pi*z..., y == -1/4*pi - pi*z...]]
</pre><p>
Alternatively, if this is NOT intended for somebody to actually read, then simply make it a "unit test", e.g., put all the tests into a function (e.g., "test_solve"), then do whatever you want to verify correctness of output using asserts, and finally put one single doctest in test_solve, which is:
</p>
<pre class="wiki">sage: test_solve()
</pre>
TicketWilliam SteinFri, 06 Apr 2012 22:54:57 GMT
https://trac.sagemath.org/ticket/12809#comment:3
https://trac.sagemath.org/ticket/12809#comment:3
<p>
This does suggest we may want to consider reseting Maxima's counter for dummy variables before calling solve.
</p>
TicketNils BruinSat, 07 Apr 2012 05:19:46 GMT
https://trac.sagemath.org/ticket/12809#comment:4
https://trac.sagemath.org/ticket/12809#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12809#comment:3" title="Comment 3">was</a>:
</p>
<blockquote class="citation">
<p>
This does suggest we may want to consider reseting Maxima's counter for dummy variables before calling solve.
</p>
</blockquote>
<p>
It would require care of the user to remember whether different occurrences of the same variable name refer to independent parameters or not, but to_poly has a convenience function to relabel the temporaries:
</p>
<pre class="wiki">(%i1) load(to_poly_solver);
(%o1) ...
(%i2) display2d: false;
(%o2) false
(%i3) nicedummies(to_poly_solve([sin(x)=cos(x)],[x]));
(%o3) %union([x = (4*%pi*%z0+%pi)/4])
(%i4) nicedummies(to_poly_solve([sin(x)=cos(x)],[x]));
(%o4) %union([x = (4*%pi*%z0+%pi)/4])
</pre><p>
I think the slight inconvenience of getting new names every time is preferable to the ambiguity that is caused by reusing names among several equation solves. Another issue is that the maxima-to-sage conversion maps %z1 to z1 without checking. This can lead to further unintended name collisions.
</p>
<p>
(but then again, if someone is willing to use the results returned by a CAS solve routine without checking, they're asking for trouble anyway)
</p>
TicketAndrew FleckensteinSat, 07 Apr 2012 11:39:46 GMTpriority changed
https://trac.sagemath.org/ticket/12809#comment:5
https://trac.sagemath.org/ticket/12809#comment:5
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>minor</em>
</li>
</ul>
TicketMichael OrlitzkyFri, 13 Apr 2012 03:41:44 GMTcc changed
https://trac.sagemath.org/ticket/12809#comment:6
https://trac.sagemath.org/ticket/12809#comment:6
<ul>
<li><strong>cc</strong>
<em>Michael Orlitzky</em> added
</li>
</ul>
<p>
I implemented <code>MaximaLibElement.nicedummies()</code>, but it seems that once you make the round-trip through sage, the information that zXX is a dummy is lost:
</p>
<pre class="wiki">from sage.interfaces.maxima_lib import maxima_lib
sage: y = var('y')
sage: soln = solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
sage: maxima_lib(soln[0][0])
x=%pi*z36+%pi/4
sage: maxima_lib(soln[0][0]).nicedummies()
x=%pi*z36+%pi/4
</pre><p>
(The function does actually work before you leave Maxima.)
</p>
<p>
So, we'd either have to add a <code>nicedummies</code> parameter to each of the routines that return them, or write our own implementation that works entirely within sage.
</p>
TicketNils BruinFri, 13 Apr 2012 06:57:30 GMT
https://trac.sagemath.org/ticket/12809#comment:7
https://trac.sagemath.org/ticket/12809#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12809#comment:6" title="Comment 6">mjo</a>:
</p>
<blockquote class="citation">
<p>
I implemented <code>MaximaLibElement.nicedummies()</code>, but it seems that once you make the round-trip through sage, the information that zXX is a dummy is lost
</p>
</blockquote>
<p>
This is mainly for documentation and sufficient cross linking. In <a class="ext-link" href="https://groups.google.com/group/sage-devel/msg/62404b9d395cce94?hl=en"><span class="icon"></span>this sage-devel thread</a> the cause is described: maxima's <code>%z2</code> gets translated to <code>z2</code> in sage and then to <code>z2</code> in maxima, so the variables get renamed.
</p>
<p>
See <code>nicedummies</code> in maxima's <code>share/contrib/topoly.lisp</code> to see how "dummies" get recognized (it's a property hanging off the symbol, not the name of the symbol)
</p>
TicketEviatar BachWed, 01 May 2013 04:42:17 GMTcc changed
https://trac.sagemath.org/ticket/12809#comment:8
https://trac.sagemath.org/ticket/12809#comment:8
<ul>
<li><strong>cc</strong>
<em>Eviatar Bach</em> added
</li>
</ul>
TicketJeroen DemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/12809#comment:9
https://trac.sagemath.org/ticket/12809#comment:9
<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/12809#comment:10
https://trac.sagemath.org/ticket/12809#comment:10
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketFor batch modificationsTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/12809#comment:11
https://trac.sagemath.org/ticket/12809#comment:11
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketFor batch modificationsSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/12809#comment:12
https://trac.sagemath.org/ticket/12809#comment:12
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketPeleg MichaeliWed, 23 Nov 2016 07:33:53 GMT
https://trac.sagemath.org/ticket/12809#comment:13
https://trac.sagemath.org/ticket/12809#comment:13
<p>
Should we update the milestone?
</p>
Ticket