N + Subs + Zeta + Derivative = maximum recursion depth exceeded #11802
Comments
|
For some reason that I haven't tracked down, this can actually crash Python on Fedora 30, Intel hardware, SymPy 1.4 That is, not just recursion in Python but a proper stack overflow... Ouch. The first derivative still causes a "maximum recusion depth exceeded" exception as noted above. |
|
maybe now pthon3.7 have less limit than the previos versions, maybe test |
|
A here is an object that doits to itself: In [1]: A = zeta(x).diff(x,2).subs(x, 2)
In [2]: A
Out[2]:
⎛ 2 ⎞│
⎜ d ⎟│
⎜───(ζ(x))⎟│
⎜ 2 ⎟│
⎝dx ⎠│x=2
In [3]: A.doit()
Out[3]:
⎛ 2 ⎞│
⎜ d ⎟│
⎜───(ζ(x))⎟│
⎜ 2 ⎟│
⎝dx ⎠│x=2So this will give infinite recursion: Lines 2135 to 2136 in c162866 |
|
mm, that sounds more like a sympy bug. |
|
I would like to take up this issue. Please guide me as to what needs to be done. |
|
Ouuu, this problem seems to be..., this really need a test for sympy. Checking deeper, this seems to not belong to Zeta function, other example My big question to know why this happen, Why It almost seems that Zeta, have a different Maybe track in both cases how works evalf, and check in what section do differents things. Hope this can help, and if other one can say other idea how work on this would be great, i don't know very well how works sympy. Thx. |
|
The idea is that a Perhaps the fallback for evalf here could be to numerically evaluate the derivative: In [81]: h = S(10)**-10
In [82]: h
Out[82]: 1/10000000000
In [83]: differentiate_finite(zeta(x).diff(x), x, points=[2-h, 2, 2+h])
Out[83]:
2
100000000000000000000⋅π ⎛20000000001⎞ ⎛19999999999⎞
- ──────────────────────── + 100000000000000000000⋅ζ⎜───────────⎟ + 100000000000000000000⋅ζ⎜───────────⎟
3 ⎝10000000000⎠ ⎝10000000000⎠
In [84]: _.evalf()
Out[84]: 1.98928023429890 |
|
Yes, that wold works. I have a question. |
I'm not sure exactly what you mean by "evaluated" there. SymPy does not have defined symbolic functions that can represent the derivatives of the zeta function. Those could be added and if they were then they could use explicit algorithms for numerical approximate evaluation: Otherwise if you mean the fact that I think that a reasonable solution here is to add something to |
|
Is there a way to know this, before?, i mean, intead check if |
|
There isn't a reasonable way to know if doit will return a |
|
In that case, when the expression is constructed, run Is to just avoid call |
|
Calling |
|
In that case, when we run |
|
That is probably worth doing but it should be handled as part of a broader overhaul of evaluation (#17280) |
|
Okis, i think can works check if Now, it feels is similar to #17280, that would be better to store in a var to know this and don't check it every time. In my case i don't know very well how check that in Sympy. I don't know if that can be considerated part of this issue. Maybe a simpler solution for now, is make a function that request this data, like |
|
Hi, @oscarbenjamin if your are right with what we have until now, i think @sachin-4099 can work on this. |
|
I am ready to start the work, but I want to know what all exactly needs to be changed. @oscarbenjamin @latot |
|
Hi, writing for now, @oscarbenjamin can confirm this please. First make a new function to recognize if a function have a sympy representation, store this in a var to don't run all the check every time for the same object, if you can find a nice way to this would be great, if not you can check if the return of Thx. |
|
We don't need to store anything. The |
|
Hi, i think that can cause some problems, #11802 (comment), if you can comment that i would appreciate it. |
|
I don't understand what problems you are referring to |
|
mm, the problem is not, the Subs is returning a derivative and that causing the recursion. The problem is that the code doesn't detect if the expression have a symbolic representation, the derivative in To can handle this point i think we need check that, but how the check can be expensive, i think would be better sotore the value, similar to what we talk of And with that check (symbolic representation), define if use numeric aproximation or not. Hope i could explain better this. |
|
Calling |
|
:O okis. To follow both things, i'm still worried there to be other cases than derivative. Ex: I think we need a good way to detect this. Edited: For now, i think checking if there is a derivative, in any part of the result can works, but i really really would like a method that can says if there is a representative function or not in sympy, not start testing in this way, is too expensive while we would be able to know this type in a easly way. |
|
We can just check if doit returned the same result. If it did we don't want to call Then if |
|
Here, i think a complete example would be better: |
|
Here itself @oscarbenjamin?? Lines 2135 to 2136 in c162866 |
|
Yes |
|
@sachin-4099 Please start a PR if you had understand what needs to be done and CC @oscarbenjamin and me to it for further review |
|
mpmath has numerical differentiation routines http://mpmath.org/doc/current/calculus/differentiation.html?highlight=diff#mpmath.diff |
@oscarbenjamin can you please be specific as to what to code in the numerical differentiation part. |
|
Hi, the idea is replace that |
Are you talking about this? |
|
Yes, something like that, but be careful, you need use diff from mpmath for the aproximations, and need to work with mixed derivatives (not just one variable). |
|
My current code looks like: where self.args[0].args[0]-->zeta(x) But |
|
Moreover this 1 testcase in test_function.py is giving an exception/error: RecursionError: maximum recursion depth exceeded while calling a Python object |
|
For the first case, than can happend for the precision, it can be changed, in the docs explains, with To can do that test in a easy way, you can assign every value tu one variable, and next run the assert, so, if fails with the recursion you can know the line with the error (is failing in I know this isn't the most pretty test case :D but i think helps while debugging. Hope this can help. |
No success, it still returns 0. I have already tried these. |
|
mm, can you test with other eq that the result is not 0? (and not close to it) |
|
suggest some equations which will make use of the function we are trying to improve. |
|
Hi, here you can try several examples like this: https://www.wolframalpha.com/input/?i=diff%28zeta%28zeta%28x%29%29%29%2C+x%3D4 |
|
I see that We should adapt that so that it works for higher-order derivatives and then use it in |
Should we change |
|
Yes |
|
Ok so what are the required changes then? |
|
There are a few things that need to be done here:
I expect the second point will be the easiest. |
|
Another thing is we should make sure |
|
Derivative support should be added for numpy as well using https://docs.scipy.org/doc/scipy/reference/generated/scipy.misc.derivative.html |
The recursion error is explained above: #11802 (comment) |
|
For lambdify, I think Derivative support has to be done in the printer. We can't do it via a replacement, because the function inside the derivative will be replaced with a numeric function which will evaluate to a numeric value. This also makes this very difficult to work around. You can only pass a custom Derivative to the modules if you know ahead of time what the Derivative will be, e.g., |
See sympygh-11802 and sympygh-26663 for background and motivation.
See sympygh-11802 and sympygh-26663 for background and motivation.
See sympygh-11802 and sympygh-26663 for background and motivation.
Hi, here the problem:
Thx. Cya.
The text was updated successfully, but these errors were encountered: