Sage: Ticket #22322: allow sympy algorithm in solve
https://trac.sagemath.org/ticket/22322
<p>
What it says. See e.g. <a class="ext-link" href="https://ask.sagemath.org/question/36469/understanding-solve/"><span class="icon"></span>this post</a> for why.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/22322
Trac 1.1.6mforetsSat, 20 May 2017 09:51:55 GMTcc changed
https://trac.sagemath.org/ticket/22322#comment:1
https://trac.sagemath.org/ticket/22322#comment:1
<ul>
<li><strong>cc</strong>
<em>mforets</em> added
</li>
</ul>
<p>
AFAIK, also useful for equations where the unkown appears as an exponent, cf. <a class="ext-link" href="https://ask.sagemath.org/question/37640/solving-returns-x/"><span class="icon"></span>solve(4.94 * 1.062^x == 15, x)</a>
</p>
TickettmonteilSat, 20 May 2017 16:48:55 GMTcc changed
https://trac.sagemath.org/ticket/22322#comment:2
https://trac.sagemath.org/ticket/22322#comment:2
<ul>
<li><strong>cc</strong>
<em>tmonteil</em> added
</li>
</ul>
TicketmforetsSun, 04 Jun 2017 13:05:51 GMT
https://trac.sagemath.org/ticket/22322#comment:3
https://trac.sagemath.org/ticket/22322#comment:3
<p>
<code>solve</code> (from <code>expression.pyx</code>) passes a relational expression to Maxima's solve, but this doesn't seem to be available in sympy:
</p>
<pre class="wiki">sage: (x==1)._maxima_()
_SAGE_VAR_x=1
sage: (x==1)._sympy_()
Traceback (most recent call last)
...
NotImplementedError: relation
</pre><p>
do you have some idea on how to tackle this? otherwise, what about passing <code>ex.lhs()-ex.rhs()</code> to sympy's solve.
</p>
TicketrwsMon, 05 Jun 2017 05:36:19 GMT
https://trac.sagemath.org/ticket/22322#comment:4
https://trac.sagemath.org/ticket/22322#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:3" title="Comment 3">mforets</a>:
</p>
<blockquote class="citation">
<p>
<code>solve</code> (from <code>expression.pyx</code>) passes a relational expression to Maxima's solve, but this doesn't seem to be available in sympy:
...
do you have some idea on how to tackle this? otherwise, what about passing <code>ex.lhs()-ex.rhs()</code> to sympy's solve.
</p>
</blockquote>
<p>
Yes, that would be it for the equalities. For inequalities <code>SympyConverter.relation()</code> is needed (atm the superclass's <code>relation</code> is called).
</p>
TicketrwsMon, 05 Jun 2017 05:38:23 GMT
https://trac.sagemath.org/ticket/22322#comment:5
https://trac.sagemath.org/ticket/22322#comment:5
<p>
Correction, doing <code>ex.lhs()-ex.rhs()</code> is not needed if the <code>SympyConverter</code> is fixed.
</p>
TicketrwsSun, 08 Oct 2017 14:21:18 GMTdependencies set
https://trac.sagemath.org/ticket/22322#comment:6
https://trac.sagemath.org/ticket/22322#comment:6
<ul>
<li><strong>dependencies</strong>
set to <em>#23990</em>
</li>
</ul>
TicketcharpentMon, 09 Oct 2017 20:37:30 GMTcc changed
https://trac.sagemath.org/ticket/22322#comment:7
https://trac.sagemath.org/ticket/22322#comment:7
<ul>
<li><strong>cc</strong>
<em>charpent</em> added
</li>
</ul>
TicketcharpentTue, 10 Oct 2017 11:17:50 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:8
https://trac.sagemath.org/ticket/22322#comment:8
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
</ul>
<p>
Hmmm...
</p>
<pre class="wiki">sage: var("a,b")
(a, b)
sage: sympy.sympify(a==b)._sage_()
a == b
sage: sympy.sympify(a==b).sage()
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-14-25de6a4c8f0a> in <module>()
----> 1 sympy.sympify(a==b).sage()
AttributeError: 'Equality' object has no attribute 'sage'
</pre><p>
Is that the expected behaviour ? Or do you plan to enhance the <code>.sage()</code> method for various objects ?
</p>
<p>
It is not obvious to me why (e. g.) mathematica objets can (sometimes...) be converted back to sage via the <code>.sage()</code> (exposed) method, whereas Sympy objects have to use the <code>._sage_()</code> (unexposed method.
</p>
TicketrwsTue, 10 Oct 2017 13:28:33 GMT
https://trac.sagemath.org/ticket/22322#comment:9
https://trac.sagemath.org/ticket/22322#comment:9
<p>
As I explained in <a class="closed ticket" href="https://trac.sagemath.org/ticket/23990" title="defect: Convert symbolic relations to/from SymPy (closed: fixed)">#23990</a> that is the SymPy convention.
</p>
TicketcharpentTue, 10 Oct 2017 13:56:52 GMT
https://trac.sagemath.org/ticket/22322#comment:10
https://trac.sagemath.org/ticket/22322#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:9" title="Comment 9">rws</a>:
</p>
<blockquote class="citation">
<p>
As I explained in <a class="closed ticket" href="https://trac.sagemath.org/ticket/23990" title="defect: Convert symbolic relations to/from SymPy (closed: fixed)">#23990</a> that is the SymPy convention.
</p>
</blockquote>
<p>
Wups, <del>bad</del> wrong ticket. I <em>thought</em> that my comment was cancelled ; it was not.
</p>
<p>
Apologies...
</p>
TicketrwsFri, 20 Oct 2017 13:06:01 GMTdependencies, milestone changed
https://trac.sagemath.org/ticket/22322#comment:11
https://trac.sagemath.org/ticket/22322#comment:11
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990</em> to <em>#23990, #24078</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-7.6</em> to <em>sage-8.2</em>
</li>
</ul>
<p>
Now that (with <a class="closed ticket" href="https://trac.sagemath.org/ticket/23990" title="defect: Convert symbolic relations to/from SymPy (closed: fixed)">#23990</a>) relations are translated from/to SymPy there are still things needed. For example we need to translate any assumptions on variables (and maybe anon. functions?) that were made using <code>assume</code> and <code>var('x', domain=...)</code>. This is not only relevant for this ticket, any SymPy operation may access the SymPy knowledge base any time. So I think this should be handled the same way as with Maxima, i.e. at the time the <code>assume</code>/<code>var</code> calls are made. This is <a class="new ticket" href="https://trac.sagemath.org/ticket/24078" title="enhancement: Set assumptions in SymPy too when doing assume() (new)">#24078</a>.
</p>
TicketrwsFri, 20 Oct 2017 13:33:10 GMTdependencies changed
https://trac.sagemath.org/ticket/22322#comment:12
https://trac.sagemath.org/ticket/22322#comment:12
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990, #24078</em> to <em>#23990</em>
</li>
</ul>
<p>
Note that SymPy's solve does not respect the global assumptions database:
</p>
<pre class="wiki">In [12]: global_assumptions
Out[12]: AssumptionsContext([Q.is_true(x > 2), Q.positive(x)])
In [13]: solve(x<3)
Out[13]: -∞ < x ∧ x < 3
In [15]: solve((x>2,x<3))
Out[15]: 2 < x ∧ x < 3
</pre><p>
So the dependency is irrelevant (at the moment).
</p>
TicketrwsFri, 20 Oct 2017 13:51:35 GMT
https://trac.sagemath.org/ticket/22322#comment:13
https://trac.sagemath.org/ticket/22322#comment:13
<p>
Our solve doesn't either, so it all is localized in the solve arguments:
</p>
<pre class="wiki">sage: assume(x>2)
sage: solve(x<3,x)
[[x < 3]]
sage: solve((x>2,x<3),x)
[[2 < x, x < 3]]
</pre>
TicketrwsFri, 20 Oct 2017 14:47:22 GMT
https://trac.sagemath.org/ticket/22322#comment:14
https://trac.sagemath.org/ticket/22322#comment:14
<p>
Our solve's output is quite opaque IMHO:
</p>
<pre class="wiki">sage: solve((x^2<1),x)
[[x > -1, x < 1]]
sage: solve((x^2>1),x)
[[x < -1], [x > 1]]
</pre><p>
From a glance, which is AND, which is OR? So I would like to use <code>And(...)</code> and <code>Or(...)</code> as in SymPy but:
</p>
<pre class="wiki">sage: Or = function('Or')
sage: ex = Or(x<0, x>1)
sage: ex
Or(x < 0, x > 1)
sage: ex.args()
(x,)
sage: ex.operands()
[x < 0, x > 1]
sage: ex[0]
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-8-c8fc37b12ad9> in <module>()
----> 1 ex[Integer(0)]
TypeError: 'sage.symbolic.expression.Expression' object does not support indexing
</pre><p>
So people would need to know that <code>operands()</code> gets the solutions. Or we support indexing as alias to <code>operands()</code>.
</p>
TicketrwsFri, 20 Oct 2017 15:26:56 GMTdependencies changed
https://trac.sagemath.org/ticket/22322#comment:15
https://trac.sagemath.org/ticket/22322#comment:15
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990</em> to <em>#23990, #24080</em>
</li>
</ul>
TicketrwsTue, 24 Oct 2017 14:35:11 GMTdependencies changed
https://trac.sagemath.org/ticket/22322#comment:16
https://trac.sagemath.org/ticket/22322#comment:16
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990, #24080</em> to <em>#23990</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:14" title="Comment 14">rws</a>:
</p>
<blockquote class="citation">
<p>
So people would need to know that <code>operands()</code> gets the solutions. Or we support indexing as alias to <code>operands()</code>.
</p>
</blockquote>
<p>
Supporting expression indexing seems tricky. Also this is an interface change. Better move it to a future ticket.
</p>
TicketrwsWed, 25 Oct 2017 07:48:43 GMT
https://trac.sagemath.org/ticket/22322#comment:17
https://trac.sagemath.org/ticket/22322#comment:17
<p>
I cannot believe devs maintained two different versions of <code>solve</code> in <code>symbolic/expression.pyx</code> and <code>symbolic/relation.py</code>. <code>expression.pyx</code> should only be an interface to a function elsewhere, preferably in <code>solve.py</code>.
</p>
TicketmforetsWed, 25 Oct 2017 09:49:49 GMT
https://trac.sagemath.org/ticket/22322#comment:18
https://trac.sagemath.org/ticket/22322#comment:18
<blockquote class="citation">
<blockquote>
<p>
Note that <a class="missing wiki">SymPy?</a>'s solve does not respect the global assumptions database:
</p>
</blockquote>
</blockquote>
<p>
shall we consider interfacing with <a class="missing wiki">SymPy?</a>'s <a class="ext-link" href="http://docs.sympy.org/latest/modules/solvers/solveset.html"><span class="icon"></span>solveset</a>? it is said to supersede <a class="ext-link" href="http://docs.sympy.org/latest/modules/solvers/solvers.html"><span class="icon"></span>solve</a> sooner or later.
</p>
<p>
i find that the interface <code>(equation, variable, domain)</code> is very clear. isn't it preferable than relying on global assumptions? (or to fallback into the global assumptions if the domain is not provided.)
</p>
TicketcharpentWed, 25 Oct 2017 10:32:08 GMT
https://trac.sagemath.org/ticket/22322#comment:19
https://trac.sagemath.org/ticket/22322#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:18" title="Comment 18">mforets</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote>
<p>
Note that <a class="missing wiki">SymPy?</a>'s solve does not respect the global assumptions database:
</p>
</blockquote>
</blockquote>
<p>
shall we consider interfacing with <a class="missing wiki">SymPy?</a>'s <a class="ext-link" href="http://docs.sympy.org/latest/modules/solvers/solveset.html"><span class="icon"></span>solveset</a>? it is said to supersede <a class="ext-link" href="http://docs.sympy.org/latest/modules/solvers/solvers.html"><span class="icon"></span>solve</a> sooner or later.
</p>
</blockquote>
<p>
Fly in the ointment : <code>solve</code> can solve <strong>systems</strong> of equations, whereas <code>solveset</code> (which is, indeed, cleaner on more than one aspect), solves only equations.
</p>
<p>
In order to solve system, we would have to map <code>solveset</code> to all the equations in the system (each for one variable (which one ?)), and return the intersection of the results, which is currently problematic.
</p>
<blockquote class="citation">
<p>
i find that the interface <code>(equation, variable, domain)</code> is very clear. isn't it preferable than relying on global assumptions? (or to fallback into the global assumptions if the domain is not provided.)
</p>
</blockquote>
<p>
The domain is only a part of the possible assumptions : e. g., maxima often asks if some expression is positive, if such variable is integer, etc... We need to maintain a "knowledge base" about outr variables as least as rich as our current (= Maxima's) facts base.
</p>
<p>
A few remarks :
</p>
<p>
1) I note that Sympy's knowledge base is richer than ours, BTW.
</p>
<p>
2) We might use profitably something analogous to Mathematica's <code>Assuming</code> statement, which does something (roughly )equivalent to :
</p>
<pre class="wiki">def assuming(condset, statement):
try:
OldAssumptions=assumptions()
Assumptions=OldAssumptions.copy()
Assumptions.extend(condset)
forget(assumptions())
assume(Assumptions)
result=<do statement, somehow>
finally:
forget(assumptions())
assume(OldAssumptions)
</pre><p>
The wasp in the ointment is of course that <code>statement</code> is evaluated before being passed to Assuming : Python has no macroes...
</p>
<p>
I <em>think</em> that <code>assuming</code> could be implemented somehow as a decorator, but I'm still to understand <em>that</em>.
</p>
TicketrwsWed, 25 Oct 2017 13:01:54 GMT
https://trac.sagemath.org/ticket/22322#comment:20
https://trac.sagemath.org/ticket/22322#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:18" title="Comment 18">mforets</a>:
</p>
<blockquote class="citation">
<p>
i find that the interface <code>(equation, variable, domain)</code> is very clear. isn't it preferable than relying on global assumptions?
</p>
</blockquote>
<p>
I have abandoned the idea of respecting assumptions after I saw that SymPy doesn't either. We don't have to reproduce Maxima results so we're good.
</p>
<blockquote class="citation">
<p>
solve can solve systems of equations, whereas solveset (which is, indeed, cleaner on more than one aspect), solves only equations.
</p>
</blockquote>
<p>
If they replace it will be unified. And I think Sage's <code>ex.solve()</code> and <code>solve(ex)</code> should be unified too, if for no other reason than for better maintenance.
</p>
<blockquote class="citation">
<p>
In order to solve system, we would have to map solveset to all the equations in the system (each for one variable (which one ?)), and return the intersection of the results, which is currently problematic.
</p>
</blockquote>
<p>
It's always problematic because you need to decide ordering of expressions without variables, and that can take time because of the possible need to increase precision. The question is, should we support SymPy's solve or immediately use solveset exclusively?
</p>
<blockquote class="citation">
<p>
We might use profitably something analogous to Mathematica's Assuming
</p>
</blockquote>
<p>
Please review <a class="closed ticket" href="https://trac.sagemath.org/ticket/10035" title="enhancement: Hold context (closed: fixed)">#10035</a>.
</p>
<blockquote class="citation">
<p>
We need to maintain a "knowledge base" about outr variables as least as rich as our current (= Maxima's) facts base.
</p>
</blockquote>
<p>
Isn't that the same as a local context?
</p>
TicketrwsWed, 25 Oct 2017 13:32:24 GMTdependencies changed
https://trac.sagemath.org/ticket/22322#comment:21
https://trac.sagemath.org/ticket/22322#comment:21
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990</em> to <em>#23990, #24104</em>
</li>
</ul>
TicketcharpentWed, 25 Oct 2017 20:06:07 GMT
https://trac.sagemath.org/ticket/22322#comment:22
https://trac.sagemath.org/ticket/22322#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:20" title="Comment 20">rws</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:18" title="Comment 18">mforets</a>:
</p>
</blockquote>
<p>
And me, it seems...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
i find that the interface <code>(equation, variable, domain)</code> is very clear. isn't it preferable than relying on global assumptions?
</p>
</blockquote>
<p>
I have abandoned the idea of respecting assumptions after I saw that SymPy doesn't either. We don't have to reproduce Maxima results so we're good.
</p>
</blockquote>
<p>
That's pushing the can down the road : in order to get the solutions, we're bound to solve a system comprising the solutions obtained without the assumptions and the assumptions themselves, which might be unsolvable (e. g. cubic equation with a solution in <em>casus irreducibilis</em> + constraints showing that the roots are real)...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
solve can solve systems of equations, whereas solveset (which is, indeed, cleaner on more than one aspect), solves only equations.
</p>
</blockquote>
<p>
If they replace it will be unified. And I think Sage's <code>ex.solve()</code> and <code>solve(ex)</code> should be unified too, if for no other reason than for better maintenance.
</p>
</blockquote>
<p>
Indeed. If...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
In order to solve system, we would have to map solveset to all the equations in the system (each for one variable (which one ?)), and return the intersection of the results, which is currently problematic.
</p>
</blockquote>
<p>
It's always problematic because you need to decide ordering of expressions without variables, and that can take time because of the possible need to increase precision. The question is, should we support SymPy's solve or immediately use solveset exclusively?
</p>
</blockquote>
<p>
IMHO, both. But that might be a lot of work.. Depends on your prognosis on the time necessary for the Sympy team to coax <code>solveset</code> in solving systems...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
We might use profitably something analogous to Mathematica's Assuming
</p>
</blockquote>
<p>
Please review <a class="closed ticket" href="https://trac.sagemath.org/ticket/10035" title="enhancement: Hold context (closed: fixed)">#10035</a>.
</p>
</blockquote>
<p>
Done (positively). But that is a possible solution only for function calls supporting <code>hold</code>. <code>solve</code> isn't one of them.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
We need to maintain a "knowledge base" about outr variables as least as rich as our current (= Maxima's) facts base.
</p>
</blockquote>
<p>
Isn't that the same as a local context?
</p>
</blockquote>
<p>
I do not understand that (yet). Care to amplify ?
</p>
<p>
And, BTW, thank you for the huge work you are doing on Sympy, which might turn out very important for Sage.
</p>
TicketrwsThu, 26 Oct 2017 06:42:25 GMT
https://trac.sagemath.org/ticket/22322#comment:23
https://trac.sagemath.org/ticket/22322#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:22" title="Comment 22">charpent</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:18" title="Comment 18">mforets</a>:
Please review <a class="closed ticket" href="https://trac.sagemath.org/ticket/10035" title="enhancement: Hold context (closed: fixed)">#10035</a>.
</p>
</blockquote>
<p>
Done (positively). But that is a possible solution only for function calls supporting <code>hold</code>. <code>solve</code> isn't one of them.
</p>
</blockquote>
<p>
It motivates me to create a context infrastructure where you can say:
</p>
<pre class="wiki">sage: mycontext = context(x>0, hold)
sage: with mycontext:
sage: solve(...)
</pre><p>
or
</p>
<pre class="wiki">sage: mycontext.start()
sage: ...
sage: solve(...)
sage: mycontext.stop()
</pre><blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
We need to maintain a "knowledge base" about outr variables as least as rich as our current (= Maxima's) facts base.
</p>
</blockquote>
<p>
Isn't that the same as a local context?
</p>
</blockquote>
<p>
I do not understand that (yet). Care to amplify ?
</p>
</blockquote>
<p>
I gave the first answer in order to give an idea.
</p>
<blockquote class="citation">
<p>
And, BTW, thank you for the huge work you are doing on Sympy, which might turn out very important for Sage.
</p>
</blockquote>
<p>
I remember reading in devel that previous developers hoped so too, also because at that time development on Pynac stopped and practically no one worked on symbolics in Sage. While that's no longer the case, solvers and integration need much help from SymPy, Fricas, and Giac.
</p>
TicketrwsThu, 26 Oct 2017 13:41:53 GMT
https://trac.sagemath.org/ticket/22322#comment:24
https://trac.sagemath.org/ticket/22322#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:19" title="Comment 19">charpent</a>:
</p>
<blockquote class="citation">
<p>
In order to solve system, we would have to map <code>solveset</code> to all the equations in the system (each for one variable (which one ?)), and return the intersection of the results, which is currently problematic.
</p>
</blockquote>
<p>
Maybe we should not worry about doing intersections, convert to <code>RealSet</code>, intersect, convert back. <code>RealSet</code> uses <code>RealInterval</code> for comparison and I guess the problems have been thought about by its developers. But what to convert the <code>RealSet</code> to in the end? For starters the output of <code>solve</code> at the moment, i.e., lists of lists. The conversion <code>RealSet</code>-->lists might be of broader interest.
</p>
TicketrwsThu, 26 Oct 2017 13:56:20 GMT
https://trac.sagemath.org/ticket/22322#comment:25
https://trac.sagemath.org/ticket/22322#comment:25
<p>
Caveat of using <code>RealSet</code>:
</p>
<pre class="wiki">sage: pi.n(30) in RealSet.point(pi)
False
sage: pi.n(50) in RealSet.point(pi)
True
</pre>
TicketrwsThu, 26 Oct 2017 14:40:38 GMT
https://trac.sagemath.org/ticket/22322#comment:26
https://trac.sagemath.org/ticket/22322#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:18" title="Comment 18">mforets</a>:
</p>
<blockquote class="citation">
<p>
i find that the interface <code>(equation, variable, domain)</code> is very clear. isn't it preferable than relying on global assumptions? (or to fallback into the global assumptions if the domain is not provided.)
</p>
</blockquote>
<p>
It is. Propagating the <code>solveset</code> interface to our solve would mean at least supporting the option <code>domain='real'</code> with complex the default.
</p>
TicketrwsThu, 26 Oct 2017 15:13:12 GMTdependencies changed
https://trac.sagemath.org/ticket/22322#comment:27
https://trac.sagemath.org/ticket/22322#comment:27
<ul>
<li><strong>dependencies</strong>
changed from <em>#23990, #24104</em> to <em>#23990, #24104, #24062</em>
</li>
</ul>
TicketrwsFri, 27 Oct 2017 13:52:33 GMT
https://trac.sagemath.org/ticket/22322#comment:28
https://trac.sagemath.org/ticket/22322#comment:28
<p>
SymPy seems to make a clear distinction between the operators in <code>x>0</code> and <code>Gt(x,0)</code>. I think it's wrong that <code>(x>0)._sympy_()</code> returns <code>x>0</code>.
</p>
TicketrwsFri, 27 Oct 2017 13:55:52 GMT
https://trac.sagemath.org/ticket/22322#comment:29
https://trac.sagemath.org/ticket/22322#comment:29
<p>
Ah no, I'm wrong. We do the right translation.
</p>
TicketrwsFri, 27 Oct 2017 14:45:40 GMTbranch set
https://trac.sagemath.org/ticket/22322#comment:30
https://trac.sagemath.org/ticket/22322#comment:30
<ul>
<li><strong>branch</strong>
set to <em>u/rws/22322</em>
</li>
</ul>
TicketrwsFri, 27 Oct 2017 14:50:57 GMTcommit, author set
https://trac.sagemath.org/ticket/22322#comment:31
https://trac.sagemath.org/ticket/22322#comment:31
<ul>
<li><strong>commit</strong>
set to <em>3073840e81e526524eea0ce89cb28bc83723c7d5</em>
</li>
<li><strong>author</strong>
set to <em>Ralf Stephan</em>
</li>
</ul>
<p>
This branch works quite well and can be used and reviewed. It lacks doctests and documentation, which I'll add next. But please experiment with it. We use <code>solveset</code> with single-expression univariate tasks, <code>solve</code> for the rest. The output is unified to Sage's list "format".
</p>
<hr />
<p>
Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=7899ea992d19f75e38e7db5526bb5c311d09d79a"><span class="icon"></span>7899ea9</a></td><td><code>20204: convert SymPy abstract functions</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=b261ec3e671179d04d1922d15d9116e4f6e1d47f"><span class="icon"></span>b261ec3</a></td><td><code>23923: fix doctest</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=5010acf00b2811420ba1a725deb2351f77eb0c01"><span class="icon"></span>5010acf</a></td><td><code>Merge branch 'u/rws/23923' of git://trac.sagemath.org/sage into t/20204/20204</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=14b1c523c468bfb304191edfe6e85a5c94e916f5"><span class="icon"></span>14b1c52</a></td><td><code>20204: more doctests</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=9c4119a3feda956846bd1fa78256830aef4739f8"><span class="icon"></span>9c4119a</a></td><td><code>16801: Conversion of psi(x,y) to/from SymPy</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=d5c60e3418468f8b5325f06997646fb4f9bf6ced"><span class="icon"></span>d5c60e3</a></td><td><code>24062: pkg version/chksum</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=1cbc23e8c18d4d93a19c225bf79cc85e3f37fd01"><span class="icon"></span>1cbc23e</a></td><td><code>24062: remove obsolote patches; adapt remaining</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=94f359f5a48696e2b98c346e3f120e9481d89a7c"><span class="icon"></span>94f359f</a></td><td><code>24062: doctest fixes</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=cf5c81a21f403d11a68c8c2827e771d3ed433df5"><span class="icon"></span>cf5c81a</a></td><td><code>Merge branch 'u/rws/24062' of git://trac.sagemath.org/sage into t22322</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=3073840e81e526524eea0ce89cb28bc83723c7d5"><span class="icon"></span>3073840</a></td><td><code>22322: sympy algorithm in solve</code>
</td></tr></table>
TicketrwsFri, 27 Oct 2017 14:52:10 GMT
https://trac.sagemath.org/ticket/22322#comment:32
https://trac.sagemath.org/ticket/22322#comment:32
<p>
And <code>domain='real'</code> is recognized too.
</p>
TicketrwsFri, 27 Oct 2017 15:36:34 GMT
https://trac.sagemath.org/ticket/22322#comment:33
https://trac.sagemath.org/ticket/22322#comment:33
<p>
Ah, multivariate doesn't work at the moment.
</p>
TicketgitSat, 28 Oct 2017 06:07:03 GMTcommit changed
https://trac.sagemath.org/ticket/22322#comment:34
https://trac.sagemath.org/ticket/22322#comment:34
<ul>
<li><strong>commit</strong>
changed from <em>3073840e81e526524eea0ce89cb28bc83723c7d5</em> to <em>eac5f8bf8a12da0373bed819bcd060673a2f7aa4</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=eac5f8bf8a12da0373bed819bcd060673a2f7aa4"><span class="icon"></span>eac5f8b</a></td><td><code>22322: fixes</code>
</td></tr></table>
TicketcharpentSat, 28 Oct 2017 22:11:33 GMT
https://trac.sagemath.org/ticket/22322#comment:35
https://trac.sagemath.org/ticket/22322#comment:35
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:23" title="Comment 23">rws</a>:
</p>
<p>
[Snip ... ]
</p>
<blockquote class="citation">
<p>
It motivates me to create a context infrastructure where you can say:
</p>
<pre class="wiki">sage: mycontext = context(x>0, hold)
sage: with mycontext:
sage: solve(...)
</pre><p>
or
</p>
<pre class="wiki">sage: mycontext.start()
sage: ...
sage: solve(...)
sage: mycontext.stop()
</pre></blockquote>
<p>
Maybe <a class="closed ticket" href="https://trac.sagemath.org/ticket/24119" title="enhancement: Create an assuming() context manager (closed: fixed)">#24119</a> might be relevant ? It doesn't medles with evaluation (or not) of the body of the <code>with</code>, it just brackets this body with temporary updates to the facts database. Not the problem you are trying to solve, but might be handy...
</p>
<p>
[ Re-snip ... ]
</p>
<blockquote class="citation">
<p>
I remember reading in devel that previous developers hoped so too, also because at that time development on Pynac stopped and practically no one worked on symbolics in Sage. While that's no longer the case, solvers and integration need much help from SymPy, Fricas, and Giac.
</p>
</blockquote>
<p>
In my (limited) experience, the ability od Sage to call "at will" SymPy, fricas, giac (and even maple and mathematica, but shhh...) is *extremely* useful for practical work. Add <code>Sage\TeX</code> to the mixture (the notebook is nice for prottyping, but I'm sold on "literate programming" for any serious publication work...), and you get a tool whose usefulness surpasses those of any of its components.
</p>
<p>
IMHO, Sage needs a lot of development in the "engineering/scientific/undergrad maths" department, which is not, to say the least, the core interest of its core developers. I see the work in this direction as an <em>investment</em> : if we make a tool useful to those non-professional-mathematician users,I would be quite surprised that none of them would dive in Sage development in these departments, thus relieving the algebraists, geometers and number theorist who <em>are</em> the core developers of Sage of the infrastructure and maintenance work.
</p>
TicketcharpentSat, 28 Oct 2017 22:15:47 GMT
https://trac.sagemath.org/ticket/22322#comment:36
https://trac.sagemath.org/ticket/22322#comment:36
<p>
Stefan,
</p>
<p>
I'm a bit lost about your various tickets. I suggest that you make a meta-ticket (say, "Work in progress on SymPy") in which you merge the various pieces you want tested (with their dependencies) : that would ease the retrieval. Reverting no-longer-useful parts should be also possible.
</p>
TicketrwsSun, 29 Oct 2017 14:50:48 GMT
https://trac.sagemath.org/ticket/22322#comment:37
https://trac.sagemath.org/ticket/22322#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:36" title="Comment 36">charpent</a>:
</p>
<blockquote class="citation">
<p>
Stefan,
</p>
<p>
I'm a bit lost about your various tickets. I suggest that you make a meta-ticket (say, "Work in progress on SymPy") in which you merge the various pieces you want tested (with their dependencies) : that would ease the retrieval.
</p>
</blockquote>
<p>
Why? Just check out the branch. It contains everything.
</p>
<blockquote class="citation">
<p>
Reverting no-longer-useful parts should be also possible.
</p>
</blockquote>
<p>
Can you explain what you are trying to do? We don't need to use the ticket for this, that's also what zulip.sagemath.org is for, just message me please.
</p>
TicketcharpentMon, 30 Oct 2017 21:19:14 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:38
https://trac.sagemath.org/ticket/22322#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>positive_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/22322#comment:37" title="Comment 37">rws</a>:
[ Snip ... ]
</p>
<blockquote class="citation">
<p>
Why? Just check out the branch. It contains everything.
</p>
</blockquote>
<p>
Aha ! I didn't understand that you had merged the necessary tickets.
</p>
<p>
Anyway : on top of 8.1.beta9 + <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/23980" title="enhancement: Add use tips to r interface documentation (needs_work)">#23980</a>+2<a class="closed ticket" href="https://trac.sagemath.org/ticket/4026" title="defect: [with spkg, positive review] Move Macaulay2 to latest upstream (closed: fixed)">#4026</a>+<a class="closed ticket" href="https://trac.sagemath.org/ticket/24119" title="enhancement: Create an assuming() context manager (closed: fixed)">#24119</a>, passes ptestlong with no errors whatsoever.
</p>
<p>
It needs doc, however. And some options do not seem to work on multivariate systems :
</p>
<pre class="wiki">sage: solve(x^3+1==0,x,domain="real") ## domain="real" does not work in Maxima's solver...
[x == 1/2*I*sqrt(3)*(-1)^(1/3) - 1/2*(-1)^(1/3), x == -1/2*I*sqrt(3)*(-1)^(1/3) - 1/2*(-1)^(1/3), x == (-1)^(1/3)]
sage: solve(x^3+1==0,x,algorithm="sympy",domain="real") # ...but works with Sympys's solver ...
[x == -1]
sage: solve([x^2+y^2 == 1, y^2 == x^3 + x + 1], [x, y],algorithm="sympy",domain=
....: "real") ### ... but not for systems.
[{y: -1, x: 0},
{y: 1, x: 0},
{y: -sqrt(-1/2*I*sqrt(3) + 3/2), x: -1/2*I*sqrt(3) - 1/2},
{y: sqrt(-1/2*I*sqrt(3) + 3/2), x: -1/2*I*sqrt(3) - 1/2},
{y: -sqrt(1/2*I*sqrt(3) + 3/2), x: 1/2*I*sqrt(3) - 1/2},
{y: sqrt(1/2*I*sqrt(3) + 3/2), x: 1/2*I*sqrt(3) - 1/2}]
</pre><p>
Notwithstandig that, <code>positive_review</code>.
</p>
TicketcharpentMon, 30 Oct 2017 21:24:51 GMT
https://trac.sagemath.org/ticket/22322#comment:39
https://trac.sagemath.org/ticket/22322#comment:39
<p>
Just a thought : I see that the patchbots fail to build the package, for lack of source tarball. It could be useful to add a pointer to it in the ticket description (ISTR that thos worked for <a class="closed ticket" href="https://trac.sagemath.org/ticket/24026" title="enhancement: Upgrade R to 3.4.2 (closed: fixed)">#24026</a>...).
</p>
TicketrwsTue, 31 Oct 2017 04:21:02 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:40
https://trac.sagemath.org/ticket/22322#comment:40
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Thanks. I have to do more Work, at least the merge of <a class="closed ticket" href="https://trac.sagemath.org/ticket/24104" title="enhancement: Merge the code of ex.solve(...) and solve(...) (closed: fixed)">#24104</a> changes and necessary documentation. The tarball will be no longer necessary with the next release because the SymPy upgrade is in there.
</p>
TicketrwsTue, 31 Oct 2017 16:00:22 GMT
https://trac.sagemath.org/ticket/22322#comment:41
https://trac.sagemath.org/ticket/22322#comment:41
<p>
We'll need to work on <a class="closed ticket" href="https://trac.sagemath.org/ticket/22024" title="defect: symbolic placeholder for complex root (closed: fixed)">#22024</a> next because <code>solve(x^5 + 3*x^3 + 7, x, algorithm='sympy')</code> will fail. But not for this ticket.
</p>
TicketrwsTue, 31 Oct 2017 17:27:02 GMTbranch changed
https://trac.sagemath.org/ticket/22322#comment:42
https://trac.sagemath.org/ticket/22322#comment:42
<ul>
<li><strong>branch</strong>
changed from <em>u/rws/22322</em> to <em>u/rws/22322-1</em>
</li>
</ul>
TicketrwsTue, 31 Oct 2017 17:31:02 GMTstatus, commit changed
https://trac.sagemath.org/ticket/22322#comment:43
https://trac.sagemath.org/ticket/22322#comment:43
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>eac5f8bf8a12da0373bed819bcd060673a2f7aa4</em> to <em>963cc0e6cb2ea5441422f73beb961b882dfec420</em>
</li>
</ul>
<p>
This is a new branch because of differences in the dependencies. I also added the missing translation of <code>LambertW</code>. Another problem is that SymPy's <code>solveset</code> is not always better than its <code>solve</code> esp. with nonlinear equations, compare e.g. <code>x+2**x==0</code>. This needs more work later.
</p>
<p>
Please review, these should be the last big changes.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=269c2de8d1e5396da594b8f1679ff71603f40765"><span class="icon"></span>269c2de</a></td><td><code>Merge branch 'develop' into 22322-1</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=86e9c201a75408816f76bde25208d46f9d73e692"><span class="icon"></span>86e9c20</a></td><td><code>24104: move doctests</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=91cb91f846ebfbea538fbaacad7780c1867d19f9"><span class="icon"></span>91cb91f</a></td><td><code>24104: solve no longer calls itself</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=0f6e8265f9ebc448d4aa4004ef0c6b504560b6ff"><span class="icon"></span>0f6e826</a></td><td><code>Move the single expression solver into stand-alone function for granularity plus some mild cleanup.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=4048e2553f264d37fc65de4e1b6dad6f4e24b1e7"><span class="icon"></span>4048e25</a></td><td><code>Merge branch 'public/symbolcs/merge_solves-24104' of git://trac.sagemath.org/sage into 22322-1</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=963cc0e6cb2ea5441422f73beb961b882dfec420"><span class="icon"></span>963cc0e</a></td><td><code>22322: allow sympy algorithm in solve</code>
</td></tr></table>
TicketcharpentWed, 01 Nov 2017 05:37:07 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:44
https://trac.sagemath.org/ticket/22322#comment:44
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
On top of 8.1.beta9 + <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/23980" title="enhancement: Add use tips to r interface documentation (needs_work)">#23980</a>+2<a class="closed ticket" href="https://trac.sagemath.org/ticket/4026" title="defect: [with spkg, positive review] Move Macaulay2 to latest upstream (closed: fixed)">#4026</a>+<a class="closed ticket" href="https://trac.sagemath.org/ticket/24119" title="enhancement: Create an assuming() context manager (closed: fixed)">#24119</a>, passes ptestlong with no errors whatsoever.
</p>
TickettscrimWed, 01 Nov 2017 06:07:21 GMT
https://trac.sagemath.org/ticket/22322#comment:45
https://trac.sagemath.org/ticket/22322#comment:45
<p>
Reviewer name.
</p>
TicketvbraunThu, 02 Nov 2017 14:50:11 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:46
https://trac.sagemath.org/ticket/22322#comment:46
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
TicketrwsThu, 02 Nov 2017 14:54:38 GMTreviewer set
https://trac.sagemath.org/ticket/22322#comment:47
https://trac.sagemath.org/ticket/22322#comment:47
<ul>
<li><strong>reviewer</strong>
set to <em>Emmanuel Charpentier</em>
</li>
</ul>
<p>
@charpent I hope you don't mind me adding your name.
</p>
TicketrwsThu, 02 Nov 2017 14:54:53 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:48
https://trac.sagemath.org/ticket/22322#comment:48
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
TicketvbraunSun, 10 Dec 2017 09:26:22 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:49
https://trac.sagemath.org/ticket/22322#comment:49
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
On OSX:
</p>
<pre class="wiki">**********************************************************************
File "src/sage/symbolic/relation.py", line 894, in sage.symbolic.relation.solve
Failed example:
solve([x^2 - y^2/exp(x), y-1], x, y, algorithm='sympy')
Expected:
[{y: 1, x: 2*lambert_w(1/2)}]
Got:
[{x: 2*lambert_w(1/2), y: 1}]
**********************************************************************
File "src/sage/symbolic/relation.py", line 902, in sage.symbolic.relation.solve
Failed example:
solve([x + y + z + t, -z - t], x, y, z, t, algorithm='sympy')
Expected:
[{z: -t, x: -y}]
Got:
[{x: -y, z: -t}]
**********************************************************************
File "src/sage/symbolic/relation.py", line 904, in sage.symbolic.relation.solve
Failed example:
solve([x^2+y+z, y+x^2+z, x+y+z^2], x, y,z, algorithm='sympy')
Expected:
[{y: -(z + 1)*z, x: z}, {y: -z^2 + z - 1, x: -z + 1}]
Got:
[{x: z, y: -(z + 1)*z}, {x: -z + 1, y: -z^2 + z - 1}]
**********************************************************************
1 item had failures:
3 of 112 in sage.symbolic.relation.solve
[377 tests, 3 failures, 185.81 s]
----------------------------------------------------------------------
sage -t --long src/sage/symbolic/relation.py # 3 doctests failed
----------------------------------------------------------------------
</pre>
TicketgitSun, 10 Dec 2017 14:05:49 GMTcommit changed
https://trac.sagemath.org/ticket/22322#comment:50
https://trac.sagemath.org/ticket/22322#comment:50
<ul>
<li><strong>commit</strong>
changed from <em>963cc0e6cb2ea5441422f73beb961b882dfec420</em> to <em>8e1e240bb9b8d735251847e67deec1fdb32eccba</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=8e1e240bb9b8d735251847e67deec1fdb32eccba"><span class="icon"></span>8e1e240</a></td><td><code>22322: dict order-independent doctests</code>
</td></tr></table>
TicketrwsSun, 10 Dec 2017 14:06:36 GMTstatus changed
https://trac.sagemath.org/ticket/22322#comment:51
https://trac.sagemath.org/ticket/22322#comment:51
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
TicketvbraunWed, 13 Dec 2017 17:38:46 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/22322#comment:52
https://trac.sagemath.org/ticket/22322#comment:52
<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/22322-1</em> to <em>8e1e240bb9b8d735251847e67deec1fdb32eccba</em>
</li>
</ul>
Ticket