-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Slowness of RSolve for third-order relations and above #1032
Comments
I looked at this a little bit. The slowness seems completely inside The input to sympy is:
(You can shorten the variables by removing the prefix Someone (perhaps you?) needs to investigate why sympy |
Thank you for the reply! Sorry, I was not very familiar with the inner workings of Mathics, but this seems to be a sympy issue then, right? |
Not totally sure if it is a SymPy issue or not. It could be that what you want to do is impossible. If you have access to the Wolfram Language, does it give the expected results there in a reasonable amount of time? If so, it could be a known limitation of SymPy. So I'd investigate whether that's the case. There are other kinds of Let me close with a little about open source. The original idea was that everyone is contributing whatever she/he can to make things better for everyone. When things break, since the code is available, the person discovering a problem has code around to investigate and even fix. |
Wolfram Alpha produces an answer for the third-order equation in fractions of a second. It doesn't for the fourth-order one, but I don't have access to Mathematica or Wolfram Alpha pro so I cannot confirm whether this is just a limitation of the free version or if it's just an inherently hard problem. That said, it's still very possible (although tedious) to calculate the result by hand up to the fourth-order, so I suspect that it shouldn't be too hard for a CAS either.
I appreciate the reminder, though I'm well-aware of how open source works :) |
Ok - if you have a chance to look into in at some point in the future, that would be great! From my standpoint, I am perfectly happy for this particular issue to hang out here as a low-priority item. (To set expectations, in another project I oversee, there was a bug lasting 6 years that seemed to impact a number of people. The fix by a who happened to see come across it went in about 3 months ago; I just finished putting out a new release, although there are still a few things I should do on that.) I think the reason I mentioned or reminded about how open-source works, is that there seemed to be an (inadvertent?) willingness to involve more open-source volunteers without having first done what you can to understand the situation beforehand. |
Description
Mathics hangs when using
RSolve
on a linear fourth-order recurrence relation with simple coefficients, which should be able to be handled in seconds. The CPU usage is high while the command is running, but no output is produced even after 15+ minutes on a decent CPU (Ryzen 5 5600H).I also tried a third-order recurrence instead, and the correct output was produced after a total of 70 seconds, which still seems excessive. Dropping the
+1
to make the relation homogeneous doesn't cut down on the processing time either.The commands used are as follows:
Fourth-order:
RSolve[{a[n] == a[n-1] + a[n-4] + 1, a[0] == 0, a[1] == 1, a[2] == 2, a[3] == 3}, a[n], n]
Third-order:
RSolve[{a[n] == a[n-1] + a[n-3] + 1, a[0] == 0, a[1] == 1, a[2] == 2}, a[n], n]
How to Reproduce
$mathics -e 'RSolve[{a[n] == a[n-1] + a[n-4] + 1, a[0] == 0, a[1] == 1, a[2] == 2, a[3] == 3}, a[n], n]'
$mathics -e 'RSolve[{a[n] == a[n-1] + a[n-3] + 1, a[0] == 0, a[1] == 1, a[2] == 2}, a[n], n]'
Output Given
None after 15 minutes for the fourth-order relation.
Expected behavior
The closed form expression of the sequence in a reasonable time.
Your Environment
Mathics 6.0.4
on CPython 3.11.9 (main, Apr 27 2024, 21:16:11) [GCC 13.2.0]
using SymPy 1.12, mpmath 1.3.0, numpy 1.24.4, cython Not installed
OS: Ubuntu 24.04 running on WSL2
Priority
Very low
The text was updated successfully, but these errors were encountered: