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() 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+unsubscr...@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Kr8kNcEOxxdqS-jm0nUhm0mQySn3jvo08A7jtduEXbfg%40mail.gmail.com.
