I think we should try to include something like this in SymPy. I'm a little confused by your screenshot. eq =@ c = d is not valid Python syntax. Are you extending the parser somehow to make it valid?
Aaron Meurer On Thu, Mar 28, 2024 at 2:10 PM '[email protected]' via sympy <[email protected]> wrote: > > 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: > > > 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. -- 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/CAKgW%3D6LSL0cFW70QMdfek%3DgeuP2eAExP2%3D9K%3D%3DteyRK8RJ8GPQ%40mail.gmail.com.
