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
struct SymReal <: Real
term::Term
end
struct SymComplex <: Number # see JuliaLang/julia/issues/33246
term::Term
end
struct SymMatrix{T <: Union{SymReal, SymComplex}} <: AbstractMatrix{T}
name::Term
end
and we could just forward the functions calls to Term, e.g
Base.sin(x::SymReal) = SymReal(@term(sin(x.term)))
Base.sin(x::SymComplex) = SymComplex(@term(sin(x.term)))
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)
XRef: SciML/ModelingToolkit.jl#175
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,Numberand 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,Expressionetc.maybe we could just use
Rewrite.jlorSimplifyas 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