search

SciML / SciMLBase.jl

The Base interface of the SciML ecosystem
https://docs.sciml.ai/SciMLBase/stable
MIT License
134 stars 97 forks source link

Depend on Symbolics #94

Open lamorton opened 3 years ago

lamorton commented 3 years ago

In order to replace issymbollike & solve method ambiguities for AD rules, SciMLBase could depend on Symbolics. Cf. this remark. by @sharanry in #85.

Currently, we can't do this b/c Symbolics.jl depends on SciMLBase here.

issymbollike from SciMLBase is extended in Symbolics: here

The original definition of issymbollike is in RecursiveArrayTools here. SciMLBase depends on RecursiveArrayTools here.

Symbolics could define an AbstractSymbol type, RecursiveArrayTools could use this for dispatching instead of branching on issymbollike, but in order to make this work we need to make sure Symbolics doesn't depend on SciMLBase.

Edit: It appears that the only mention of SciMLBase within Symbolics is where issymbollike is extended. I'm gonna do a smoke test & make sure.

shashi commented 3 years ago

The right way to check for a symbolic expression is:

Symbolics.unwrap(x) isa Symbolics.Symbolic

The right way to use dispatch would be:

foo(x) = _foo(unwrap(x))
_foo(x::Symbolic) = ... actually do foo ...
_foo(x) = ... do something else? ...

The thing that is done in RecursiveArrayTools seems to be to avoid dependency on Symbolics there.

ChrisRackauckas commented 3 years ago

The right way to use dispatch would be:

You can't do that on getindex. That gives ambiguities.

shashi commented 3 years ago

You can define

getindex(A::SciMLBase.AbstractNoTimeSolution, sym::FillArray)

and

getindex(A::SciMLBase.AbstractNoTimeSolution, sym::Any)

will get the symbols, you can unwrap there if you want.