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
currently symbols are all defined as subtype of Number, which my cause things not work with builtin complex number. After I played a few ideas with my own toy engine: https://github.com/Roger-luo/Sym.jl
I think a proper solution might be to have different types defined as subtype of Real, Number and even AbstractMatrix. This will make symbolic objects go through most of the functions defined in many packages, so a lot things should "just work".
Moreover, the domain can always be inferred by Julia's own type inference in this way. So to be more specific what I'm suggesting is to separate the engine with higher abstraction of the symbols, e.g Variable, Term, Expression etc.
maybe we could just use Rewrite.jl or Simplify as the engine in the future, and provide this wrapper here, it would look like
in this way the Real/Complex domain of result type can be inferred by Julia's own type inference from these primitives (imagine if there is a more complicated user defined function)
Yes, this is a good suggestion. I have some ideas for a next gen interface as I rewrite Symbolics.jl from scratch, but those aren't really ready to make public.
currently symbols are all defined as subtype of
Number
, which my cause things not work with builtin complex number. After I played a few ideas with my own toy engine: https://github.com/Roger-luo/Sym.jlI think a proper solution might be to have different types defined as subtype of
Real
,Number
and evenAbstractMatrix
. This will make symbolic objects go through most of the functions defined in many packages, so a lot things should "just work".Moreover, the domain can always be inferred by Julia's own type inference in this way. So to be more specific what I'm suggesting is to separate the engine with higher abstraction of the symbols, e.g
Variable
,Term
,Expression
etc.maybe we could just use
Rewrite.jl
orSimplify
as the engine in the future, and provide this wrapper here, it would look likeand we could just forward the functions calls to
Term
, e.gin this way the Real/Complex domain of result type can be inferred by Julia's own type inference from these primitives (imagine if there is a more complicated user defined function)
XRef: SciML/ModelingToolkit.jl#175
The text was updated successfully, but these errors were encountered: