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
Simliar to #692, some substitutions seem to change the type of the expression. This leads to strange effects, for example back and forth substituting is not possible. I'm not quite sure whether this Issue should be in MTK or SymbolicUtils. I'm posting it here since I was not able to reproduce it with anything other than the MTK paramter type.
using ModelingToolkit
using SymbolicUtils: to_symbolic, substitute
@parameters t a(t) b(t)
# back and forth substitution does not work for parameters with dependencies
term =to_symbolic(a) # a(t)
term2 =substitute(term, a=>b) # b(t)
term3 =substitute(term2, b=>a) # b(t), should be a(t)
The only difference seems to be the type after substitution
Yes, this seems like a bug. But more generally, I think we need to be fixing up how we tag contextual information to symbols. I would propose using @MasonProtter's idea from
of how to do type tags in the current type system. Sym{ModelingToolkit.Parameter{Real}} is a non-extendable version of this, and interferes with the current rules handling. If it's always Sym{Real,{ModelingToolkit.Parameter}}, then the contextual information is all in extendable tags and the rules can be written to use the algebraic set of the first part.
Differentiating similarterm and symtype will fix the wrapper issue. I.e. similarterm creates a term with the wrapper type, but symtype unwraps the type for value promotion. For nested wrappers, we can make more sophisticated latter.
Simliar to #692, some substitutions seem to change the type of the expression. This leads to strange effects, for example back and forth substituting is not possible. I'm not quite sure whether this Issue should be in MTK or SymbolicUtils. I'm posting it here since I was not able to reproduce it with anything other than the MTK paramter type.
The only difference seems to be the type after substitution
However, the
isequal
function does not care, the pattern matching in SymbolicUtils seems to use something different here.During exploration I found a weird hack for this problem but thats not usefull as an solution.
The text was updated successfully, but these errors were encountered: