-
-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sympy: Problem with integration/differentiation of symbolic functions. #28964
Comments
comment:1
Weird. Round-tripping to maxima seems to do the right thing, so that's not where the problem seems to lie:
If you make the variable combinations a little more complicated:
These are Pynac errors. So I suspect that there is a differentiation that doesn't have its variable specified, and that with only two variables around (one for the integration!) it ends up choosing that variable. So my guess is either Pynac itself or the way we interface with it. The same problem seems to arise the other way around as well:
we can make that cause an error by fiddling with some more variables and then we see that the error traces back in something being called from |
comment:2
Replying to @nbruin: [ Snip... ]
According to a comment posted around Jan 7, 2020 07:00 by dsejas in the original ask.sagemath question, the problem might have been introduced between 8.8 and 8.9. It should be possible to |
comment:3
Replying to @EmmanuelCharpentier:
The culprit might be #27958. |
Changed keywords from none to integrate, integral |
comment:5
I am the original poster in ask.sagemath.org for this issue. Hope I am not out of line to add a test case because I hope the eventual fix will solve my original problem:
Used to work in Sage 8.8. Not working in 8.9 or 9.0. Thanks a lot. |
comment:6
Translation of derivatives to sympy is definitely wonky:
There are typos in
I'm pretty sure the second-last line should be iterating over |
comment:7
Replying to @nbruin:
The following fixes this particular problem: --- a/src/sage/symbolic/expression_conversions.py
+++ b/src/sage/symbolic/expression_conversions.py
@@ -860,7 +860,7 @@ class SympyConverter(Converter):
# retrieve order
order = operator._parameter_set
# arguments
- _args = ex.arguments()
+ _args = ex.operands()
sympy_arg = []
for i, a in enumerate(_args):
|
This comment has been minimized.
This comment has been minimized.
comment:9
The patches in comment:6 and comment:7 almost fix the problem, but there were a few more issues in the conversion of derivatives between sympy and Sage. These are now fixed by this branch. Most notably, sympy's arguments are encoded as Moreover, the conversion from Sage to sympy was very broken and has been rewritten completely, especially to account for the case of variables with multiple occurences as in comment:1. As far as I can see, all the test cases mentioned on this ticket work correctly now. New commits:
|
Commit: |
Author: Markus Wageringel |
Branch: u/gh-mwageringel/28964 |
Changed keywords from integrate, integral to integrate, integral, sympy |
comment:10
Handling the Rational this way leads to problem
If this is really needed (I don't quite understand why yet), then you should check that there is no denominator. |
Reviewer: Vincent Delecroix |
Branch pushed to git repo; I updated commit sha1. New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:13
You are right. That was not a good solution. It turns out the problem is that elements of type
I have just fixed this by implementing the missing conversion routine for integers. Thanks for pointing me in the right direction. I will squash the commits if you prefer. |
comment:14
Good enough as it is. |
Changed branch from u/gh-mwageringel/28964 to |
This ticket fixes several problems related to the conversion of derivatives to and from sympy:
sympy.core.containers.Tuple
which was not handled(Original description below.)
Minimal case of a problem reported on ask.sagemath.org.
As expected. But :
No, no, no. And no.
Slightly better:
No again. But at least, this is an explicit error, not a silently accepted wrong result.
The problem seems to point to handling formal arguments of undefined functions. I do not (yet) understand this code...
IMHO, at least the first case is critical (possibly blocker), because it silently returns a wrong result.
Note that the handling of defined functions seems to be correct. For example:
Component: symbolics
Keywords: integrate, integral, sympy
Author: Markus Wageringel
Branch/Commit:
57a8e83
Reviewer: Vincent Delecroix
Issue created by migration from https://trac.sagemath.org/ticket/28964
The text was updated successfully, but these errors were encountered: