Substitution example linked from the SymPy site fails. #172
Comments
|
Thanks for reporting this. Where is this example described? I though that sympy gamma was supposed to take "natural language" inputs rather than something that looks more like Python code. |
|
BTW it would be great to learn more from a more experienced project like Macsyma. If you have any tips to pass on then please do! I still haven't used Macsyma but was recently reading this: |
|
I'm guessing this broke when we recently updated the version of SymPy that Gamma uses. I guess this example isn't tested, so we didn't notice that it broke. |
|
There is a bug in the parse_expr transformations used by SymPy Gamma sympy/sympy#21020. Note that the example will work just fine, e.g., in SymPy Live (after fixing it to be valid Python): https://live.sympy.org/?evaluate=u%20%3D%20symbols(%27u%27)%0A%23--%0A(exp(x)%20%2F%20(1%20%2B%20exp(2*x))).subs(exp(x)%2C%20u)%0A%23--%0A. The issue is specifically with SymPy Gamma, which tries to parse non-Python syntax like implicit multiplication, but is failing here. |
|
It would also help to have an option in Gamma to disable to "smart" parsers and only parse the expression as Python. That would not only be useful for cases like this where the parser fails, but in some cases the parser might guess wrong (it is impossible to be completely unambiguous with implicit multiplication vs. function application). That's actually a feature I wish Wolfram Alpha had as well. Every time I try to use it, it tries to parse my input in some weird way, even if I try to make it exact Mathematica syntax, and there's no apparent way to disable this. |
|
The substitution example is linked here: Yeah, it did seem a confusion between multiplication and method access. I might suggest using a \ to force it to be one or the other—for Gamma, probably force it to be python? e.g: (exp(x) / (1 + exp(2x)))\.subs(exp(x), u)I don't know that I would have any useful insights from >30 years ago. I do have Maxima on my system, and I happen to be about to try to integrate Maxima with a Jupyter docker image I'm constructing. I mostly worked on the lower levels that supported the math, maintained Maclisp, was one of the NIL Lisp team, before joining Symbolics in '81. I looked for any of my code in the Maxima code base, and couldn't find any remnants, even my polynomial decomp solver. My ~1975 TEACH;LISP code does still exist, however. If you want to be seriously amused—here's me trying to get it to run in a browser by implementing Maclisp in Javascript. Seriously foiled by code rot on the TEACH;LISP side, though. |
|
I wonder when that GCDHEU algorithm was put into Maple? The Liao/Fateman paper is from 1995, and the Geddes citation is 1992, both long after I left MIT (and Fateman left MIT to Berkeley about 5 years earlier). RJF cites his first GCD experience in Macsyma in 1970, before I even got to MIT. But Maple was just getting started as I was leaving MIT. So I'm guessing around 1985? That's around the end of the usage of Macsyma on the PDP-10. A hard constraint up to then (and the motivation behind the NIL project as well as Maple) was address space. And many times in adding a new feature to Maclisp, we had to scrounge around for ways to save a word or two from the Maclisp interpreter code pages to avoid crossing a page boundary, which would mean losing a page of heap, which would cause some important Macsyma usage to fail. Today, adding more code is seldom an issue, and it seems to me for GCD, instead of choosing an algorithm, you could pick the top contenders and run them in parallel to see which finishes first. CPU cores are finite (even GPU cores), but GCD tends to be a bottleneck. Of course, in CPython, you have that pesky Global Interpreter Lock, so you'd have to do it outside of Python unless you can preallocate everything. (Art*Enterprise didn't even have locking, so I referred to that interpreter as "aggressively single-threaded". Python fares a bit better...) |
Note that SymPy Gamma is different from SymPy Live. In SymPy Live you can run Python code using SymPy so any code examples from the documentation are supposed to work. SymPy Gamma is supposed to be something like Wolfram Alpha where you enter natural language-like inputs (rather than Python code) and it will try to guess what you mean and show you some interesting stuff. I wouldn't expect regular sympy code to work in SymPy Gamma although it should give a better error message. |
There's still the work involved in actually writing that code :) I don't know much about gcd algorithms but they are a bottleneck in sympy which doesn't even have a sparse implementation of the PRS algorithm: sympy/sympy#20874 |
|
It seems like a good challenge for a young grad student looking for a topic for a paper. Implement a few published algorithms, set up the parallelism, collect stats on which algorithm win, and how much it wins over picking any one algorithm If SymPy Gamma isn't supposed to work on that input, then SymPy's site shouldn't link it in quite that way. Maybe a different example where the distinction doesn't lead to an error? |
|
Where is it linked from? |
|
Sorry, I thought I'd responded, but it seems I didn't quite get to it! It's here:
Sorry for the long delay! |
|
Thanks. Looks like it's a parsing bug in sympy gamma as mentioned above. |
This example (from Features/Core Capabilities/Substitution) fails:
https://www.sympygamma.com/input/?i=%28exp%28x%29+%2F+%281+%2B+exp%282x%29%29%29.subs%28exp%28x%29%2C+u%29
Reducing it to:
Gives the same error.
(Aging Macsyma project member here—it makes me happy to discover this project! This happened to the first thing I tried...but the second was the diophantine equation example, which redeemed itself. It's good to see people continuing to work with computer algebra systems and putting them to new uses! I came across your project via the Quantitative Economics project -> Jupyter-Book project -> here).
The text was updated successfully, but these errors were encountered: