Eq is not only some semantical respresentation of equation, but also can be part of Basic. For example, we can have Eq(Eq(a, b), Eq(c, d)), f(Eq(a, b)), or something like this. So after the author's suggestion, I may believe that Eq becomes something both as a rule and a expression, while everything in SymPy remains just as expressions, and it is confusing.
Even though it may be reasonable to put Eq more semantics, however, the suggestions like that are sparsely come up with and shallowly discussed, so it just adds more ambiguity, and I'd like to avoid this direction, for more better programming. The example that the author had come up with, such as force.subs(accel), is too shallow to discuss many important perspectives about how Eq, or subs works, and also many different variants of results solve, or solveset for instance. On Thursday, March 28, 2024 at 12:36:28 AM UTC+1 [email protected] wrote: > In https://github.com/sympy/sympy/pull/26399 there is proposal to allow > `subs` to recognize `Eq` so ` x.subs(x, 1) = x.subs( Eq(x, 1) ) = x.subs( [ > Eq(x, 1) ] ) = 1` but `x.subs(Eq(1, x)) = x`. > > It would be good to see if there is any strong senitment and rationale for > or against this. > > In favor, `Eq` is an immutable ordered container like Tuple (and Tuple is > recognized): > `x.subs([Tuple(x,1)]) = 1`. It seems like a natural way to pass the > information and doesn't require the user to know about `args` in order to > pass it as `Eq(x,1).args` (as is currently the case. > > Other comments are in the PR link given above. > > /c > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b918ea31-9a12-4e1b-86e8-a6c0a27ad87en%40googlegroups.com.
