Closed AayushSabharwal closed 7 months ago
Did not mean to start a new review, I'm not sure how that happened
Needs a rebase?
Yep, almost done
Rebased
Should SciMLBase also export getp
and setp
?
Attention: 258 lines
in your changes are missing coverage. Please review.
Comparison is base (
9fdb9c8
) 25.91% compared to head (bbba9c6
) 0.00%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In my code I make heavy use of odefunction.syms
to get the symbols for plotting purposes, find the right indices in the u
vector, and so on. Is there a recommended way to get the symbols now?
I found odefunction.sys.variables
but this again uses some internals that might change in the future...
The recommended way is to import SymbolicIndexingInterface
and use variable_symbols(odefunction)
Indeed. The main purpose of this transition is to establish a well-defined interface that this is all based off of, rather than having to know internals voodoo for what's setup related to symbolic indexing. This is https://github.com/SciML/SymbolicIndexingInterface.jl, with our downstream packages implemented the documented interface https://docs.sciml.ai/SymbolicIndexingInterface/stable/api/ (and tutorials coming soon). If you stick to the documented interface and version control with respect to that, you will get guarantees of correctness in the setup which relying on internals could never give you. Hopefully this makes everything easier to maintain in the future, not just for us but for anyone like you who downstream is trying to use/extend the symbolic indexing in any way.
Thanks a lot for the details, I'll look into that package! Pleas don't get me wrong, I did not mean to complain about the "breakage" at all -- that's what you get for using internals. I really like the transition to more and more tested and guaranteed interfaces. Luckily we have funding for a major rewrite next your so we can base our package on modern SciML standards removing many of those 3 year old hacks...
Yes no worries. Interfaces are great, but you definitely have to rip off a few bandaids to put one in place where there wasn't one before. I mean, .syms
served us well from 2016-2022, so it did its job 😅. I couldn't have predicted we needed an interface back when it was put in. But now we are in a different place and really formalizing what's going on is the only way for people to make use of all of its functionality correctly and in a way that allows maximum performance.
Indeed. The main purpose of this transition is to establish a well-defined interface that this is all based off of, rather than having to know internals voodoo for what's setup related to symbolic indexing. This is https://github.com/SciML/SymbolicIndexingInterface.jl, with our downstream packages implemented the documented interface https://docs.sciml.ai/SymbolicIndexingInterface/stable/api/ (and tutorials coming soon). If you stick to the documented interface and version control with respect to that, you will get guarantees of correctness in the setup which relying on internals could never give you. Hopefully this makes everything easier to maintain in the future, not just for us but for anyone like you who downstream is trying to use/extend the symbolic indexing in any way.
Great, thanks for the work @AayushSabharwal and @ChrisRackauckas and everyone else working on this. I was just about to interface ODESystem in DynamicalSystems.jl and allow using symbols for e.g., set_parameter
or continuation
. Now I'll start learning and doing it the proper way!
Overall, this looks great! I think there might be a little more cleanup possible by getting rid of
syms
/paramsyms
and always usingsys
, but this already is a substantial clean up.