Introducing Equation module
115 views
Skip to first unread message
JSS95
May 9, 2021, 2:12:54 AM5/9/21
to sympy
Symbolic equation has been proposed and discussed since 2020. See #19479 and previous discussion.
The idea is that Eq should be a boolean relation and Eqn should be symbolic relation. Unlike Eq, Eqn is not evaluated to True or False, and operation between equation such as (x=1) + (y=2) -> (x+y = 3) is possible. Also, there should be a simple way to manipulate the argument(s) of the equation, such as expanding the right hand side while keeping the left hand side intact.
In #21325, the basic structure for equation module is introduced.
1. `apply`, `applylhs`, and `applyrhs` properties are introduced for manipulation of the arguments. See docstring for detailed explanation.
2. `Basic.subs()` method can take equation as argument. For example, `(x*y).subs(x=2)` will return `2*y`.
3. Operations between equations are not implemented yet, in order to keep the diff small.
This change needs more review before being merged. Please leave your comment in #21325.
Jisoo Song
David Bailey
May 9, 2021, 5:28:00 PM5/9/21
to sy...@googlegroups.com
On 09/05/2021 07:12, JSS95 wrote:
Symbolic equation has been proposed and discussed since 2020. See #19479 and previous discussion.
The idea is that Eq should be a boolean relation and Eqn should be symbolic relation. Unlike Eq, Eqn is not evaluated to True or False, and operation between equation such as (x=1) + (y=2) -> (x+y = 3) is possible. Also, there should be a simple way to manipulate the argument(s) of the equation, such as expanding the right hand side while keeping the left hand side intact.
That sounds interesting, can I download some python code to test your Eqn()?
David
gu...@uwosh.edu
May 9, 2021, 5:59:25 PM5/9/21
to sympy
David,
A pip install that does this and more is available through Algebra_with_SymPy. The Algebra with SymPy repository also has a Binder link were you can try this out. I have been using it for about 18 months with undergraduates. We are still struggling to agree on a way to incorporate all these features into SymPy. To get some idea of the issues see the draft SymPEP for this. What @JSS95 is referring to can by tried by using their PR in the SymPy repository.
Input is appreciated.
Jonathan
David Bailey
May 9, 2021, 6:36:28 PM5/9/21
to sy...@googlegroups.com
On 09/05/2021 22:59, gu...@uwosh.edu
wrote:
David,
A pip install that does this and more is available through Algebra_with_SymPy. The Algebra with SymPy repository also has a Binder link were you can try this out. I have been using it for about 18 months with undergraduates. We are still struggling to agree on a way to incorporate all these features into SymPy. To get some idea of the issues see the draft SymPEP for this. What @JSS95 is referring to can by tried by using their PR in the SymPy repository.
Thanks - that worked nicely!
One immediate issue I have - that may be completely naive - is
that Eqn(a,4) prints as
a=4
but its srepr confirms that it is:
Equation(Symbol('a'), Integer(4))
Overloading = in this way feels like a source of confusion -
maybe == would be better
Wouldn't it avoid confusion to use a==4, or even a===b, or something else?
David
gu...@uwosh.edu
May 9, 2021, 6:52:33 PM5/9/21
to sympy
David,
I do not think you are being naive. The choice of representation is to keep things as close to standard mathematics as possible. However, your suggestions are approaches taken by others. For example Sagemath uses a==4 as the way to input and display something similar to the proposed Equation type. My problem with this is that it looks like the logical comparison operator in most computer languages that should yield True or False. I am not sure that is very important to most people doing math, but since I do both coding and math it bothers me. Of course a = 4 looks like an assignment in most computer languages, which is not the same thing as an equation such as a = b/c that can be manipulated to the mathematically valid statement c = b/a, on the assumption that the equality holds.
I am in favor of using '=' just as we would use '>' or '<' to maintain consistency with the most standard mathematical notation used.
Jonathan
David Bailey
May 10, 2021, 9:47:02 AM5/10/21
to sy...@googlegroups.com
On 09/05/2021 23:52, gu...@uwosh.edu wrote:
> David,
>
> I do not think you are being naive. The choice of representation is to
> keep things as close to standard mathematics as possible. However,
> your suggestions are approaches taken by others. For example Sagemath
> uses a==4 as the way to input and display something similar to the
> proposed Equation type. My problem with this is that it looks like the
> logical comparison operator in most computer languages that should
> yield True or False. I am not sure that is very important to most
> people doing math, but since I do both coding and math it bothers me.
Well of course, even people who don't do coding will understand the
> David,
>
> I do not think you are being naive. The choice of representation is to
> keep things as close to standard mathematics as possible. However,
> your suggestions are approaches taken by others. For example Sagemath
> uses a==4 as the way to input and display something similar to the
> proposed Equation type. My problem with this is that it looks like the
> logical comparison operator in most computer languages that should
> yield True or False. I am not sure that is very important to most
> people doing math, but since I do both coding and math it bothers me.
other meaning of '=' within SymPy work.
I called myself naive, in that I suppose I think it would ideally know
that SymPy would not generate ambiguous results. One simple answer here
might be not to supply a simple rendering of Equation(a,b) except to for
use with TeX, where I suppose it would be possible to render the '=' in
a larger size, or different colour.
Imagine what would happen if someone cut and pasted an Equation object
rendered using '=' to another place in the code.
David
gu...@uwosh.edu
May 11, 2021, 8:24:39 PM5/11/21
to sympy
> I called myself naive, in that I suppose I think it would ideally know
> that SymPy would not generate ambiguous results. One simple answer here
> might be not to supply a simple rendering of Equation(a,b) except to for
> use with TeX, where I suppose it would be possible to render the '=' in
> a larger size, or different colour.
> Imagine what would happen if someone cut and pasted an Equation object
> rendered using '=' to another place in the code.
> that SymPy would not generate ambiguous results. One simple answer here
> might be not to supply a simple rendering of Equation(a,b) except to for
> use with TeX, where I suppose it would be possible to render the '=' in
> a larger size, or different colour.
> Imagine what would happen if someone cut and pasted an Equation object
> rendered using '=' to another place in the code.
Yes, this is something I have struggled with what might work best. Presently, SymPy latex output in a Jupyter notebook converts `*` and `**` to more standard representations, which cannot be copied and pasted into code. The programmer solution is to assign the expression to a name and use that name where you want the code version. This works equally well for the Eqn object. I would still like to be able to copy and paste from the output, which means we may want something like what Sagemath used to do, which allowed you to toggle between latex and code view. I think that capability went away in the Jupyter compatible version, but have not tested it recently.
I agree that when Latex output is not used the output should probably be in a representation that can be directly copies into code. That is an easy change. After I grade my exams I will incorporate it into the various versions.
Jonathan
On Monday, May 10, 2021 at 8:47:02 AM UTC-5 da...wrote:
JSS95
May 12, 2021, 11:53:05 PM5/12/21
to sympy
Jonathan, may I squash the commits when the PR is merged? This means that your 80 commit logs will be lost, but you will still have the credits as a co-author.
Jisoo Song
2021년 5월 12일 수요일 오전 9시 24분 39초 UTC+9에 gu...@uwosh.edu님이 작성:
gu...@uwosh.edu
May 13, 2021, 9:02:32 AM5/13/21
to sympy
Jisoo,
If you can get it to work that would be great. I tried to squash everything into one commit in PR #21333, but I could not get GIT to do it. I'm not sure why. If you do get it to work, please let me know how.
Jonathan
Chris Smith
May 13, 2021, 11:37:09 AM5/13/21
to sympy
In such case where the squash doesn't work as you would wish you can
- merge with master,
- create a diff relative to master,
- create a new branch from master and
- apply to diff and
- copy the author to that commit.
/c
Matthias Geier
May 13, 2021, 11:47:23 AM5/13/21
to sy...@googlegroups.com
Hi Jonathan.
On Thu, May 13, 2021 at 3:02 PM gu...@uwosh.edu wrote:
>
> Jisoo,
>
> If you can get it to work that would be great. I tried to squash everything into one commit in PR #21333, but I could not get GIT to do it. I'm not sure why. If you do get it to work, please let me know how.
You could do that:
git rebase master --interactive
Your favorite editor will be opened and you can replace the "pick"
with "squash" or "fixup" as you like.
After saving the file and closing the editor, your new commit(s) will
be available.
This will keep the author information.
HTH,
Matthias
> --
> 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/a2aebc5c-0d80-4fe6-a906-703d42d8d128n%40googlegroups.com.
On Thu, May 13, 2021 at 3:02 PM gu...@uwosh.edu wrote:
>
> Jisoo,
>
> If you can get it to work that would be great. I tried to squash everything into one commit in PR #21333, but I could not get GIT to do it. I'm not sure why. If you do get it to work, please let me know how.
git rebase master --interactive
Your favorite editor will be opened and you can replace the "pick"
with "squash" or "fixup" as you like.
After saving the file and closing the editor, your new commit(s) will
be available.
This will keep the author information.
HTH,
Matthias
> 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/a2aebc5c-0d80-4fe6-a906-703d42d8d128n%40googlegroups.com.
gu...@uwosh.edu
May 13, 2021, 12:47:31 PM5/13/21
to sympy
Having tried various versions of what Matthias suggests, I think the solution for my case is probably what Chris suggests.
Thanks,
Jonathan
Oscar Benjamin
May 13, 2021, 1:00:31 PM5/13/21
to sympy
I think when you've merged with master a few times already it gets
fiddly to do anything other than what Chris suggests. The rebase can
be worth it if there was a clean commit history but if you're
squashing then you can just do it the direct way.
I would do this like:
$ git checkout mybranch
$ git checkout -b mybranch_backup # make a backup!
$ git checkout mybranch
$ git fetch upstream
$ git merge upstream/master
$ git diff upstream/master > mybranch.diff
$ git reset --hard HEAD~1000 # <-- wipe 1000 commits, more might be needed...
$ git pull upstream/master
$ git apply mybranch.diff
Then you add, commit etc, use Co-authored-by for other authors and finally
$ git push --force
Oscar
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e5781162-6a5b-4742-9192-f67ca7d9f409n%40googlegroups.com.
fiddly to do anything other than what Chris suggests. The rebase can
be worth it if there was a clean commit history but if you're
squashing then you can just do it the direct way.
I would do this like:
$ git checkout mybranch
$ git checkout -b mybranch_backup # make a backup!
$ git checkout mybranch
$ git fetch upstream
$ git merge upstream/master
$ git diff upstream/master > mybranch.diff
$ git reset --hard HEAD~1000 # <-- wipe 1000 commits, more might be needed...
$ git pull upstream/master
$ git apply mybranch.diff
Then you add, commit etc, use Co-authored-by for other authors and finally
$ git push --force
Oscar
Matthias Geier
May 13, 2021, 1:44:12 PM5/13/21
to sy...@googlegroups.com
On Thu, May 13, 2021 at 6:47 PM gu...@uwosh.edu wrote:
>
> Having tried various versions of what Matthias suggests, I think the solution for my case is probably what Chris suggests.
Using the one command I suggested, this takes less than a minute and
>
> Having tried various versions of what Matthias suggests, I think the solution for my case is probably what Chris suggests.
there is no way I can forget to add anything. And the author
information is automatically taken care of.
Here's a squashed commit I just created, for closer inspection:
https://github.com/mgeier/sympy/commit/92e0f806dc615219e3617f90b56c18ae8ee8ee28
cheers,
Matthias
Chris Smith
May 13, 2021, 4:35:23 PM5/13/21
to sympy
>
I would do this like:
Interesting to see the different approaches. My version doesn't involve resetting the head:
git checkout master
git pull
git checkout my
git merge master
git diff master > dif
git branch myback
git checkout master
git branch -D my
git checkout -b my
git apply dif
git commit
git commit
git branch -D myback
git push -f
/c
Aaron Meurer
May 13, 2021, 7:23:16 PM5/13/21
to sympy
On Tue, May 11, 2021 at 6:24 PM gu...@uwosh.edu <gu...@uwosh.edu> wrote:
>
> > I called myself naive, in that I suppose I think it would ideally know
> > that SymPy would not generate ambiguous results. One simple answer here
> > might be not to supply a simple rendering of Equation(a,b) except to for
> > use with TeX, where I suppose it would be possible to render the '=' in
> > a larger size, or different colour.
>
> > Imagine what would happen if someone cut and pasted an Equation object
> > rendered using '=' to another place in the code.
>
> Yes, this is something I have struggled with what might work best. Presently, SymPy latex output in a Jupyter notebook converts `*` and `**` to more standard representations, which cannot be copied and pasted into code. The programmer solution is to assign the expression to a name and use that name where you want the code version. This works equally well for the Eqn object. I would still like to be able to copy and paste from the output, which means we may want something like what Sagemath used to do, which allowed you to toggle between latex and code view. I think that capability went away in the Jupyter compatible version, but have not tested it recently.
>
> I agree that when Latex output is not used the output should probably be in a representation that can be directly copies into code. That is an easy change. After I grade my exams I will incorporate it into the various versions.
The standard SymPy way of dealing with this is that the str()
>
> > I called myself naive, in that I suppose I think it would ideally know
> > that SymPy would not generate ambiguous results. One simple answer here
> > might be not to supply a simple rendering of Equation(a,b) except to for
> > use with TeX, where I suppose it would be possible to render the '=' in
> > a larger size, or different colour.
>
> > Imagine what would happen if someone cut and pasted an Equation object
> > rendered using '=' to another place in the code.
>
> Yes, this is something I have struggled with what might work best. Presently, SymPy latex output in a Jupyter notebook converts `*` and `**` to more standard representations, which cannot be copied and pasted into code. The programmer solution is to assign the expression to a name and use that name where you want the code version. This works equally well for the Eqn object. I would still like to be able to copy and paste from the output, which means we may want something like what Sagemath used to do, which allowed you to toggle between latex and code view. I think that capability went away in the Jupyter compatible version, but have not tested it recently.
>
> I agree that when Latex output is not used the output should probably be in a representation that can be directly copies into code. That is an easy change. After I grade my exams I will incorporate it into the various versions.
representation should be something that can be copy-pasted (this is
what print() will give), but the pprint() and latex() representation
should be as readable as possible as a mathematical expression.
Aaron Meurer
>
> Jonathan
>
> On Monday, May 10, 2021 at 8:47:02 AM UTC-5 da...wrote:
>>
>> On 09/05/2021 23:52, wrote:
>> > David,
>> >
>> > I do not think you are being naive. The choice of representation is to
>> > keep things as close to standard mathematics as possible. However,
>> > your suggestions are approaches taken by others. For example Sagemath
>> > uses a==4 as the way to input and display something similar to the
>> > proposed Equation type. My problem with this is that it looks like the
>> > logical comparison operator in most computer languages that should
>> > yield True or False. I am not sure that is very important to most
>> > people doing math, but since I do both coding and math it bothers me.
>>
>> Well of course, even people who don't do coding will understand the
>> other meaning of '=' within SymPy work.
>>
>> I called myself naive, in that I suppose I think it would ideally know
>> that SymPy would not generate ambiguous results. One simple answer here
>> might be not to supply a simple rendering of Equation(a,b) except to for
>> use with TeX, where I suppose it would be possible to render the '=' in
>> a larger size, or different colour.
>>
>> Imagine what would happen if someone cut and pasted an Equation object
>> rendered using '=' to another place in the code.
>>
>> David
>>
>>
> --
> 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/164822bb-4c13-411c-8167-b06fd815272cn%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 sympy+un...@googlegroups.com.
Chris Smith
May 14, 2021, 9:05:27 AM5/14/21
to sympy
>
the str() representation should be something that can be copy-pasted
This, of course, allows for creativity in presentation to get the cut-and-paste right while still giving something that is easy to look at. Consider the matrix-like presentation of Matrix:
>>> ones(2)
Matrix([
[1, 1],
[1, 1]])
/c
gu...@uwosh.edu
May 19, 2021, 8:57:52 PM5/19/21
to sympy
On Friday, May 14, 2021 at 8:05:27 AM UTC-5 smi...@gmail.com wrote:
>
the str() representation should be something that can be copy-pasted
I like the ability to cut-and-paste the output of a `print()`. However, delving into the standards for Python suggests that `repr()` should return an expression that can be passed to `eval()`, but `str()` is meant to be human readable and may or may not work with `eval()`. Within Sympy I do not see a problem, but worry that Sympy may be depending on `str()===repr()` in libraries it uses. Does anybody have some insight into this?
Jonathan
Hanspeter Schmid
May 20, 2021, 6:45:39 AM5/20/21
to sympy
In SymPy, str() is meant to be copy-paste-d. See https://docs.sympy.org/latest/tutorial/printing.html#str
Hanspi
gu...@uwosh.edu
May 20, 2021, 8:13:14 AM5/20/21
to sympy
On Thursday, May 20, 2021 at 5:45:39 AM UTC-5 hanspete...@fhnw.ch wrote:
In SymPy, str() is meant to be copy-paste-d. See https://docs.sympy.org/latest/tutorial/printing.html#st
Let me restate my question. I am clear on what the sympy standard is. What I am unclear about is how this works with other libraries that sympy depends upon? For example mpmath (see https://mpmath.org/doc/current/basics.html#printing). For mpmath the str() representation is not equivalent to the repr(), although str() should still work as valid python. Are there other places where sympy uses external libraries where the output of print() and str() potentially varies from the sympy standard?
Jonathan
Reply all
Reply to author
Forward
0 new messages