-
Notifications
You must be signed in to change notification settings - Fork 31
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
Integration with Symbolics.jl #456
Comments
is there still interest in this? i would be interested to learn how both libraries work by implementing the integration, with light mentorship. |
I think yes, there is still interest. But the mentorship should be done by @saschatimme (because he coded this part) and I don't know if he has the capacities at the moment. |
I have been observing that HC.jl is slow when dealing with large Having this in mind, it seems like it would be good to have an abstract type I think I could use https://www.juliahomotopycontinuation.org/HomotopyContinuation.jl/stable/systems/#Interface in order to implement |
Yes, some sort of special handling for determinants would be really nice but it is definitely not trivial to integrate it into our symbolics pipeline. Right now every symbolic function is assumed to be taking in one or two arguments (We have our own efficient interpreter to evaluate system). Additionally your evaluation function for determinants needs to properly work with higher order precision, and we actually don't just need the first order derivative but we need to be able to derive a local Taylor series up to order 4. So its complicated 🙃 @azoviktor Did you try to run HC with the Otherwise, my general recommendation is to avoid as much as possible the use of determinants. In particular 10x10 sounds very challenging from a numerical point of view. It is (when possible) much better to replace your equations by a modified system in higher dimension. The basic idea is to replace det(A) = 0 by something like [A * v; vT v - 1] = 1 |
@saschatimme, I see, indeed complicated :-)
yes, this is exactly what I did. I was just wondering what is the best way to deal with this. Also I would like to ask, why do you prefer Symbolics.jl more than symengine? Is it because you would like to get rid of calling C? Do you think Symbolics.jl could be faster and calling C slows things down? |
Using Symbolics.jl would allow some niceties like evaluating arbitrary Julia types with the symbolic engine (with symengine we can only do the symengine supported ones). Also based on Symbolics.jl / ModelingToolkit there is some nice work for rewriting symbolic system to improve evaluation performance etc. |
We should keep track of https://github.com/JuliaSymbolics/Symbolics.jl . Maybe at some point we can even remove the symengine dependency in favour of Symbolics.jl
The text was updated successfully, but these errors were encountered: