Jisoo, If you can get it to work that would be great. I tried to squash everything into one commit in PR <https://github.com/sympy/sympy/pull/21333> #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 On Wednesday, May 12, 2021 at 10:53:05 PM UTC-5 JSS95 wrote: > > 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에 [email protected]님이 작성: > >> > 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. >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a2aebc5c-0d80-4fe6-a906-703d42d8d128n%40googlegroups.com.
