allowing Eq as recognized subs argument?

[Chris Smith]

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

[Sangyub Lee]

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.

[gu...@uwosh.edu]

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

[Aaron Meurer]

I remember this being proposed a long time ago, and there being a
pretty extensive discussion about it. We should definitely look at
what was said in those previous discussions before proceeding with
this, because I think it was intentionally decided not to support
this, if I remember the outcome correctly.

Aaron Meurer

> --
> 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 sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/f38dee22-4249-4c3f-ac77-22a34a2f7e23n%40googlegroups.com.

[Aaron Meurer]

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 'gu...@uwosh.edu' via sympy
<sy...@googlegroups.com> 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 syle...@gmail.com 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 smi...@gmail.com 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 sympy+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/69b60c58-7d97-41ae-a94e-487e38219c06n%40googlegroups.com.

[gu...@uwosh.edu]

On Thursday, March 28, 2024 at 5:47:11 PM UTC-5 asme...@gmail.com wrote:

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

Aaron,

Sorry about non-Pythonic syntax. You can define equations using `eq1 = Equation(a/b,c-d)`. For this list, I probably should not have used the compact notation.

Algebra_with_Sympy implements a pre-parser that includes the compact `=@` syntax as a substitute for `= Equation(...)`. The pre-parser also implements some other convenience features such as allowing  on-the-fly toggling  (on/off) casting of Python `int` -> Sympy `Integer`.

Most of the interactive user features depend on the existence of an `Equation` class in Sympy, although some of the interactive usability features apply to any Sympy expression. Thus, I would be strongly in favor of including the `Equation` class in Sympy. I am not in favor of modifying the behavior of the `Eq` class because currently other parts of Sympy depend upon its current behavior. Because of the current behavior of `Eq` I do not think it can be reliably used as an input to `.subs()`, `evalf()` or `solve()`. Thus the need for `Equation`.

I also think it might be better to keep the interactive convenience behaviors, such as the request that started this thread, in a separate package such as Algebra_with_Sympy. I have been able to figure out how to have them live there happily, as long as the `Equation` class is embedded in Sympy.

Jonathan

[gu...@uwosh.edu]

I have created a pull request  for an equation class that can be used as an input to `solve()` and `subs()` as well as facilitate step-by-step algebraic manipulations. It does not have the problem of collapsing to a Boolean that the `Eq` class currently part of Sympy has. This is the equation class I have been maintaining through [Algebra_with_Sympy](https://gutow.github.io/Algebra_with_Sympy/algebra_with_sympy.html) and a fork of [sympy](https://github.com/gutow/sympy-for-algebra/tree/for_algebra_1.13_2). The pull request is at: [https://github.com/sympy/sympy/pull/28258](https://github.com/sympy/sympy/pull/28258). I would appreciate comments and reviews.

The tools the pull request is derived from have been used extensively in the Chemistry community for teaching purposes (I use them to generate step-by-step answer keys and to introduce students to using CAS tools). I think we should include the Equation class in Sympy to facilitate adoption as a general use CAS tool. Sympy has now reached the stage that it is adequate for many users who do not need the full power of [SageMath](https://www.sagemath.org/) or commercial tools such as Maple and Mathematica. However, the lack of something like the proposed `Equation` class is a show-stopper for many of them, because they want to be able to manipulate equations (e.g. solve a relation algebraically in  a step-by-step manner). 

Thanks for your comments and reviews. Please put them in the [pull request](https://github.com/sympy/sympy/pull/28258). If you do not have a github account, creating one is easy and it does not mean you have to write code. The community needs input from users as well as the people who write the code.

Thanks,

Jonathan