You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the new FAQ (SciML/Optimization.jl#451) we will be telling people that in many cases they should be using NaNMath.jl for their math functions, but we could in theory do this automatically (with an option to turn it off). That could make the optimization process more robust.
The text was updated successfully, but these errors were encountered:
I am just leaving this comment to cross-reference a similar (or not?) problem in Symbolics.
There are some issues with very specialized methods competing for dispatch, e.g., when it comes to linear algebra with symbolic arrays. Cassette can be used to define a dispatch context, prioritizing the overwrites for symbolic arrays, see JuliaSymbolics/Symbolics.jl#811.
For my personal work, I ended up using a dirty work-around which scans for applicable, specialized method definitions at runtime and defines the overwrites.
The more I am thinking about it, it seems that maybe the context idea was not such a bad idea after all, at least with opt-in or opt-out. One of the drawbacks of the context approach was that it had to be enabled manually. Can it be activated automatically? Moreover: Are there performance drawbacks?
If there is progress or discussion in this thread, the results can perhaps be used in Symbolics, too.
The more I am thinking about it, it seems that maybe the context idea was not such a bad idea after all, at least with opt-in or opt-out. One of the drawbacks of the context approach was that it had to be enabled manually. Can it be activated automatically? Moreover: Are there performance drawbacks?
I agree, I don't think it should be thrown away that quickly. It might be the right way to do it. I would like to have @YingboMa and @shashi take a good look at them. I thought it was closed a little quickly.
With the new FAQ (SciML/Optimization.jl#451) we will be telling people that in many cases they should be using NaNMath.jl for their math functions, but we could in theory do this automatically (with an option to turn it off). That could make the optimization process more robust.
The text was updated successfully, but these errors were encountered: