It seems to me that we are about to start again the discussion that lead me to propose and implement the `Equation` class. This class has not been folded into Sympy, but exists in the fork I am presently maintaining https://github.com/gutow/sympy-for-algebra/, which I ended up creating to support behavior like those requested that are supplied by the package algebra_with_sympy (https://gutow.github.io/Algebra_with_Sympy/). I could not reliably implement behaviors on top of the `Eq` class because it will collapse to a boolean if sympy can evaluate the expression as True or False. Screen shot of the desired behavior presently implemented in Algebra_with_Sympy: [image: Screenshot 2024-03-28 at 2.55.35 PM.png]
Should we consider getting the `Equation` class or a form of it into sympy itself? This would allow many of the usability features I have included in Algebra_with_Sympy to be easily implemented or extended by others. Jonathan On Thursday, March 28, 2024 at 11:06:15 AM UTC-5 [email protected] wrote: > 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/69b60c58-7d97-41ae-a94e-487e38219c06n%40googlegroups.com.
