In such case where the squash doesn't work as you would wish you can 1. merge with master, 2. create a diff relative to master, 3. create a new branch from master and 4. apply to diff and 5. copy the author to that commit.
/c On Thursday, May 13, 2021 at 8:02:32 AM UTC-5 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 > <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에 gu...@uwosh.edu님이 작성: >> >>> > 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/4377dc02-f41b-472a-836f-523ea6cdc9b3n%40googlegroups.com.