-
Notifications
You must be signed in to change notification settings - Fork 171
Implementing query method for exp class #2386
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
Conversation
So basically after extracting the base we need to compare it against the constant |
I was able to frame a patch for this and get an output
But the code looks quite odd in comparison to other class query methods (because unfortunately symengine doesn't support an So essentially just one statement in the frontend
Which involves replacing a single statement in the frontend with around 6 statements through the pass
I'll paste the working patch below but just as I pointed out I am a bit doubtful if this is the best approach here. Because check the following case out . Through symengine we would get
Whereas if through sympy we would get
Hence we would have to tackle such cases too if we continue without introducing the |
But yeah if we are interested in the approach that I've pasted above, this is the way to go
It works perfectly fine but confuses me if we would like to have such a big implementation or should we maybe just introduce the |
The question of introducing the exp class in SymEngine is a design question which has pros/cons, but I suspect we should not do it, it seems it does not speed things up, and Mathematica also doesn't do it, only SymPy. I opened up an issue symengine/symengine#1984 to discuss that more. Given that, and given that matching and querying also fails in Mathematica if you query for Exp, you have to query for Power, I would go with that design. The problem is how to keep compatibility with SymPy. I think we can support
Any other option? It seems the last option is the only way forward. This means there might not be any way we can enforce at compile time this difference. The solution might be that we might need to create a pure Python implementation of the Symbolic API, since SymPy itself differs slightly. This might be a good idea to do, and SymPy could later use it as well. For this pure Python implementation we will 100% guarantee that if it works in LPython, it will work with this pure Python implementation. SymPy will only work 99% or so. We will document that if you want to be compatible with sympy, to use |
As I have worked with SymPy's There would be cases where we would like to use But yeah if we have don't see any other viable option, we can try not following the compilation rule (if works in Lpython, should work in SymPy) for this corner case and support only the |
This can now be closed as we have decided not to go ahead with a query method for |
We start with something like the following in the frontend
And I think we need to transform this into something like the following through the pass