Re: [sympy] Re: Real-Root Isolation
Ah, I was afraid of that. Looking at the code, I'm not sure if the algorithm provides a better way than continually refining with smaller epsilon until you get a separation, but I don't know the details of the algorithm so that could be wrong. I will note that you can use refine_root() once you have your intervals to just refine a single interval, which would at least be a little more efficient. Aaron Meurer On Tue, May 21, 2024 at 4:30 PM Ani J wrote: > > It doesn't look like just taking the minimum length works. > Consider the following program: > > from sympy import Poly > from sympy.abc import x > from sympy import div, ZZ, QQ, RR > p = Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, > domain='QQ') > print(p.intervals()) > print(p.intervals(eps=0.5)) > > > like just taking the minimum length works. The first output is: [((-3, -2), > 1), ((-1, -1), 1), ((-1, 0), 1), ((1, 1), 1)] > Here the minimum interval length (>0) is 1. Even using 0.5 as the interval > length in the next line prints: [((-3, -14/5), 1), ((-1, -1), 1), ((-1, > -4/5), 1), ((1, 1), 1)] > but this has -1 as the common endpoint between the second and the third > interval. > It would be great if the intervals have different endpoint. For now, I just > start a while loop with eps=1 and keep dividing eps by 2, > until I get different endpoints. Hope this works for now. > > Best > > On Tuesday, May 21, 2024 at 2:02:20 PM UTC-7 asme...@gmail.com wrote: >> >> I'm not sure if it's enough to just take the minimum length of the >> intervals that overlap and set eps to something smaller than that. >> Someone more familiar with the inner workings of the algorithm would >> have to verify whether that would work or if it could still leave >> intersecting endpoints. >> >> IMO, we should just fix the function to not return intersecting >> endpoints in the first place. The intervals aren't really isolating if >> they intersect. >> >> Aaron Meurer >> >> On Tue, May 21, 2024 at 2:58 PM Ani J wrote: >> > >> > Yes, this seems like a good option, so keep reducing eps in a while loop >> > until the endpoints of all intervals are different, right? >> > >> > On Tuesday, May 21, 2024 at 1:55:54 PM UTC-7 asme...@gmail.com wrote: >> >> >> >> I don't know if there's an existing option to do this. It seems like >> >> it would be useful. You can always lower the eps to make the intervals >> >> smaller: >> >> >> >> >>> Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, >> >> >>> domain='QQ').intervals(eps=0.1) >> >> [((-29/10, -26/9), 1), ((-1, -1), 1), ((-10/11, -9/10), 1), ((1, 1), 1)] >> >> >> >> Aaron Meurer >> >> >> >> On Tue, May 21, 2024 at 2:51 PM Ani J wrote: >> >> > >> >> > >> >> > Oh! I see, but i believe that the intervals overlap on the endpoints, >> >> > is it possible to make the intervals completely disjoint?? >> >> > For example consider the following program: >> >> > >> >> > from sympy import Poly >> >> > from sympy.abc import x >> >> > from sympy import div, QQ >> >> > p = Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, >> >> > domain='QQ') >> >> > p.intervals() >> >> > >> >> > The intervals that this outputs is: [((-3, -2), 1), ((-1, -1), 1), >> >> > ((-1, 0), 1), ((1, 1), 1)] >> >> > >> >> > Here we can see that the point -1 is a common endpoint between the >> >> > second and >> >> > >> >> > the third term. Is it possible to enforce that there be no common point? >> >> > >> >> > >> >> > Best >> >> > >> >> > On Tuesday, May 21, 2024 at 10:27:15 AM UTC-7 asme...@gmail.com wrote: >> >> >> >> >> >> Yes, this is the case. The documentation for this method could perhaps >> >> >> be improved, but the key word is "isolating", meaning each interval >> >> >> contains exactly one root. You can also read more about the algorithm >> >> >> that is referenced in the docstring >> >> >> https://en.wikipedia.org/wiki/Vincent%27s_theorem >> >> >> >> >> >> Aaron Meurer >> >> >> >> >> >> >> >> >> On Tue, May 21, 2024 at 9:18 AM Chris Smith wrote: >> &g
Re: [sympy] Re: Real-Root Isolation
I'm not sure if it's enough to just take the minimum length of the intervals that overlap and set eps to something smaller than that. Someone more familiar with the inner workings of the algorithm would have to verify whether that would work or if it could still leave intersecting endpoints. IMO, we should just fix the function to not return intersecting endpoints in the first place. The intervals aren't really isolating if they intersect. Aaron Meurer On Tue, May 21, 2024 at 2:58 PM Ani J wrote: > > Yes, this seems like a good option, so keep reducing eps in a while loop > until the endpoints of all intervals are different, right? > > On Tuesday, May 21, 2024 at 1:55:54 PM UTC-7 asme...@gmail.com wrote: >> >> I don't know if there's an existing option to do this. It seems like >> it would be useful. You can always lower the eps to make the intervals >> smaller: >> >> >>> Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, >> >>> domain='QQ').intervals(eps=0.1) >> [((-29/10, -26/9), 1), ((-1, -1), 1), ((-10/11, -9/10), 1), ((1, 1), 1)] >> >> Aaron Meurer >> >> On Tue, May 21, 2024 at 2:51 PM Ani J wrote: >> > >> > >> > Oh! I see, but i believe that the intervals overlap on the endpoints, is >> > it possible to make the intervals completely disjoint?? >> > For example consider the following program: >> > >> > from sympy import Poly >> > from sympy.abc import x >> > from sympy import div, QQ >> > p = Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, >> > domain='QQ') >> > p.intervals() >> > >> > The intervals that this outputs is: [((-3, -2), 1), ((-1, -1), 1), ((-1, >> > 0), 1), ((1, 1), 1)] >> > >> > Here we can see that the point -1 is a common endpoint between the second >> > and >> > >> > the third term. Is it possible to enforce that there be no common point? >> > >> > >> > Best >> > >> > On Tuesday, May 21, 2024 at 10:27:15 AM UTC-7 asme...@gmail.com wrote: >> >> >> >> Yes, this is the case. The documentation for this method could perhaps >> >> be improved, but the key word is "isolating", meaning each interval >> >> contains exactly one root. You can also read more about the algorithm >> >> that is referenced in the docstring >> >> https://en.wikipedia.org/wiki/Vincent%27s_theorem >> >> >> >> Aaron Meurer >> >> >> >> >> >> On Tue, May 21, 2024 at 9:18 AM Chris Smith wrote: >> >> > >> >> > I strongly suspect that the roots returned by `Poly.intervals` have >> >> > only one root in them (by definition). If you use >> >> > `refine_root(lo,hi,eps)` to refine the root bounds to arbitrary width >> >> > and give it an interval in which there is more than one root, it will >> >> > raise an error. >> >> > >> >> > /c >> >> > On Tuesday, May 21, 2024 at 6:06:14 AM UTC-5 ani...@gmail.com wrote: >> >> >> >> >> >> Is it possible to use SymPy library to get intervals (with rational >> >> >> endpoints) such that there is exactly one root in the interval? I >> >> >> would like to use an implementation of RRI algorithm for my purpose. I >> >> >> believe that the interval function does this. Is this correct? Is it >> >> >> guaranteed that the output intervals are guaranteed to not have any >> >> >> common points? >> >> >> >> >> >> >> >> > -- >> >> > 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/807f8910-040d-475b-91b6-a5002cedeea0n%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. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sympy/884eb7ff-0762-4771-a81f-930c13dada2dn%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/c987974b-cf39-4c8a-ad0a-579b61778513n%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%3D6LB2-7GKdeUx5z3qaST6K-s22MSUs%2Bi%3DDA2_Nh67URU3Q%40mail.gmail.com.
Re: [sympy] Re: Real-Root Isolation
I don't know if there's an existing option to do this. It seems like it would be useful. You can always lower the eps to make the intervals smaller: >>> Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, >>> domain='QQ').intervals(eps=0.1) [((-29/10, -26/9), 1), ((-1, -1), 1), ((-10/11, -9/10), 1), ((1, 1), 1)] Aaron Meurer On Tue, May 21, 2024 at 2:51 PM Ani J wrote: > > > Oh! I see, but i believe that the intervals overlap on the endpoints, is it > possible to make the intervals completely disjoint?? > For example consider the following program: > > from sympy import Poly > from sympy.abc import x > from sympy import div, QQ > p = Poly(x**6 + 19/5*x**5 + 131/50*x**4 - x**2 - 19/5*x - 131/50, x, > domain='QQ') > p.intervals() > > The intervals that this outputs is: [((-3, -2), 1), ((-1, -1), 1), ((-1, 0), > 1), ((1, 1), 1)] > > Here we can see that the point -1 is a common endpoint between the second and > > the third term. Is it possible to enforce that there be no common point? > > > Best > > On Tuesday, May 21, 2024 at 10:27:15 AM UTC-7 asme...@gmail.com wrote: >> >> Yes, this is the case. The documentation for this method could perhaps >> be improved, but the key word is "isolating", meaning each interval >> contains exactly one root. You can also read more about the algorithm >> that is referenced in the docstring >> https://en.wikipedia.org/wiki/Vincent%27s_theorem >> >> Aaron Meurer >> >> >> On Tue, May 21, 2024 at 9:18 AM Chris Smith wrote: >> > >> > I strongly suspect that the roots returned by `Poly.intervals` have only >> > one root in them (by definition). If you use `refine_root(lo,hi,eps)` to >> > refine the root bounds to arbitrary width and give it an interval in which >> > there is more than one root, it will raise an error. >> > >> > /c >> > On Tuesday, May 21, 2024 at 6:06:14 AM UTC-5 ani...@gmail.com wrote: >> >> >> >> Is it possible to use SymPy library to get intervals (with rational >> >> endpoints) such that there is exactly one root in the interval? I would >> >> like to use an implementation of RRI algorithm for my purpose. I believe >> >> that the interval function does this. Is this correct? Is it guaranteed >> >> that the output intervals are guaranteed to not have any common points? >> >> >> >> >> > -- >> > 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/807f8910-040d-475b-91b6-a5002cedeea0n%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/884eb7ff-0762-4771-a81f-930c13dada2dn%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%3D6LCaEVXOcE_Y8%3DuwPD9mxkDmRy-zpDOvFORRP%2BoAZxyxQ%40mail.gmail.com.
Re: [sympy] Re: Real-Root Isolation
Yes, this is the case. The documentation for this method could perhaps be improved, but the key word is "isolating", meaning each interval contains exactly one root. You can also read more about the algorithm that is referenced in the docstring https://en.wikipedia.org/wiki/Vincent%27s_theorem Aaron Meurer On Tue, May 21, 2024 at 9:18 AM Chris Smith wrote: > > I strongly suspect that the roots returned by `Poly.intervals` have only one > root in them (by definition). If you use `refine_root(lo,hi,eps)` to refine > the root bounds to arbitrary width and give it an interval in which there is > more than one root, it will raise an error. > > /c > On Tuesday, May 21, 2024 at 6:06:14 AM UTC-5 ani...@gmail.com wrote: >> >> Is it possible to use SymPy library to get intervals (with rational >> endpoints) such that there is exactly one root in the interval? I would like >> to use an implementation of RRI algorithm for my purpose. I believe that the >> interval function does this. Is this correct? Is it guaranteed that the >> output intervals are guaranteed to not have any common points? >> >> > -- > 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/807f8910-040d-475b-91b6-a5002cedeea0n%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%3D6Ku7CAXsreQ%2B2qkG3inxU7YuYMcK7-ndMgt%2Bc14wPrQVA%40mail.gmail.com.
[sympy] SWE-agent paper uses SymPy
The SWE-agent project uses LLMs to try to automatically fix issues in GitHub repositories. I found their paper interesting, mostly because they make extensive use of SymPy as a test repository. https://swe-agent.com/ Apparently there are quite a few SymPy issues in the SWE-bench dataset, which is a dataset of issues and corresponding pull requests in open source projects. https://www.swebench.com/ Their model was able to fix 10% of SymPy issues in the dataset. That's obviously not going to replace human developers any time soon, but it's still interesting. From what I could tell, the issues seem to be biased towards more easy/straightforward ones (i.e., ones that are easy to verify if a fix is correct or not). But still, if LLMs are reaching a point where they can fix bugs completely automatically that could be very useful. 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JvWJBCnfbQjsQOo5VCOFw2jG-jXr36UYbkaQZ07TtRtA%40mail.gmail.com.
Re: [sympy] New feature possibility
On Wed, May 15, 2024 at 10:41 AM Francesco Bonazzi wrote: > > > > On Monday, May 13, 2024 at 4:56:30 p.m. UTC+2 henrique...@tecnico.ulisboa.pt > wrote: > > Sorry for the late response, we've been busy with other subjects. > What about time systems, included in the "Misc" section in the page mentioned > on my first message? > > > That page hasn't really been updated since 2014 :( > Time units are already supported. Calendars are not. I cannot think of a use > case where users would use SymPy for calendars. I agree. We don't want SymPy to become a datetime library. There are already excellent libraries for that, and they are a lot of work to write and maintain correctly. Aaron Meurer > > Or is there anything from the units module you would like us to work on? > > > It would be nice to have transformations between unit systems. But that's > quite hard to implement. > > -- > 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/52560e2f-c9c3-48b3-bdbf-577628c2c67bn%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%3D6J4%3DrE26Xvgo1uw0cp8it4%2BTuoJK67L5-Pd3Zpx-JDthw%40mail.gmail.com.
Re: [sympy] New feature possibility
Francesco could probably give a more specific answer, but I imagine you could find some things that need fixing in the units module if you search in the issue tracker. Aaron Meurer On Mon, May 13, 2024 at 8:56 AM 'Henrique Miguel Cortes Soares' via sympy wrote: > > Sorry for the late response, we've been busy with other subjects. > What about time systems, included in the "Misc" section in the page mentioned > on my first message? Or is there anything from the units module you would > like us to work on? > We could also work on some new area where sympy is still at a basic level, if > there is one. > > On Monday, April 29, 2024 at 1:20:12 PM UTC+1 Francesco Bonazzi wrote: >> >> The class UnitSystem in SymPy defines the relations between units. In most >> cases, the Imperial Units follow the same relations as the SI unit system >> (maybe there are slight differences in fluid units between the UK and the >> US?). Anyways, creating an imperial unit system does not make any sense to >> me, as the SI unit system already implements the relations between imperial >> units. >> >> New unit systems should be implemented when the relations between units or >> physical constants are different than in SI. For example, in CGS there is no >> fundamental unit for electromagnetic quantities, and also physical equations >> are different from SI. >> >> Bear in mind that UnitSystem defines the behaviour of the function >> "convert_to". You can convert Imperial Units using "convert_to" from SI >> without any issue (relationships are the same). On the other hand, >> "convert_to" behaves differently in other unit systems, such as CGS or >> Natural units. >> >> On Thursday, April 25, 2024 at 10:02:04 p.m. UTC+2 Aaron Meurer wrote: >>> >>> Looking closer, I think you might be right that the imperial system >>> isn't there. The units are all defined, but there isn't an imperial >>> Unitsystem that includes them all. This should be straightforward to >>> add, The main concern I see is that there isn't a single "imperial >>> system" and what's often called that contains many units that measure >>> the same quantities. But the SymPy unit systems define a single unit >>> for each quantity. So we may need to add multiple "systems" to >>> represent the imperial units. >>> >>> Aaron Meurer >>> >>> On Thu, Apr 25, 2024 at 1:56 PM Aaron Meurer wrote: >>> > >>> > I believe the imperial system should already be there, but if there's >>> > anything missing, we should fix that. >>> > >>> > Aaron Meurer >>> > >>> > On Thu, Apr 25, 2024 at 10:06 AM 'Henrique Miguel Cortes Soares' via >>> > sympy wrote: >>> > > >>> > > So, should the imperial system be added? If not, what system could we >>> > > add then? >>> > > >>> > > Henrique Soares >>> > > >>> > > On Tuesday, April 23, 2024 at 10:56:47 PM UTC+1 asme...@gmail.com wrote: >>> > >> >>> > >> I would say that new unit systems should be added only if they are >>> > >> generally used and useful. General improvements to the units module >>> > >> are always welcome. Francesco is the main maintainer of the units >>> > >> module, so he would know more details on what needs to be done there. >>> > >> >>> > >> Aaron Meurer >>> > >> >>> > >> On Tue, Apr 23, 2024 at 3:54 PM 'Henrique Miguel Cortes Soares' via >>> > >> sympy wrote: >>> > >> > >>> > >> > Hello all, >>> > >> > >>> > >> > I've seen in the page >>> > >> > https://github.com/sympy/sympy/wiki/Unit-systems that two of the >>> > >> > possible improvements for the unit systems in SymPy are to define >>> > >> > new unit systems and improving the access to units and dimensions in >>> > >> > a given system. >>> > >> > Me and a friend wanted to give this feature a try, in the context of >>> > >> > a subject of a Computer Science course we are both taking. >>> > >> > So, I wanted to ask whether the functionality I described is >>> > >> > something worth working on and not yet implemented. >>> > >> > >>> > >> > Thank you for your time. >>&
Re: [sympy] GSoC 2024 Contributors Announced
Yes, I probably should have shared this initially, but you can see a list of the projects with their summaries at https://summerofcode.withgoogle.com/programs/2024/organizations/sympy Aaron Meurer On Fri, May 3, 2024 at 12:25 PM wrote: > > Dear Aaron, > > I am happy to join in congratulating the guys selected for GSoC! > > I am a retired salesman (studied engineering 45+ years ago) and I play around > with sympy.phyiscs.mechanics to pass time. VERY enjoyable! > I have never made a PR, and the equation: me + GitHub / computers = complete > messholds true. > > These two projects look interesting to me: > > Hwayeon Kang, Implementing Specific Forces and Torques: Jason Moore, Timo > Stienstra > Riccardo Di Girolamo, Sympy for Classical Mechanics: Developing and > Benchmarking Equations of Motion Generation Methods: Jason Moore, Timo > Stienstra > > Is there a way, I can 'see' what will be done there? > > Thanks & take care! > > Peter > > -----Original Message- > From: sympy@googlegroups.com On Behalf Of Aaron > Meurer > Sent: Donnerstag, 2. Mai 2024 21:36 > To: sympy > Subject: [sympy] GSoC 2024 Contributors Announced > > Hi everyone. As many of you may have noticed, Google has announced the > results for Google Summer of Code. I am proud to announce that 5 people have > been accepted to work on SymPy this year. The following projects have been > accepted: > > Abhishek Kumar, Improving and Expanding the functionalities of the SymPy's > Control Module.: Nikhil Maan > > Arnab Nandi, Improving Series Expansions and Limit Computations: > Anutosh Surendra Bhat, Oscar Benjamin > > Hwayeon Kang, Implementing Specific Forces and Torques: Jason Moore, Timo > Stienstra > > Riccardo Di Girolamo, Sympy for Classical Mechanics: Developing and > Benchmarking Equations of Motion Generation Methods: Jason Moore, Timo > Stienstra > > Shishir Kushwaha, Extending Continuum Mechanics Module: Advait Pote, Ishan > Pandhare > > Join me in congratulating them on their acceptance. > > To everyone who was accepted, you should be receiving an email from your > mentors soon to discuss how you will be communicating over the summer about > your project. You should meet with your mentors once a week during the summer > to go over your progress. Most people choose to use video calls for these > meetings, but you may use another method, such as a public chatroom, if you > prefer. > > Note that in many cases you may interact with some mentors as your primary > mentors, and other mentors will be backup mentors. Please contact the backup > mentors if you are not able to get ahold of your primary mentor(s). If you > cannot get ahold of either, please let me and Oscar Benjamin > (oscar.j.benja...@gmail.com) know immediately. > > I would like all of us to strongly encourage students to submit pull requests > early and often. This will go a long ways towards making sure that you don't > end the summer with a ton of code written that never gets merged. Students > should help review pull requests by other students, so that we don't get > bogged down reviewing so much code. > > We also require that all students keep a weekly blog of their work over the > summer. If you don't already have a blog, you should start one. I recommend > using either Wordpress, Blogger, or creating your own blog on GitHub pages. > If you are savvy enough to set it up, I recommend GitHub pages, but if you > aren't, both Wordpress and Blogger are good enough. > > The GSoC coding period officially starts May 27 > (https://developers.google.com/open-source/gsoc/timeline). > > I would like to thank all the students who applied this year and everyone who > submitted a patch. I would also like to thank all the mentors for helping > review patches and proposals. > > This summer is looking to be another very productive one for SymPy, and I > look forward to it! > > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B6r%2BxD_7DjRR60WuAhnsJkRw6SMWOpwTsnVN0D-JrjKw%40mail.gmail.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/004601da9d87%24509
Re: [sympy] Continuing with GSOC Proposal without Funding
Hi Sam. You are always free to contribute to SymPy outside of GSoC. I think everything that you proposed in your proposal is something that we want for SymPy. I can't commit to full time mentorship, but I can try my best to take a look at your pull requests and review them and offer suggestions. Aaron Meurer On Wed, May 1, 2024 at 3:03 PM Sam Lubelsky wrote: > > Hello, > > I unfortunately just found out that my proposal was not accepted for GSOC, > but I am still interested in forging ahead with my project this summer(though > likely with a slightly scope than originally planned). > > I was wondering if there were any big issues with my proposal(GSOC 2024 > Benchmarks and Performance - Google Docs) that would need to get fixed before > I would start to work on it. If so, I would like to figure them out as soon > as possible so I can get to work. Also, if it seems like the project is just > not a good fit I would be open to working on something completely different > than what my proposal layed out. > > I was also wondering if I would be able to have someone as a mentor this > summer. I understand that Sympy's mentors' time is very limited and is > already being spread thin among all the accepted GSOC applicants, but I think > having someone more experienced with Sympy to ask questions to and get good > feedback from would be very helpful. > > Thanks, > Sam. > > -- > 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/6630bb33-7c0f-468a-a1b8-ee07a078ce58n%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%3D6LhUAv19G5JULi_jaoLoyOpAwb7pRqQ5_Fr%3DO_f8tywFg%40mail.gmail.com.
Re: [sympy] Re: Enhancing the flexibility of MatchPy
Hi Samith. You are always free to contribute to SymPy independently of GSoC, as it is an open source project and you can always contribute to an open source project. We can't guarantee you the mentorship that a GSoC contributor would receive. It would be up to Francesco and other community members if he is interested in helping out with this project. Aaron Meurer On Wed, May 1, 2024 at 7:58 PM Samith Kavishke wrote: > > Hi, > Eventhough have not been selected, do we still have a chance to continue the > project? Without the stipend. > > On Tuesday, April 2, 2024 at 7:14:15 AM UTC+5:30 Samith Kavishke wrote: >> >> I have attached the changed version of this project. Thank you! >> >> On Monday, April 1, 2024 at 2:43:25 PM UTC+5:30 Samith Kavishke wrote: >>> >>> I will go through it and try to suggest a new method if time permits. Thank >>> you Francesco you helped a lot to achieve this amount. >>> >>> On Monday, April 1, 2024 at 2:27:15 PM UTC+5:30 Francesco Bonazzi wrote: >>>> >>>> The issue I see in the proposal is that the methods should probably be >>>> functions, not class methods. If we keep class methods we are probably >>>> still forced to use subclassing (I would like to avoid that). Anyways, it >>>> looks good, this is just a minor issue >>>> >>>> On Tuesday, March 26, 2024 at 12:07:15 p.m. UTC+1 Francesco Bonazzi wrote: >>>>> >>>>> The base idea is about modifying MatchPy in order to allow easy >>>>> integration of MatchPy into SymPy and into the python bindings of >>>>> protosym. Additional extensions to the project idea are welcome, provided >>>>> there is enough time to complete them. Trying a translation of MatchPy >>>>> into Rust has the potential of speeding up the library a lot, but it >>>>> should be benchmarked. >>>>> >>>>> On Tuesday, March 26, 2024 at 2:54:23 a.m. UTC+1 samithkar...@gmail.com >>>>> wrote: >>>>>> >>>>>> Is it worth for me to mention about the Protosym's architecture, in >>>>>> order to strengthen my proposal ? or do I need more contributions in >>>>>> sympy repositories. >>>>>> >>>>>> On Sunday, March 24, 2024 at 4:29:40 AM UTC+5:30 Samith Kavishke wrote: >>>>>>> >>>>>>> Hi, >>>>>>> Thank you, Francesco for your valuable insights. I have attached my >>>>>>> current draft of GSOC 24 proposal. Can you help me with feedbacks for >>>>>>> the proposal. >>>>>>> >>>>>>> >>>>>>> On Tuesday, March 19, 2024 at 8:15:07 PM UTC+5:30 Francesco Bonazzi >>>>>>> wrote: >>>>>>>> >>>>>>>> No, no parsers are needed. Just a tree traversal for-loop. It's >>>>>>>> already implemented: >>>>>>>> >>>>>>>> iterator >>>>>>>> iterator size >>>>>>>> >>>>>>>> As you see, in the current implementation we need to use >>>>>>>> @op_iter.register... because "op_iter" is a MatchPy function that does >>>>>>>> not exist in SymPy... With @op_iter.register we can extend it to a >>>>>>>> SymPy object. The problem is: >>>>>>>> >>>>>>>> @op_iter.register is an almost hackish way to do it, it messes up with >>>>>>>> the class inheritance. We need something easier to use. >>>>>>>> The .register method defines the iterator on a class. We may have >>>>>>>> cases in which we would like to have different iterators for the same >>>>>>>> class... so it shouldn't be a class method. >>>>>>>> >>>>>>>> >>>>>>>> On Monday, March 18, 2024 at 11:20:10 p.m. UTC+1 >>>>>>>> samithkar...@gmail.com wrote: >>>>>>>>> >>>>>>>>> I think, I understood the point you are making. If we are going to >>>>>>>>> redefine the tree structure in matchpy using overridable methods, >>>>>>>>> does that mean we have to use a parser to translate the sympy object >>>>>>>>> type to matchpy or are there any better way to handle the situation. >>>>>>>>> On
[sympy] GSoC 2024 Contributors Announced
Hi everyone. As many of you may have noticed, Google has announced the results for Google Summer of Code. I am proud to announce that 5 people have been accepted to work on SymPy this year. The following projects have been accepted: Abhishek Kumar, Improving and Expanding the functionalities of the SymPy's Control Module.: Nikhil Maan Arnab Nandi, Improving Series Expansions and Limit Computations: Anutosh Surendra Bhat, Oscar Benjamin Hwayeon Kang, Implementing Specific Forces and Torques: Jason Moore, Timo Stienstra Riccardo Di Girolamo, Sympy for Classical Mechanics: Developing and Benchmarking Equations of Motion Generation Methods: Jason Moore, Timo Stienstra Shishir Kushwaha, Extending Continuum Mechanics Module: Advait Pote, Ishan Pandhare Join me in congratulating them on their acceptance. To everyone who was accepted, you should be receiving an email from your mentors soon to discuss how you will be communicating over the summer about your project. You should meet with your mentors once a week during the summer to go over your progress. Most people choose to use video calls for these meetings, but you may use another method, such as a public chatroom, if you prefer. Note that in many cases you may interact with some mentors as your primary mentors, and other mentors will be backup mentors. Please contact the backup mentors if you are not able to get ahold of your primary mentor(s). If you cannot get ahold of either, please let me and Oscar Benjamin (oscar.j.benja...@gmail.com) know immediately. I would like all of us to strongly encourage students to submit pull requests early and often. This will go a long ways towards making sure that you don't end the summer with a ton of code written that never gets merged. Students should help review pull requests by other students, so that we don't get bogged down reviewing so much code. We also require that all students keep a weekly blog of their work over the summer. If you don't already have a blog, you should start one. I recommend using either Wordpress, Blogger, or creating your own blog on GitHub pages. If you are savvy enough to set it up, I recommend GitHub pages, but if you aren't, both Wordpress and Blogger are good enough. The GSoC coding period officially starts May 27 (https://developers.google.com/open-source/gsoc/timeline). I would like to thank all the students who applied this year and everyone who submitted a patch. I would also like to thank all the mentors for helping review patches and proposals. This summer is looking to be another very productive one for SymPy, and I look forward to it! 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B6r%2BxD_7DjRR60WuAhnsJkRw6SMWOpwTsnVN0D-JrjKw%40mail.gmail.com.
Re: [sympy] New feature possibility
Looking closer, I think you might be right that the imperial system isn't there. The units are all defined, but there isn't an imperial Unitsystem that includes them all. This should be straightforward to add, The main concern I see is that there isn't a single "imperial system" and what's often called that contains many units that measure the same quantities. But the SymPy unit systems define a single unit for each quantity. So we may need to add multiple "systems" to represent the imperial units. Aaron Meurer On Thu, Apr 25, 2024 at 1:56 PM Aaron Meurer wrote: > > I believe the imperial system should already be there, but if there's > anything missing, we should fix that. > > Aaron Meurer > > On Thu, Apr 25, 2024 at 10:06 AM 'Henrique Miguel Cortes Soares' via > sympy wrote: > > > > So, should the imperial system be added? If not, what system could we add > > then? > > > > Henrique Soares > > > > On Tuesday, April 23, 2024 at 10:56:47 PM UTC+1 asme...@gmail.com wrote: > >> > >> I would say that new unit systems should be added only if they are > >> generally used and useful. General improvements to the units module > >> are always welcome. Francesco is the main maintainer of the units > >> module, so he would know more details on what needs to be done there. > >> > >> Aaron Meurer > >> > >> On Tue, Apr 23, 2024 at 3:54 PM 'Henrique Miguel Cortes Soares' via > >> sympy wrote: > >> > > >> > Hello all, > >> > > >> > I've seen in the page https://github.com/sympy/sympy/wiki/Unit-systems > >> > that two of the possible improvements for the unit systems in SymPy are > >> > to define new unit systems and improving the access to units and > >> > dimensions in a given system. > >> > Me and a friend wanted to give this feature a try, in the context of a > >> > subject of a Computer Science course we are both taking. > >> > So, I wanted to ask whether the functionality I described is something > >> > worth working on and not yet implemented. > >> > > >> > Thank you for your time. > >> > > >> > Best regards, > >> > Henrique Soares > >> > > >> > -- > >> > 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/c342d6ca-2d5a-4b5e-ac1a-d4e7488a04d7n%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/2b5adfc0-2e33-4ba9-be7f-43eb2a2093c9n%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%3D6K%2BhMFHvSJscFaj22EM3FG5RoreMXTCAPFDK8b_W4rhHQ%40mail.gmail.com.
Re: [sympy] New feature possibility
I believe the imperial system should already be there, but if there's anything missing, we should fix that. Aaron Meurer On Thu, Apr 25, 2024 at 10:06 AM 'Henrique Miguel Cortes Soares' via sympy wrote: > > So, should the imperial system be added? If not, what system could we add > then? > > Henrique Soares > > On Tuesday, April 23, 2024 at 10:56:47 PM UTC+1 asme...@gmail.com wrote: >> >> I would say that new unit systems should be added only if they are >> generally used and useful. General improvements to the units module >> are always welcome. Francesco is the main maintainer of the units >> module, so he would know more details on what needs to be done there. >> >> Aaron Meurer >> >> On Tue, Apr 23, 2024 at 3:54 PM 'Henrique Miguel Cortes Soares' via >> sympy wrote: >> > >> > Hello all, >> > >> > I've seen in the page https://github.com/sympy/sympy/wiki/Unit-systems >> > that two of the possible improvements for the unit systems in SymPy are to >> > define new unit systems and improving the access to units and dimensions >> > in a given system. >> > Me and a friend wanted to give this feature a try, in the context of a >> > subject of a Computer Science course we are both taking. >> > So, I wanted to ask whether the functionality I described is something >> > worth working on and not yet implemented. >> > >> > Thank you for your time. >> > >> > Best regards, >> > Henrique Soares >> > >> > -- >> > 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/c342d6ca-2d5a-4b5e-ac1a-d4e7488a04d7n%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/2b5adfc0-2e33-4ba9-be7f-43eb2a2093c9n%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%3D6JDbrL0DKsPA8QKmKvmPVR-J7mrD9mt%3Dgu3RDSesADA1A%40mail.gmail.com.
Re: [sympy] New feature possibility
I would say that new unit systems should be added only if they are generally used and useful. General improvements to the units module are always welcome. Francesco is the main maintainer of the units module, so he would know more details on what needs to be done there. Aaron Meurer On Tue, Apr 23, 2024 at 3:54 PM 'Henrique Miguel Cortes Soares' via sympy wrote: > > Hello all, > > I've seen in the page https://github.com/sympy/sympy/wiki/Unit-systems that > two of the possible improvements for the unit systems in SymPy are to define > new unit systems and improving the access to units and dimensions in a given > system. > Me and a friend wanted to give this feature a try, in the context of a > subject of a Computer Science course we are both taking. > So, I wanted to ask whether the functionality I described is something worth > working on and not yet implemented. > > Thank you for your time. > > Best regards, > Henrique Soares > > -- > 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/c342d6ca-2d5a-4b5e-ac1a-d4e7488a04d7n%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%3D6%2BSQTCdm0o4RsGG9rs%3DNbrJFLJwOvmTDu8akNdW1j0Xgw%40mail.gmail.com.
Re: [sympy] Seeking Assistance with SymPy Simplification for Statistical Equations
Hi. I'm not sure if the things you mentioned are implemented or not, but if they are, they would be in the sympy.stats module. If they aren't there yet, it sounds like they would be appropriate for that submodule. sympy.stats implements the algebra of random variables you are talking about. Taking ratios of random variables is supported, although there may be different things that aren't yet implemented. Also note that some of these things are more general mathematical concepts applied to statistics (like asymptotic expansions), which may already be implemented in other parts of SymPy. For example, there is support for asymptotic expansions (aseries()), although I don't know if Sterling's approximation is implemented. Aaron Meurer On Tue, Apr 23, 2024 at 1:25 PM Matthew Robinson wrote: > > Dear SymPy Developers Group, > > I hope this email finds you well. I am currently exploring the use of SymPy, > a powerful symbolic mathematics library, to simplify equations related to > mathematical statistics. Specifically, I am interested in developing a > function that can handle statistical equations by recognizing and > substituting large sample size (asymptotic) approximations. > > Here are the key aspects I’d like to address: > > Approximations: > > Sterling’s Approximation: I aim to incorporate Sterling’s Approximation for > factorials, which becomes increasingly accurate for large values. > Binomial and Poisson Distributions: I want to approximate these discrete > distributions with the Normal Distribution when dealing with large sample > sizes. > > Algebra of Random Variables: > > Additionally, I would like to explore algebraic operations involving random > variables, particularly focusing on the ratio distribution. > Ratio distribution - Wikipedia > > In summary, my goal is to input formulas that involve distributions (such as > binomial and Poisson distributions) into SymPy. The library should then > simplify these formulas using well-known large sample size approximations, > including the normal distribution and Sterling’s approximation. For example, > if the ratio of a Poisson Distribution divided by a Binomial Distribution is > input, it should output a mathematically simplified expression representing > the large sample size approximations of the Poisson distribution divided by > the large sample size approximation for the Binomial distribution. > > If there are existing methods or tools for achieving this, I would greatly > appreciate any guidance or pointers. Alternatively, if no such methods > currently exist, I am enthusiastic about contributing to the development of > this functionality. > > Thank you for your time, and I look forward to any insights or suggestions > you may have. > > Best regards, > > Matthew Robinson > > -- > 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/dde90ce8-95b4-4565-9293-e8392c029110n%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%3D6LfhZZL87H6QhYO5qMoKEzxNwyVE3ssQ1ahu%3D8UkAnhdw%40mail.gmail.com.
Re: [sympy] Re: SymPy integration with LLM (generative AI)
I believe the custom GPTs require the paid version, since they use GPT 4 and the code interpreter which are paid features only. If you have a ChatGPT subscription and you click the link I provided, it should show up in the sidebar (or you can click "explore GPTs" and search for "SymPy"). Aaron Meurer On Sat, Apr 13, 2024 at 10:31 PM wrote: > > Dear Aaron, > > Thanks! > > Does this also work with the free ChatGPT version, or only with the paid for > version? > How do I use it? Simply start my (free) ChatGPT as I do now? > > Excuse my dumb questions, but I am not the greatest computer expert ☹ > > Peter > > -Original Message- > From: sympy@googlegroups.com On Behalf Of Aaron > Meurer > Sent: Sonntag, 14. April 2024 05:30 > To: sympy@googlegroups.com > Subject: Re: [sympy] Re: SymPy integration with LLM (generative AI) > > I made a SymPy GPT for ChatGPT. Although ChatGPT will already use SymPy if > you ask it to solve a math problem. The only difference is that this has > access to the latest version of SymPy and the SymPy documentation. > > There was some discussion about using LLMs to do LaTeX parsing (currently > done by a grammar-based parser in parse_latex()) at > https://github.com/sympy/sympy/issues/26128. > > Aaron Meurer > > On Fri, Apr 12, 2024 at 12:17 AM Samith Kavishke > wrote: > > > > Are there any plans from our side for the LLM that use Sympy? > > > > On Friday, April 12, 2024 at 2:11:13 AM UTC+5:30 Francesco Bonazzi wrote: > >> > >> Their example jupyter notebook: > >> https://github.com/langchain-ai/langchain/blob/master/cookbook/llm_sy > >> mbolic_math.ipynb > >> > >> On Thursday, April 11, 2024 at 10:35:18 p.m. UTC+2 Francesco Bonazzi wrote: > >>> > >>> It looks like someone is already trying to integrate LLM with SymPy: > >>> https://api.python.langchain.com/en/latest/llm_symbolic_math/langcha > >>> in_experimental.llm_symbolic_math.base.LLMSymbolicMathChain.html > >>> > > -- > > 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/1e47b5b5-615a-45eb-8585-33470cfa483bn%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%3D6LxM29Ms-xxpZwr2%2BZ06qbeKYPE3pmhx6ajr-PM1nAhMQ%40mail.gmail.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/032101da8e24%249af957d0%24d0ec0770%24%40gmail.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%3D6J%2BmSDLTRbikVrsPQOZxLqGE9B8wowhNZp%2Bt1Sw_w1LFw%40mail.gmail.com.
Re: [sympy] Re: SymPy integration with LLM (generative AI)
I made a SymPy GPT for ChatGPT. Although ChatGPT will already use SymPy if you ask it to solve a math problem. The only difference is that this has access to the latest version of SymPy and the SymPy documentation. There was some discussion about using LLMs to do LaTeX parsing (currently done by a grammar-based parser in parse_latex()) at https://github.com/sympy/sympy/issues/26128. Aaron Meurer On Fri, Apr 12, 2024 at 12:17 AM Samith Kavishke wrote: > > Are there any plans from our side for the LLM that use Sympy? > > On Friday, April 12, 2024 at 2:11:13 AM UTC+5:30 Francesco Bonazzi wrote: >> >> Their example jupyter notebook: >> https://github.com/langchain-ai/langchain/blob/master/cookbook/llm_symbolic_math.ipynb >> >> On Thursday, April 11, 2024 at 10:35:18 p.m. UTC+2 Francesco Bonazzi wrote: >>> >>> It looks like someone is already trying to integrate LLM with SymPy: >>> https://api.python.langchain.com/en/latest/llm_symbolic_math/langchain_experimental.llm_symbolic_math.base.LLMSymbolicMathChain.html >>> > -- > 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/1e47b5b5-615a-45eb-8585-33470cfa483bn%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%3D6LxM29Ms-xxpZwr2%2BZ06qbeKYPE3pmhx6ajr-PM1nAhMQ%40mail.gmail.com.
Re: [sympy] live.sympy.org
Actually it looks like other people are seeing this as well, and I just saw it myself https://github.com/sympy/live/issues/21. Aaron Meurer On Tue, Apr 9, 2024 at 1:13 PM Aaron Meurer wrote: > > It would mean there's some issue with jupyterlite or pyodide. I > checked and it loads for me. Are there any messages in the console in > the developer tools? It's possible whatever site serves pyodide was > down when you were trying to use it so it was unable to load. Also if > you have an ad blocker try seeing if turning it off fixes it. > > Aaron Meurer > > On Tue, Apr 9, 2024 at 9:29 AM Chris Smith wrote: > > > > Lately, the live.sympy.org page never finishes loading for me. Does anyone > > know why this might be? > > > > /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+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sympy/069818fe-aff9-42e0-8aa0-2d58c9da7dcfn%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%3D6J_88jC9XgLLh2v%3DVR07-gJFEtXpNvScYF2inixbxmehQ%40mail.gmail.com.
Re: [sympy] live.sympy.org
It would mean there's some issue with jupyterlite or pyodide. I checked and it loads for me. Are there any messages in the console in the developer tools? It's possible whatever site serves pyodide was down when you were trying to use it so it was unable to load. Also if you have an ad blocker try seeing if turning it off fixes it. Aaron Meurer On Tue, Apr 9, 2024 at 9:29 AM Chris Smith wrote: > > Lately, the live.sympy.org page never finishes loading for me. Does anyone > know why this might be? > > /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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/069818fe-aff9-42e0-8aa0-2d58c9da7dcfn%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%3D6%2BVbER0NCkHRxhU%3DUATtKTsZD%3DL5pbTVXy3mcM8q-oMaQ%40mail.gmail.com.
Re: [sympy] Inquiry About GSoC Parsing Project
Did you already submit your proposal? The deadline to submit was last week, and we are unable to extend it. Aaron Meurer On Mon, Apr 1, 2024 at 6:48 AM Aquazod wrote: > > Hello, > My name is Assem Ali and I'm currently working on my proposal for the Parsing > project. > > First of all, I know that I'm really late but I had a job and I needed to > quit it to find time to work on the proposal and I couldn't quit it before > the 26th of this month. > > The Parsing project caught my interest and I read about the work that was > done at GSoC 2019 regarding the C & Fortran parsers. Here > > My question is, what is the best plan to follow? should I propose to > implement parsers for Julia and Octave, or propose to improve the current C & > Fortran parsers? > > My original plan was to create Julia & Octave parsers, and then work on > optimizing the C parser in case there is time left or in case the deadline > will be expanded. I picked the C parser specifically because it had the > lowest test coverage rate. > > My other question is if it will be so late to post my proposal here at 1st > April. > > Can potential mentors Jason Moore or Sam Brockie reply to me please. > > Thank you in advance! > > Kind Regards. > > -- > 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/3709d308-3834-4450-8881-fdcce5a6db18n%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%3D6%2BSMBbwAS_phYgLsR%2BAjq2DFTvcnzKChZG3nQex%2B1RgRQ%40mail.gmail.com.
Re: [sympy] Diffgeom needs some major rethinking
I would open an issue to discuss this, if you haven't already. These sorts of issues relating to what Add class is used to represent sums generally end up being pretty tricky and involve a lot of subtleties. Aaron Meurer On Mon, Apr 8, 2024 at 12:33 PM Davide Pittet wrote: > > I think that the main problem is that we "delegate" the sum of tensors to the > Add class, allowing to sum apples with pears; e.g. we can create an object > that is the sum of a vector and a covector like e_x + dx, when they really > belong to different spaces, without getting an error. This reflects in > cascade to the whole submodule: the sum of two tensor products is a tensor > and should be treated as such, not as a generic Add instance, because there > are constraints that are not taken into account; extending the previous > example, we cannot sum TensorProduct(e_x, dx) with TensorProduct(dx, e_:x). > > Then, we have to implement the associativity of the tensor product and the > distributivity of the tensor product wrt the sum. > > Once this is fixed we have to put a constraint on the number and the type of > the arguments of the __call__ method and this should solve the problems > pointed out on GitHub. > > Davide Pittet > > Il giorno lunedì 8 aprile 2024 alle 10:06:46 UTC+2 asme...@gmail.com ha > scritto: >> >> Your contributions are definitely welcome, although it would be a good >> idea to first lay out exactly what changes you want to make, either >> here or on an issue. If any of the changes are controversial, or would >> break the current API, we should iron them out before you potentially >> waste a lot of time coding them. >> >> If there's any changes you want to make that aren't potentially >> controversial, like bugfixes, you don't need to open issues for them >> first. >> >> Aaron Meurer >> >> On Sun, Apr 7, 2024 at 2:02 PM Davide Pittet wrote: >> > >> > Hello everyone, >> > >> > following up the discussion on GitHub related to the WedgeProduct bug, I >> > started exploring the code around the implementation of wedge and tensor >> > products. I think there are deep problems with the way tensor products >> > (but not only) are implemented in the diffgeom submodule. >> > >> > I would like to address these issues, but it would be my first >> > contribution and I do not think it will be a simple task. I have a good >> > knowledge of the theoretical field as my MSc thesis applied differential >> > geometry to particle physics and I would like to help, but I would surely >> > appreciate some guidance with the code, primarely on the direction we want >> > to follow. >> > >> > Davide Pittet >> > >> > >> > -- >> > 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/f480cb78-3741-484a-bc32-1535cbab177bn%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/5ea6ca99-0cc9-4190-8817-c8ba5da1a9a8n%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%3D6L5fEWMYe%2BG_rRNpUFRsxjZ3UVsxpdCC%3Dze_BWUCsiRoA%40mail.gmail.com.
Re: [sympy] Diffgeom needs some major rethinking
Your contributions are definitely welcome, although it would be a good idea to first lay out exactly what changes you want to make, either here or on an issue. If any of the changes are controversial, or would break the current API, we should iron them out before you potentially waste a lot of time coding them. If there's any changes you want to make that aren't potentially controversial, like bugfixes, you don't need to open issues for them first. Aaron Meurer On Sun, Apr 7, 2024 at 2:02 PM Davide Pittet wrote: > > Hello everyone, > > following up the discussion on GitHub related to the WedgeProduct bug, I > started exploring the code around the implementation of wedge and tensor > products. I think there are deep problems with the way tensor products (but > not only) are implemented in the diffgeom submodule. > > I would like to address these issues, but it would be my first contribution > and I do not think it will be a simple task. I have a good knowledge of the > theoretical field as my MSc thesis applied differential geometry to particle > physics and I would like to help, but I would surely appreciate some guidance > with the code, primarely on the direction we want to follow. > > Davide Pittet > > > -- > 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/f480cb78-3741-484a-bc32-1535cbab177bn%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%3D6KCBy4LEN%2BT3DrmrVkk2dsydXLpxQo9RY5eW1t_HX_EvA%40mail.gmail.com.
Re: [sympy] Re: GSOC: Benchmark Project Questions
I've updated the ideas page with a link to an issue that discusses some ways that benchmarks on GitHub Actions could be improved. Aaron Meurer On Mon, Apr 1, 2024 at 2:35 AM Sam Lubelsky wrote: > Yeah, I see no good reason for why the benchmark results show the Master > vs previous release. That information does not seem relevant to the PR and > I would bet it's causing people to ignore the benchmark when it is actually > saying something useful. > > I think that Master vs previous release section should be moved to a > separate program which is run everytime there is a new release, because > this information still seems useful just to see the general performance > trend and to see if there are any big regressions. > > It would be nice if this could be run automatically. Does this type of > thing seem doable in Github actions? > On Monday, April 1, 2024 at 3:11:18 AM UTC-5 asme...@gmail.com wrote: > >> I agree with this. The usability of the current benchmarking output >> needs to be improved a lot. Ideally, it should work in a way that >> people are actually alerted to real performance regressions, and not >> bothered if there aren't any performance regressions. >> >> Another issue is that the PR benchmarks comments also list the changes >> in master since the previous release. This is almost always completely >> irrelevant to the PR in question, so we should remove or demote this >> information. >> >> If the benchmarking system was robust enough, there would never be a >> regression in master, because regressions in PRs would be disallowed, >> the same as test failures in PRs are currently disallowed. >> >> Aaron Meurer >> >> On Mon, Apr 1, 2024 at 1:13 AM Jason Moore wrote: >> > >> > This is my opinion, not sure if it is shared, but I don't think anyone >> uses the information that is displayed on the pull request. This isn't >> because the information isn't accurate or informative, but because of how >> and when it is presented. I haven't looked at all pull requests, of course, >> but I don't recall one where someone noticed the slowdown and it led to >> change in the PR. It has probably happened, but it happens rarely. >> > >> > The current system shows two things: timing differences in the current >> commit vs last release and current commit vs master. The current commit vs >> last release is most helpful for making the new release, but can be >> confusing for the PR because it contains slowdowns/speedups from more than >> your own PR work. The current commit vs master should show the PR author >> that they have made some good or bad change wrt to the benchmarks. That's >> all we really need to tell them (besides which benchmarks are slower and by >> how much). It does this, but it is easy to just not read it. >> > >> > The old way was that some of us monitored the asv generated websites >> and then opened issues about slowdowns and commented on the old PRs. This >> isn't automated but it did lead to specific comments on PRs that PR authors >> then were very aware of. >> > >> > Jason >> > moorepants.info >> > +01 530-601-9791 <(530)%20601-9791> >> > >> > >> > On Mon, Apr 1, 2024 at 2:57 AM Sam Lubelsky wrote: >> >> >> >> Is there any specific problems with the current pull request >> benchmarking system that this project should address? >> >> On Sunday, March 31, 2024 at 1:41:58 PM UTC-5 moore...@gmail.com >> wrote: >> >>> >> >>> HI Sam, >> >>> >> >>> I think that idea could be a bit outdated. I'm not sure if the text >> was updated for this year. If it was, then someone else can speak up about >> it. >> >>> >> >>> I think that improving our sympy_benchmarks repository with more and >> better benchmarks and making the benchmarking system that we have setup >> with each pull request to sympy more useful is a better focus. I'm not sure >> we can run the benchmarks on a dedicated machine unless we spend some sympy >> funds to do that. >> >>> >> >>> We basically want to know if a pull request slows down sympy and make >> sure the pull request authors are warned about this in a clear way before >> merging. In the past it was helpful to see the historical speed of various >> SymPy benchmarks (here is an example I used to maintain: >> https://www.moorepants.info/misc/sympy-asv/) but that does require a >> dedicated machine so that benchmarks are comparable over time. >> >>> >> >>> Anothe
Re: [sympy] Re: GSOC: Benchmark Project Questions
I agree with this. The usability of the current benchmarking output needs to be improved a lot. Ideally, it should work in a way that people are actually alerted to real performance regressions, and not bothered if there aren't any performance regressions. Another issue is that the PR benchmarks comments also list the changes in master since the previous release. This is almost always completely irrelevant to the PR in question, so we should remove or demote this information. If the benchmarking system was robust enough, there would never be a regression in master, because regressions in PRs would be disallowed, the same as test failures in PRs are currently disallowed. Aaron Meurer On Mon, Apr 1, 2024 at 1:13 AM Jason Moore wrote: > > This is my opinion, not sure if it is shared, but I don't think anyone uses > the information that is displayed on the pull request. This isn't because the > information isn't accurate or informative, but because of how and when it is > presented. I haven't looked at all pull requests, of course, but I don't > recall one where someone noticed the slowdown and it led to change in the PR. > It has probably happened, but it happens rarely. > > The current system shows two things: timing differences in the current commit > vs last release and current commit vs master. The current commit vs last > release is most helpful for making the new release, but can be confusing for > the PR because it contains slowdowns/speedups from more than your own PR > work. The current commit vs master should show the PR author that they have > made some good or bad change wrt to the benchmarks. That's all we really need > to tell them (besides which benchmarks are slower and by how much). It does > this, but it is easy to just not read it. > > The old way was that some of us monitored the asv generated websites and then > opened issues about slowdowns and commented on the old PRs. This isn't > automated but it did lead to specific comments on PRs that PR authors then > were very aware of. > > Jason > moorepants.info > +01 530-601-9791 > > > On Mon, Apr 1, 2024 at 2:57 AM Sam Lubelsky wrote: >> >> Is there any specific problems with the current pull request benchmarking >> system that this project should address? >> On Sunday, March 31, 2024 at 1:41:58 PM UTC-5 moore...@gmail.com wrote: >>> >>> HI Sam, >>> >>> I think that idea could be a bit outdated. I'm not sure if the text was >>> updated for this year. If it was, then someone else can speak up about it. >>> >>> I think that improving our sympy_benchmarks repository with more and better >>> benchmarks and making the benchmarking system that we have setup with each >>> pull request to sympy more useful is a better focus. I'm not sure we can >>> run the benchmarks on a dedicated machine unless we spend some sympy funds >>> to do that. >>> >>> We basically want to know if a pull request slows down sympy and make sure >>> the pull request authors are warned about this in a clear way before >>> merging. In the past it was helpful to see the historical speed of various >>> SymPy benchmarks (here is an example I used to maintain: >>> https://www.moorepants.info/misc/sympy-asv/) but that does require a >>> dedicated machine so that benchmarks are comparable over time. >>> >>> Another thing I thought would be useful in the past, is to run benchmarks >>> as part of the release process (or just before) so we can see if the >>> upcoming release is slower than the prior release. >>> >>> Jason >>> moorepants.info >>> +01 530-601-9791 >>> >>> >>> On Sun, Mar 31, 2024 at 8:13 PM Sam Lubelsky wrote: >>>> >>>> Sorry if it is kinda intimidating that I put so many questions. I really >>>> just need the answer to the first one to make my proposal. I know I am a >>>> little late to GSOC, but I've really enjoyed getting to know the Sympy >>>> community a little bit in this past week and I am committed to putting >>>> together a good project proposal. >>>> Thanks, >>>> Sam. >>>> On Friday, March 29, 2024 at 4:37:55 PM UTC-5 Sam Lubelsky wrote: >>>>> >>>>> I put an introduction a few emails down, but to recap my name is Sam, I'm >>>>> a college freshman, and I'm very interested in working on improving >>>>> Sympy's benchmarking services over this summer through GSOC. >>>>> >>>>> While going through the project description I had a few questions: >>>>> &g
Re: [sympy] GSOC: Benchmark Project Questions
On Fri, Mar 29, 2024 at 3:38 PM Sam Lubelsky wrote: > > I put an introduction a few emails down, but to recap my name is Sam, I'm a > college freshman, and I'm very interested in working on improving Sympy's > benchmarking services over this summer through GSOC. > > While going through the project description I had a few questions: > > 1) "It also needs an automated system to run them" > What exactly is meant by this. Right now, github actions seems to be already > automatically running benchmarking after each pr. Why is this not an > automated system? Is the meaning of automated system something that runs > weekly/monthly on the whole repo, generates a benchmark report and sends it > somewhere? asv has two modes. A mode to compare a commit against another commit, and a mode to run the benchmarks along a sequence of commits in history to generate a graph and find regressions. The pull requests run the first mode, but it's harder to run the second mode because it takes a lot of time, and also you have to have a system that has stable performance or else you will just get false positives. > > 2) How to go about hosting benchmarks on a remote, dedicated machine? What's > the general idea of how to go about this in open source project. Is there > money available to pay some cloud provider to host it? Free hosting > options?(doesn't seem reliable enough for benchmarking). We do have some money that could be used for this. The real question is figuring out if is is feasible, and something that would be maintainable. > > 3) SymEngine vs SymPy. I'm not familiar with SymEngine. Approximately how > similar are SymPy and SymEngine? Is making the project also work with > SymEngine more of a quick fix(≈1-2 weeks) or should I expect it to take > longer? I wouldn't worry about SymEngine. We should remove that section from the ideas page. > > 4) Current Benchmark Suite > "We currently have a benchmarking suite and run the benchmarks on GitHub > Actions, but this is limited and is often buggy" > > What are the limitation(s) to github actions that this project should address? > If we don't use github actions, is there another way to make it run after > every PR like we have now? > > 5) Where are the tests run now? > On the project description it says " the results are run and hosted Ad Hoc", > which I assumes means whatever computer is running all the other PR tests. > Just want to make sure this is correct. For the asv runs that run against every commit in history, those are indeed currently run ad hoc, meaning someone has to run them on their own computer and upload the results. 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/ed7520ea-3fee-4185-b087-0a3a38dd763fn%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%3D6%2Bw3%2BjrEWcUVqcCEhSfwjWJhzQ%3DHG3egQKR1N_G2zU%3DpQ%40mail.gmail.com.
Re: [sympy] Re: Seeking Feedback on Floating Point Expression Optimization Project
We would generally only accept one proposal for each project, unless the proposals are distinct enough that they can be done independently. Aaron Meurer On Thu, Mar 28, 2024 at 4:43 PM Tommaso Vaccari wrote: > > Thank you Aaron, I'll add it to the proposal, I have a question, more people > can work on a single idea? > > Il giorno giovedì 28 marzo 2024 alle 23:42:01 UTC+1 asme...@gmail.com ha > scritto: >> >> Remember that there is a requirement to make a pull request to SymPy. >> You should list any pull requests you have made to SymPy in your >> proposal. >> >> Aaron Meurer >> >> On Thu, Mar 28, 2024 at 1:43 AM Tommaso Vaccari wrote: >> > >> > Hello everyone, >> > Here's my proposal, I would like to seek some feedbacks about it. >> > Thanks! >> > >> > Il giorno lunedì 18 marzo 2024 alle 18:52:22 UTC+1 Tommaso Vaccari ha >> > scritto: >> >> >> >> Thanks Aaron for the feedback! >> >> >> >> Il giorno lunedì 18 marzo 2024 alle 18:51:02 UTC+1 asme...@gmail.com ha >> >> scritto: >> >>> >> >>> You can put it on the wiki if you like to get public feedback. If >> >>> there isn't a page for it, it just means no one has created it yet. >> >>> >> >>> Aaron Meurer >> >>> >> >>> On Mon, Mar 18, 2024 at 11:13 AM Tommaso Vaccari >> >>> wrote: >> >>> > >> >>> > Ah ok thanks, I was asking because I have seen that in the previous >> >>> > years there was a place in the simpy wiki. >> >>> > Thank you, >> >>> > Best Regards >> >>> > >> >>> > Il giorno lunedì 18 marzo 2024 alle 18:12:07 UTC+1 >> >>> > samithkar...@gmail.com ha scritto: >> >>> >> >> >>> >> you must publish in the GSOC 24 official page >> >>> >> >> >>> >> On Monday, March 18, 2024 at 9:09:17 PM UTC+5:30 Tommaso Vaccari >> >>> >> wrote: >> >>> >>> >> >>> >>> Ok thanks, where I can publish my proposal ? I think it's missing a >> >>> >>> page in the wiki for gsoc24 proposal. >> >>> >>> Let me know! >> >>> >>> >> >>> >>> Il giorno lunedì 18 marzo 2024 alle 12:25:39 UTC+1 >> >>> >>> samithkar...@gmail.com ha scritto: >> >>> >>>> >> >>> >>>> Most of the ideas that still in the page need more work to do as I >> >>> >>>> assume, >> >>> >>>> >> >>> >>>> On Monday, March 18, 2024 at 4:53:55 PM UTC+5:30 Samith Kavishke >> >>> >>>> wrote: >> >>> >>>>> >> >>> >>>>> This is the idea page: >> >>> >>>>> https://github.com/sympy/sympy/wiki/GSoC-Ideas >> >>> >>>>> Refer this thread for more info: >> >>> >>>>> https://groups.google.com/u/0/g/sympy/c/pwr87uHzXIc/m/Eoi8U9u7AAAJ >> >>> >>>>> >> >>> >>>>> On Monday, March 18, 2024 at 2:06:20 PM UTC+5:30 Tommaso Vaccari >> >>> >>>>> wrote: >> >>> >>>>>> >> >>> >>>>>> Hey everyone, >> >>> >>>>>> >> >>> >>>>>> I hope you're all doing well. I wanted to ask if anyone else is >> >>> >>>>>> having trouble finding the wiki section for GSoC proposals for >> >>> >>>>>> 2024. >> >>> >>>>>> >> >>> >>>>>> I've been searching around but can't seem to locate it. Am I the >> >>> >>>>>> only one facing this issue, or am I missing something obvious? >> >>> >>>>>> >> >>> >>>>>> Any help or pointers would be greatly appreciated. Thanks ! >> >>> >>>>>> >> >>> >>>>>> Il giorno lunedì 18 marzo 2024 alle 09:23:09 UTC+1 Tommaso >> >>> >>>>>> Vaccari ha scritto: >> >>> >>>>>> >> >>> >>>>>> Hello everyone, >> >>> >>>>>> >> >>> >>>>>> I hope this me
Re: [sympy] Re: allowing Eq as recognized subs argument?
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 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/69b60c58-7d97-41ae-a94e-487e38219c06n%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%3D6LSL0cFW70QMdfek%3DgeuP2eAExP2%3D9K%3D%3DteyRK8RJ8GPQ%40mail.gmail.com.
Re: [sympy] allowing Eq as recognized subs argument?
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 On Wed, Mar 27, 2024 at 5:36 PM Chris Smith 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/f38dee22-4249-4c3f-ac77-22a34a2f7e23n%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%3D6JgLvrewGLPRW45EBH85yozKpCz75ibD%2B%3DDEo6HVBj8CA%40mail.gmail.com.
Re: [sympy] Re: Seeking Feedback on Floating Point Expression Optimization Project
Remember that there is a requirement to make a pull request to SymPy. You should list any pull requests you have made to SymPy in your proposal. Aaron Meurer On Thu, Mar 28, 2024 at 1:43 AM Tommaso Vaccari wrote: > > Hello everyone, > Here's my proposal, I would like to seek some feedbacks about it. > Thanks! > > Il giorno lunedì 18 marzo 2024 alle 18:52:22 UTC+1 Tommaso Vaccari ha scritto: >> >> Thanks Aaron for the feedback! >> >> Il giorno lunedì 18 marzo 2024 alle 18:51:02 UTC+1 asme...@gmail.com ha >> scritto: >>> >>> You can put it on the wiki if you like to get public feedback. If >>> there isn't a page for it, it just means no one has created it yet. >>> >>> Aaron Meurer >>> >>> On Mon, Mar 18, 2024 at 11:13 AM Tommaso Vaccari wrote: >>> > >>> > Ah ok thanks, I was asking because I have seen that in the previous years >>> > there was a place in the simpy wiki. >>> > Thank you, >>> > Best Regards >>> > >>> > Il giorno lunedì 18 marzo 2024 alle 18:12:07 UTC+1 samithkar...@gmail.com >>> > ha scritto: >>> >> >>> >> you must publish in the GSOC 24 official page >>> >> >>> >> On Monday, March 18, 2024 at 9:09:17 PM UTC+5:30 Tommaso Vaccari wrote: >>> >>> >>> >>> Ok thanks, where I can publish my proposal ? I think it's missing a >>> >>> page in the wiki for gsoc24 proposal. >>> >>> Let me know! >>> >>> >>> >>> Il giorno lunedì 18 marzo 2024 alle 12:25:39 UTC+1 >>> >>> samithkar...@gmail.com ha scritto: >>> >>>> >>> >>>> Most of the ideas that still in the page need more work to do as I >>> >>>> assume, >>> >>>> >>> >>>> On Monday, March 18, 2024 at 4:53:55 PM UTC+5:30 Samith Kavishke wrote: >>> >>>>> >>> >>>>> This is the idea page: https://github.com/sympy/sympy/wiki/GSoC-Ideas >>> >>>>> Refer this thread for more info: >>> >>>>> https://groups.google.com/u/0/g/sympy/c/pwr87uHzXIc/m/Eoi8U9u7AAAJ >>> >>>>> >>> >>>>> On Monday, March 18, 2024 at 2:06:20 PM UTC+5:30 Tommaso Vaccari >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hey everyone, >>> >>>>>> >>> >>>>>> I hope you're all doing well. I wanted to ask if anyone else is >>> >>>>>> having trouble finding the wiki section for GSoC proposals for 2024. >>> >>>>>> >>> >>>>>> I've been searching around but can't seem to locate it. Am I the >>> >>>>>> only one facing this issue, or am I missing something obvious? >>> >>>>>> >>> >>>>>> Any help or pointers would be greatly appreciated. Thanks ! >>> >>>>>> >>> >>>>>> Il giorno lunedì 18 marzo 2024 alle 09:23:09 UTC+1 Tommaso Vaccari >>> >>>>>> ha scritto: >>> >>>>>> >>> >>>>>> Hello everyone, >>> >>>>>> >>> >>>>>> I hope this message finds you well. My name is Tommaso, and I'm >>> >>>>>> currently a second-year student pursuing a degree in computer >>> >>>>>> engineering. I'm reaching out to the community and potential mentors >>> >>>>>> to discuss a project idea I'm passionate about: optimizing >>> >>>>>> floating-point expressions. >>> >>>>>> >>> >>>>>> I have a strong interest in mathematics and a keen enthusiasm for >>> >>>>>> optimizing processes. I would like to develop techniques for >>> >>>>>> optimizing floating-point expressions, with a focus on improving >>> >>>>>> both accuracy and speed. >>> >>>>>> >>> >>>>>> I would greatly appreciate any feedback, insights, or guidance from >>> >>>>>> the community and potential mentors. >>> >>>>>> >>> >>>>>> Thank you for considering my proposal, and I look forward to your >>> >>>>>> feedback and suggestions. >>> >>>>>> >>> >>>>>> Best regards, Tommaso >>> > >>> > -- >>> > 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/ff1f5edf-7e6c-4163-a77a-531fdfaa9fb5n%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/74e7ddab-6f50-40b1-8e40-846b94262379n%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%3D6Jk3q3BdWbgUEDRpgakrxPDhc%2B14_F9E3HQcMVxA_64uQ%40mail.gmail.com.
Re: [sympy] Inquiry about the number of contributors SymPy can accept this year
I'm assuming you're referring to GSoC. The number of people we accept each year depends on many factors, including how many people apply, the variety and quality of applications we receive, and the number of people who are able to mentor the applications we receive. If you look at past years, we've accepted ~5 people each year and I would guess this year will likely be around the same number. You can look at the reports on the wiki to see the actual numbers for each year. Aaron Meurer On Tue, Mar 26, 2024 at 7:13 AM Xianrui “Oliver” Teng wrote: > > Dear mentors, > > I hope this email finds you well. > > I am interested in participating in this year's SymPy program, and I have a > question regarding the number of contributors that SymPy can accept. Could > you please provide some information on the maximum number of contributors > that can be accepted? > > Thank you for your time and assistance. > > Best regards, > Xianrui Oliver Teng > > > > > > > > -- > 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/ea349169-1161-464e-b4d6-84d830896f10n%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%3D6LVtPtUHk9BdUmUOC9QHELDUi7bUDFmZ_Q_K6dohBEfbg%40mail.gmail.com.
Re: [sympy] Re: Seeking Feedback on Floating Point Expression Optimization Project
You can put it on the wiki if you like to get public feedback. If there isn't a page for it, it just means no one has created it yet. Aaron Meurer On Mon, Mar 18, 2024 at 11:13 AM Tommaso Vaccari wrote: > > Ah ok thanks, I was asking because I have seen that in the previous years > there was a place in the simpy wiki. > Thank you, > Best Regards > > Il giorno lunedì 18 marzo 2024 alle 18:12:07 UTC+1 samithkar...@gmail.com ha > scritto: >> >> you must publish in the GSOC 24 official page >> >> On Monday, March 18, 2024 at 9:09:17 PM UTC+5:30 Tommaso Vaccari wrote: >>> >>> Ok thanks, where I can publish my proposal ? I think it's missing a page in >>> the wiki for gsoc24 proposal. >>> Let me know! >>> >>> Il giorno lunedì 18 marzo 2024 alle 12:25:39 UTC+1 samithkar...@gmail.com >>> ha scritto: >>>> >>>> Most of the ideas that still in the page need more work to do as I assume, >>>> >>>> On Monday, March 18, 2024 at 4:53:55 PM UTC+5:30 Samith Kavishke wrote: >>>>> >>>>> This is the idea page: https://github.com/sympy/sympy/wiki/GSoC-Ideas >>>>> Refer this thread for more info: >>>>> https://groups.google.com/u/0/g/sympy/c/pwr87uHzXIc/m/Eoi8U9u7AAAJ >>>>> >>>>> On Monday, March 18, 2024 at 2:06:20 PM UTC+5:30 Tommaso Vaccari wrote: >>>>>> >>>>>> Hey everyone, >>>>>> >>>>>> I hope you're all doing well. I wanted to ask if anyone else is having >>>>>> trouble finding the wiki section for GSoC proposals for 2024. >>>>>> >>>>>> I've been searching around but can't seem to locate it. Am I the only >>>>>> one facing this issue, or am I missing something obvious? >>>>>> >>>>>> Any help or pointers would be greatly appreciated. Thanks ! >>>>>> >>>>>> Il giorno lunedì 18 marzo 2024 alle 09:23:09 UTC+1 Tommaso Vaccari ha >>>>>> scritto: >>>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I hope this message finds you well. My name is Tommaso, and I'm >>>>>> currently a second-year student pursuing a degree in computer >>>>>> engineering. I'm reaching out to the community and potential mentors to >>>>>> discuss a project idea I'm passionate about: optimizing floating-point >>>>>> expressions. >>>>>> >>>>>> I have a strong interest in mathematics and a keen enthusiasm for >>>>>> optimizing processes. I would like to develop techniques for optimizing >>>>>> floating-point expressions, with a focus on improving both accuracy and >>>>>> speed. >>>>>> >>>>>> I would greatly appreciate any feedback, insights, or guidance from the >>>>>> community and potential mentors. >>>>>> >>>>>> Thank you for considering my proposal, and I look forward to your >>>>>> feedback and suggestions. >>>>>> >>>>>> Best regards, Tommaso > > -- > 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/ff1f5edf-7e6c-4163-a77a-531fdfaa9fb5n%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%3D6JgBq9LJGiv70zpdeEcW84f5qdw%3DDvhredTE74kX2X5OQ%40mail.gmail.com.
Re: [sympy] Re: Enhancing the flexibility of MatchPy
As far as we can tell, SymPy is the only thing that uses MatchPy, outside of the specific research software from that research group that it was developed for. If making MatchPy more SymPy specific eases the development burden, we should do that, especially if we are going to fork it anyway. I think the core of it does need to remain independent of SymPy's types, especially if we want to try to write a Rust backend. Aaron Meurer On Tue, Mar 12, 2024 at 6:29 PM Samith Kavishke wrote: > > Hi, > If we are maintianing matchpy as our own repository, Is it okay for us to > make the matchpy elements in more integrated way to sympy, or still we need > to support the every functionalities that matchpy gave earlier. As an > example, issue 69 suggests to create neutral or identity element, but for it > to make a proper meaning in XML domain we need to make it as default value, > likewise there are more things that we take into consideration if we need to > support this for other types as well. Because somethings that supports in > current version of matchpy would break when we add those functionalities. > > > > On Monday, March 11, 2024 at 6:07:27 PM UTC+5:30 Francesco Bonazzi wrote: >> >> The main issue is that we don't control the MatchPy repository. It's owned >> by a research center. Unfortunately they don't appear to be active anymore, >> so I guess we'll probably have to fork the project. >> >> Regarding SymPy, our aim is to improve the integration between MatchPy and >> SymPy in order to use MatchPy's pattern matching and replacement algorithms >> inside SymPy. So the main use case is the implementation of algorithms in >> SymPy using MatchPy's algorithm. >> >> For example, can we implement an equation solver using MatchPy? There is a >> basic example in the documentation of "matchpy_connector". >> >> Can MatchPy be modified and made more flexible so that we can avoid using >> all evil tricks used in "matchpy_connector" to get it to work? >> >> Can MatchPy be rewritten in Rust for more efficiency? >> >> On Sunday, March 10, 2024 at 11:11:43 a.m. UTC+1 samithkar...@gmail.com >> wrote: >>> >>> Hi Francesco, >>> Thank you for the reply. How should I progress in this project? I have >>> several issues encountered when I am going through the matchpy repository, >>> where would I raise those issues. >>> >>> On Wednesday, March 6, 2024 at 3:49:09 PM UTC+5:30 Francesco Bonazzi wrote: >>>> >>>> The idea that I have in mind requires forking the MatchPy library. If we >>>> can find a way to modify the tree-traversal algorithms in MatchPy in order >>>> not to depend on type checks, we will make MatchPy's integration into >>>> SymPy much easier. >>>> >>>> On Wednesday, March 6, 2024 at 1:17:17 a.m. UTC+1 samithkar...@gmail.com >>>> wrote: >>>>> >>>>> Hi, >>>>> Even though, I have engaged with few chats I thought to introduce me >>>>> first. I am Samith Karunathilake, a third year undergraduate from >>>>> University of Moratuwa, Sri Lanka. I have an interest on contributing for >>>>> the Sympy for GSOC 2024. As for now I have baisc understanding about few >>>>> areas, sympy.series, matchpy_connector and parse_mathematica. >>>>> >>>>> Here are the few methods that I identified about matchpy restructuring. >>>>> Since, at the moment it uses an Expression node as the root node and we >>>>> can redefine it and introduce some methods to check whether it is a >>>>> instance of wildcard or an operation. >>>>> Through that we can change the tree traversal method without bothering >>>>> about the implementation of the Wild Card and Operations. >>>>> If Francesco Bonazzi, or any potential mentor can give their idea on this >>>>> thread, it would be much helpful. I will post more about this project as >>>>> a reply for this thread. >>>>> >>>>> Thanks in advance for your collaboration. >>>>> Samith Karunathilake. > > -- > 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/e25976d9-682f-4379-9001-961ab21be4a7n%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%3D6%2B2HsH78r1Vup-FVzpSW8iTU922VKp6rPkpD2%3DfvYSykw%40mail.gmail.com.
Re: [sympy] In memory of Kalevi Suominen
The passing of Kalevi Suominen truly a loss for the SymPy community. I had the honor of meeting Kalevi face to face once on a video call many years ago, but other than that, like everyone else, I primarily interacted with him online. Kalevi was always known in the SymPy community as the mathematics expert. As a retired professor of mathematics, his knowledge greatly assisted the development of some of the deep mathematical areas in SymPy, such as the polynomials and group theory modules. He was always available to give advice whenever I was unsure of some part of SymPy that was outside of my domain of expertise. I was always impressed by the breadth of his mathematical knowledge, as well as his skill as a Python programmer, a combination which can be rare to see. Yet despite being easily the most mathematically adept member of the community, he never lorded it over us, but always approached every interaction with kindness and humility. He considered himself to be an equal and as both a teacher and a learner. He can be a model for the sort of contributor and community member we should all strive to be, and our project was truly lucky to have him. I found some of the papers and books he wrote on Google Scholar https://scholar.google.com/scholar?hl=en_sdt=0%2C32=Kalevi+Suominen= and MathSciNet (but this requires a subscription to view, which I do not have) https://mathscinet.ams.org/mathscinet/MRAuthorID/209375. He never mentioned this work, and it seems like most of it deals with technical mathematical areas which are not directly relevant to SymPy. I'll close on the following paragraphs from Kalevi himself, which I found in an old private email from 2018, on why he contributed to SymPy: > Being retired, I consider myself lucky as I can work with open code > on my own time with no pressure. It seems that many pensioners find > themselves a hobby. This is what suits me. > > I originally came across SymPy when searching for a mathematical > library for experimenting with some algorithms. It was (almost) > "love at first sight". It does not matter that the language, Python, > is not the most efficient one. It is easy to work with, and very much > readable. Readability is important to me as it helps in finding > errors. (That is what I had been doing for a great part of my > professional life.) It was also of importance to me that functions > would look familiar, sin(x), not Sin[x]. Instead of simply using > SymPy I finally found myself wanting to improve the library, > but that is another story. Aaron Meurer On Sun, Mar 10, 2024 at 10:31 AM Oscar Benjamin wrote: > > Hi all SymPy community, > > It is with great sadness that I bring the news that Kalevi Suominen > (@jksuom on GitHub) passed away on the 4th of March. Kalevi's son > Risto passed on this news to me and some others by email yesterday. > > I never met Kalevi in person but we had many conversations online over > many years. Kalevi was an outstanding SymPy contributor and was > involved with the project long before me and so there are others here > who have known him much longer than I have. Kalevi guided many SymPy > contributors and supervised many GSOC students over many years. > Looking in the git history his earliest commit was from almost exactly > 10 years ago. > > Personally I learnt a huge amount from Kalevi and I am very grateful > for the time he took to teach me and others and to guide the project > generally. Kalevi's expertise in many areas of Mathematics and across > the full depth of many parts of the SymPy codebase was unmatched > within the community. > > Interacting through GitHub I guess that many of us did not realise > that Kalevi's health was in decline. He continued to be involved > including most recently reviewing a pull request just 6 weeks ago. A > few weeks ago he sent me some files with what he was most recently > working on but was no longer able to finish. I will try to complete > that work and submit it as Kalevi's final pull request. > > Kalevi's passing is a huge loss to SymPy but I don't want to dwell on > that. Instead I invite those of us who have known Kalevi to share > their thoughts and memories here. > > Oscar > > -- > 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/CAHVvXxTRWVQp_N_0%3DNnf-yBJwSu373sw-NB7UKuZCks2HTHGaA%40mail.gmail.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%3D6%2Bn9hbbk2OsPqUfoJUUmrSbB1Znrx_42wgexghtYXMF6w%40mail.gmail.com.
Re: [sympy] Addin sympy to SPEC 0?
On Sun, Mar 10, 2024 at 8:48 AM Oscar Benjamin wrote: > > Hi Anton, > > What difference does it make to you in practice whether or not SymPy > is listed in SPEC 0? > > SymPy does not really support old versions with maintenance releases > so it does not really have a "support cycle" in the sense that SPEC 0 > seems to describe. There can be a bugfix release shortly after a > feature release to fix some obvious regressions but that is basically > it. This fact alone would be worth notating in that document. It's not always obvious to what degree different packages support older versions. Aaron Meurer > > SymPy itself broadly tries to have wide version support for other > packages like numpy just because without listing them as hard > dependencies there is no way to indicate which versions sympy is > compatible with. There is no way to put version constraints on > optional dependencies in pip/PyPI land. > > Oscar > > On Sun, 10 Mar 2024 at 14:24, Anton Akhmerov wrote: > > > > Hi all, > > > > There is now SPEC 0, a SciPy-community-wide standard for versions of > > different packages that developers should aim supporting, see > > https://scientific-python.org/specs/spec-/ > > > > I believe Sympy is the biggest package missing from SPEC 0, and I've asked > > the maintainers of SPEC 0 what is the best way to proceed > > (https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov). > > They appear to welcome the idea and recommended to reach out via this > > mailing list. > > > > So here's the question I'd like to know (as someone authoring software that > > depends on Sympy): would Sympy like to join SPEC 0? > > > > Thank you for your consideration, > > Anton > > > > -- > > 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/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%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/CAHVvXxS%2Bh1foa1G3dfKA58Osp%3D%3DZ9W69gjRygjzphkcstqTarw%40mail.gmail.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%3D6%2BmFxyTd_a89Vv15P1pFeW1w5qh5dCeHVyQizg-fTLy9Q%40mail.gmail.com.
Re: [sympy] GSOC Application: Creating a Wolfram Mathematica Interpreter with Sympy
Mathics has a license that makes it incompatible with sympy. But regardless, I think we should find a way to make RUBI work without having to build a full Wolfram language interpreter. Aaron Meurer On Sat, Mar 2, 2024 at 10:10 AM Samith Kavishke wrote: > > Is that means this project is not going to be continued? > > On Saturday, March 25, 2023 at 2:12:27 AM UTC+5:30 Oscar wrote: >> >> There already is mathics which is a Wolfram Language interpreter that >> is based on SymPy. It would seem a bit odd to create a new one. >> >> On Fri, 24 Mar 2023 at 19:48, Aaron Meurer wrote: >> > >> > I believe the primary function of this project is to make it easier to >> > integrate the RUBI integrator into SymPy. The project shouldn't >> > actually depend on Wolfram Mathematica or any proprietary code at all. >> > The best place to start here would be to look at RUBI and see what the >> > status of it is. You can see the status of the SymPy RUBI port at >> > https://github.com/sympy/rubi, and by searching for "rubi" in the >> > SymPy issue tracker. >> > >> > Aaron Meurer >> > >> > On Fri, Mar 24, 2023 at 10:39 AM Dawn Magnet wrote: >> > > >> > > >> > > Dear Sympy Community, >> > > >> > > My name is Zutong Wen, and I am a student from China Agricultural >> > > University. I am writing to express my interest in participating in the >> > > Google Summer of Code (GSOC) program with the Sympy project. >> > > Specifically, I am interested in the "Create a Wolfram Mathematica >> > > interpreter" subproject. >> > > >> > > I have always been fascinated by the power and versatility of >> > > mathematical software, and I believe that the Sympy project is an >> > > excellent platform for me to develop my skills and contribute to the >> > > open-source community. As a student of mathematics and computer science, >> > > I have a strong foundation in both fields, and I am confident that I >> > > have the knowledge and skills necessary to tackle the challenges of this >> > > project. >> > > >> > > The "Create a Wolfram Mathematica interpreter" subproject is >> > > particularly appealing to me because it involves integrating two >> > > powerful mathematical software systems. Wolfram Mathematica is a widely >> > > used and highly respected software system for symbolic and numerical >> > > computation, and Sympy is a powerful Python library for symbolic >> > > mathematics. By creating an interpreter for Wolfram Mathematica in >> > > Sympy, we can bring together the strengths of both systems and provide >> > > users with a more comprehensive and flexible tool for mathematical >> > > computation. >> > > >> > > As a potential GSOC participant, I am committed to working closely with >> > > the Sympy community to develop a high-quality and useful interpreter for >> > > Wolfram Mathematica. I am familiar with the Python programming language >> > > and have experience with various Python libraries, including Sympy. I >> > > have also worked on several programming projects in the past, including >> > > a web-based backend API and some commandline tools such as Tetris. And >> > > I'm also familiar with C++ and Rust. >> > > >> > > In addition to my technical skills, I am also a dedicated and >> > > hardworking individual. I understand the importance of time management >> > > and communication in a collaborative project, and I am confident that I >> > > can meet the expectations of the Sympy community and the GSOC program. >> > > >> > > In conclusion, I am excited about the opportunity to contribute to the >> > > Sympy project and to work on the "Create a Wolfram Mathematica >> > > interpreter" subproject. I believe that this project has the potential >> > > to benefit a wide range of users and to advance the field of >> > > mathematical software. Thank you for considering my application, and I >> > > look forward to hearing from you soon. >> > > >> > > Sincerely, >> > > >> > > Zutong Wen >> > > >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "sympy" group. >> > > To unsubscribe from this group an
Re: [sympy] Re: Need GSoC mentors and help updating ideas page
Yes, that idea is new this year. Aaron Meurer On Sun, Mar 3, 2024 at 2:08 AM Samith Kavishke wrote: > > If that so, what are the ideas that we can really contribute? I hope > "Enhancing the flexibility of MatchPy" is still needed. > > On Sunday, March 3, 2024 at 2:31:26 PM UTC+5:30 asme...@gmail.com wrote: >> >> I've Cced Francesco Bonazzi about the Wolfram Interpreter idea. It >> relates to the RUBI project, but I don't know whether it is something >> that is still needed for it. Personally I would prefer to avoid >> creating a Wolfram Language interpreter if possible. >> >> Aaron Meurer >> >> On Sat, Mar 2, 2024 at 11:31 PM Samith Kavishke >> wrote: >> > >> > Is this concluded, does that mean all the current projects that can be >> > seen in the Ideas page are available for students to apply? >> > (specifically regarding the Wolfram Interpreter) >> > >> > On Tuesday, February 13, 2024 at 3:25:46 AM UTC+5:30 asme...@gmail.com >> > wrote: >> >> >> >> Another thing I forgot to mention: new this year is small projects, >> >> which are 90 hour projects, in addition to the 175 and 350 hour >> >> projects. Right now, none of the ideas specify 90 hours, but we should >> >> probably add some smaller projects to the list. >> >> >> >> Aaron Meurer >> >> >> >> On Wed, Jan 24, 2024 at 11:49 AM Aaron Meurer wrote: >> >> > >> >> > It is time again for us to apply to Google to be a GSoC mentoring org. >> >> > >> >> > I need help updating the GSoC ideas page. >> >> > https://github.com/sympy/sympy/wiki/GSoC-Ideas. If any ideas there are >> >> > already completed, please remove or update them. Also please add new >> >> > ideas, although you may want to discuss them here first if you aren't >> >> > sure about them. >> >> > >> >> > Secondly, we need to update the potential mentors page. >> >> > https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. If >> >> > you were a student in the past I encourage you to mentor. Please add >> >> > your name there if you can mentor this year. If you can't mentor but >> >> > want to help review applications, just let me know. >> >> > >> >> > If you are someone who is interested in applying to SymPy for GSoC, >> >> > start here. >> >> > https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions >> >> > >> >> > 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/cf6c7cf3-82f4-435d-abd0-5b2d5e81b5dcn%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/c95486ee-0523-4101-be26-b3d4a5d059b1n%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%3D6LBqooQ6xcPPNkCO3aFdbLCHyZmivCiDY_tPUnXsHMVvw%40mail.gmail.com.
Re: [sympy] Re: Need GSoC mentors and help updating ideas page
I've Cced Francesco Bonazzi about the Wolfram Interpreter idea. It relates to the RUBI project, but I don't know whether it is something that is still needed for it. Personally I would prefer to avoid creating a Wolfram Language interpreter if possible. Aaron Meurer On Sat, Mar 2, 2024 at 11:31 PM Samith Kavishke wrote: > > Is this concluded, does that mean all the current projects that can be seen > in the Ideas page are available for students to apply? > (specifically regarding the Wolfram Interpreter) > > On Tuesday, February 13, 2024 at 3:25:46 AM UTC+5:30 asme...@gmail.com wrote: >> >> Another thing I forgot to mention: new this year is small projects, >> which are 90 hour projects, in addition to the 175 and 350 hour >> projects. Right now, none of the ideas specify 90 hours, but we should >> probably add some smaller projects to the list. >> >> Aaron Meurer >> >> On Wed, Jan 24, 2024 at 11:49 AM Aaron Meurer wrote: >> > >> > It is time again for us to apply to Google to be a GSoC mentoring org. >> > >> > I need help updating the GSoC ideas page. >> > https://github.com/sympy/sympy/wiki/GSoC-Ideas. If any ideas there are >> > already completed, please remove or update them. Also please add new >> > ideas, although you may want to discuss them here first if you aren't >> > sure about them. >> > >> > Secondly, we need to update the potential mentors page. >> > https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. If >> > you were a student in the past I encourage you to mentor. Please add >> > your name there if you can mentor this year. If you can't mentor but >> > want to help review applications, just let me know. >> > >> > If you are someone who is interested in applying to SymPy for GSoC, >> > start here. https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions >> > >> > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/cf6c7cf3-82f4-435d-abd0-5b2d5e81b5dcn%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%3D6LZ_%3DZSGr2HudWcpjsFVvX_zgaLYV5AQKwrRm%2BZAS2UGg%40mail.gmail.com.
Re: [sympy] Re: How to avoid distributing a constant factor after differentiation?
On Wed, Feb 28, 2024 at 2:23 PM Chris Smith wrote: > > > I might not be following > > Say a current test is `assert ans == 2*x + 2*y`. That isn't going to pass > when distribution is off. I was imagining that there was some way you could > write a decorator that would be able to convert that to `assert f(ans) == > f(2*x+2*y)` where `f` is something like `factor_terms`. I'm not sure there is > a way to write such a decorator, however. But if you instead write 'assert ans == 2*(x + y)' it should work, because the right-hand side will either remain unevaluated or distribute, according to whatever the distribute flag is set to. > > What we can do, incrementally, is: pick a test function; decorate it with a > function that runs the tests in a `distribute(False)` context; fix failing > tests. Then repeat that process until > > a) all functions are thusly decorated and > b) all routines that are identified as failing (because they made an > assumption about distribution) are fixed. > > Make distribution default to False. > > Is that what you had in mind? Yes, except the decorator has to run the test twice, once with distribute(False) and once with distribute(True) (because the current behavior also has to continue to work and be tested). This is how the _both_exp_pow decorator works https://github.com/sympy/sympy/blob/ab2fb691a90457b65bbf2a7c091c8265be9cee09/sympy/testing/pytest.py#L291. Aaron Meurer > > /c > On Monday, February 26, 2024 at 3:32:16 PM UTC-6 Aaron Meurer wrote: >> >> On Mon, Feb 26, 2024 at 1:54 PM Chris Smith wrote: >> > >> > It seems that the tests could be marked as passing for both forms to see >> > where tests fail because a routine is broken. Broken routines could be >> > fixed (as necessary) so they are not assuming distribution. Would the >> > decorator need to be taken off routines once everything was passing? >> >> Ideally once we got everything working we would flip the flag default, >> and then we could delete the decorator. >> >> The one issue is that it could be more complicated if we want to do >> some sort of deprecation, though I'm not sure if we can. If there's a >> lot of library code that breaks when you disable automatic >> distribution then there will be a lot of user code that breaks as >> well. >> >> > >> > Except for a single Add from which only a Rational can be subtracted, I >> > suspect that detecting a passing form for a given result would be more >> > tricky than one might expect. >> >> I might not be following exactly what you are saying here, but >> wouldn't something like >> >> assert f() == 2*(x + y) >> >> work regardless of whether distribution is enabled or not? It will >> either happen to both sides of the equation or to neither side. >> >> Aaron Meurer >> >> > >> > /c >> > On Thursday, February 22, 2024 at 7:57:05 PM UTC-6 Aaron Meurer wrote: >> >> >> >> I don't think we need to try to check the code for everywhere a >> >> multiplication happens. We can rely on the tests sufficiently covering >> >> the code. >> >> >> >> So what you would do is set the global distribute flag to False, run >> >> the tests, and see what fails. Then as you fix certain tests that are >> >> broken, add a @both_distribute decorator to the test to make sure it >> >> always passes with distribution both off and on. >> >> >> >> The downside of this incremental approach is that functions would need >> >> to work both with and without automatic distribution. In many cases, >> >> though, this is something that should happen anyway, as even currently >> >> automatic distribution is not guaranteed. For example, it doesn't >> >> happen with 2*x*(x + y). And it's not uncommon to have un-distributed >> >> expressions because functions like factor() create them. >> >> >> >> Aaron Meurer >> >> >> >> On Thu, Feb 22, 2024 at 2:15 PM Chris Smith wrote: >> >> > >> >> > In order to solve the issue incrementally, it seems like we would need >> >> > to identify every line where multiplication is used (on arguments that >> >> > could possibly be Number and Add) and have them call `Mul` with a >> >> > `distribute=True` option. >> >> > >> >> > How to identify where the multiplication lines are located? Set a booby >> >> > trap in the `flatten` routine that requires the `distribute` flag to be >> >>
Re: [sympy] Re: How to avoid distributing a constant factor after differentiation?
On Mon, Feb 26, 2024 at 1:54 PM Chris Smith wrote: > > It seems that the tests could be marked as passing for both forms to see > where tests fail because a routine is broken. Broken routines could be fixed > (as necessary) so they are not assuming distribution. Would the decorator > need to be taken off routines once everything was passing? Ideally once we got everything working we would flip the flag default, and then we could delete the decorator. The one issue is that it could be more complicated if we want to do some sort of deprecation, though I'm not sure if we can. If there's a lot of library code that breaks when you disable automatic distribution then there will be a lot of user code that breaks as well. > > Except for a single Add from which only a Rational can be subtracted, I > suspect that detecting a passing form for a given result would be more tricky > than one might expect. I might not be following exactly what you are saying here, but wouldn't something like assert f() == 2*(x + y) work regardless of whether distribution is enabled or not? It will either happen to both sides of the equation or to neither side. Aaron Meurer > > /c > On Thursday, February 22, 2024 at 7:57:05 PM UTC-6 Aaron Meurer wrote: >> >> I don't think we need to try to check the code for everywhere a >> multiplication happens. We can rely on the tests sufficiently covering >> the code. >> >> So what you would do is set the global distribute flag to False, run >> the tests, and see what fails. Then as you fix certain tests that are >> broken, add a @both_distribute decorator to the test to make sure it >> always passes with distribution both off and on. >> >> The downside of this incremental approach is that functions would need >> to work both with and without automatic distribution. In many cases, >> though, this is something that should happen anyway, as even currently >> automatic distribution is not guaranteed. For example, it doesn't >> happen with 2*x*(x + y). And it's not uncommon to have un-distributed >> expressions because functions like factor() create them. >> >> Aaron Meurer >> >> On Thu, Feb 22, 2024 at 2:15 PM Chris Smith wrote: >> > >> > In order to solve the issue incrementally, it seems like we would need to >> > identify every line where multiplication is used (on arguments that could >> > possibly be Number and Add) and have them call `Mul` with a >> > `distribute=True` option. >> > >> > How to identify where the multiplication lines are located? Set a booby >> > trap in the `flatten` routine that requires the `distribute` flag to be >> > set. Repeatedly run the tests to identify locations and add the >> > `distribute=False`. At that point all tests are unchanged and passing. >> > >> > Now, one by one, change a distribute flag to True, run tests, fix tests or >> > code to handle the non-distribution since either could cause a failure: >> > the former because something previously distributed would no longer be so, >> > and the latter because expectations for the algorithm were not met and the >> > algorithm (and maybe the test) need modification. >> > >> > /c >> > >> > On Wednesday, February 21, 2024 at 6:07:35 PM UTC-6 Aaron Meurer wrote: >> >> >> >> On Wed, Feb 21, 2024 at 4:09 PM Chris Smith wrote: >> >> > >> >> > > There is a distribute() context manager >> >> > >> >> > I had forgotten about that, thanks for the reminder! >> >> >> >> We probably shouldn't advertise it too widely. Like I said, it's not >> >> as bad as the evaluate() context manager, but it has some of the same >> >> fundamental issues. >> >> >> >> The main point of it is that there is a global flag in the core to >> >> turn the distribution off, which should make it easier to remove it if >> >> anyone ever wants to put in that work. For instance we could make a >> >> decorator for the tests that makes sure a specific test passes with >> >> automatic distribution turned off (similar to this one >> >> https://github.com/sympy/sympy/blob/ae13ee38f54aa9c8944ef7d103dda778d2a39dbd/sympy/testing/pytest.py#L291). >> >> That way we can start fixing the code incrementally, instead of taking >> >> an "all or nothing" approach, which has failed in the past. >> >> >> >> Aaron Meurer >> >> >> >> > >> >> > /c >> >> > >> >> > On Wednesday, Februar
Re: [sympy] Re: How to avoid distributing a constant factor after differentiation?
I don't think we need to try to check the code for everywhere a multiplication happens. We can rely on the tests sufficiently covering the code. So what you would do is set the global distribute flag to False, run the tests, and see what fails. Then as you fix certain tests that are broken, add a @both_distribute decorator to the test to make sure it always passes with distribution both off and on. The downside of this incremental approach is that functions would need to work both with and without automatic distribution. In many cases, though, this is something that should happen anyway, as even currently automatic distribution is not guaranteed. For example, it doesn't happen with 2*x*(x + y). And it's not uncommon to have un-distributed expressions because functions like factor() create them. Aaron Meurer On Thu, Feb 22, 2024 at 2:15 PM Chris Smith wrote: > > In order to solve the issue incrementally, it seems like we would need to > identify every line where multiplication is used (on arguments that could > possibly be Number and Add) and have them call `Mul` with a `distribute=True` > option. > > How to identify where the multiplication lines are located? Set a booby trap > in the `flatten` routine that requires the `distribute` flag to be set. > Repeatedly run the tests to identify locations and add the > `distribute=False`. At that point all tests are unchanged and passing. > > Now, one by one, change a distribute flag to True, run tests, fix tests or > code to handle the non-distribution since either could cause a failure: the > former because something previously distributed would no longer be so, and > the latter because expectations for the algorithm were not met and the > algorithm (and maybe the test) need modification. > > /c > > On Wednesday, February 21, 2024 at 6:07:35 PM UTC-6 Aaron Meurer wrote: >> >> On Wed, Feb 21, 2024 at 4:09 PM Chris Smith wrote: >> > >> > > There is a distribute() context manager >> > >> > I had forgotten about that, thanks for the reminder! >> >> We probably shouldn't advertise it too widely. Like I said, it's not >> as bad as the evaluate() context manager, but it has some of the same >> fundamental issues. >> >> The main point of it is that there is a global flag in the core to >> turn the distribution off, which should make it easier to remove it if >> anyone ever wants to put in that work. For instance we could make a >> decorator for the tests that makes sure a specific test passes with >> automatic distribution turned off (similar to this one >> https://github.com/sympy/sympy/blob/ae13ee38f54aa9c8944ef7d103dda778d2a39dbd/sympy/testing/pytest.py#L291). >> That way we can start fixing the code incrementally, instead of taking >> an "all or nothing" approach, which has failed in the past. >> >> Aaron Meurer >> >> > >> > /c >> > >> > On Wednesday, February 21, 2024 at 4:39:22 PM UTC-6 Aaron Meurer wrote: >> >> >> >> There is a distribute() context manager which lets you disable >> >> automatic distribution, though it's not pretty: >> >> >> >> >>> from sympy.core.parameters import distribute >> >> >>> with distribute(False): >> >> ... print(expr.diff(t)) >> >> 3*a*(t - t0)**2 + 2*b*(t - t0) >> >> >> >> While this is less dangerous than the similar evaluate() context >> >> manager, it is possible this could break something if you put too much >> >> under the context. >> >> >> >> As Chris said, we do want to eventually remove this automatic >> >> behavior, but it hasn't been easy to do as a lot of things depend on >> >> it currently. Rearranging things after the fact as Chris suggests is >> >> probably the better solution. There's really no guarantees about what >> >> the form of an expression from diff() will look like. >> >> >> >> Aaron Meurer >> >> >> >> On Sun, Feb 18, 2024 at 12:10 PM Chris Smith wrote: >> >> > >> >> > Autodistribution of Number into an Add is how SymPy works and there is >> >> > no flag for differentiation (or for many functions) that would prevent >> >> > it. Simply pass the expression to `factor_terms` to get it cleaned up. >> >> > (But that will extract a factor of `t-t0`, too, which you might not >> >> > want so you could use `Add(*[factor_terms(i) for i in >> >> > expr.diff(t).args])` in this case.) >> >> > >> >> > Some day autodistribution will
Re: [sympy] Re: How to avoid distributing a constant factor after differentiation?
On Wed, Feb 21, 2024 at 4:09 PM Chris Smith wrote:
>
> > There is a distribute() context manager
>
> I had forgotten about that, thanks for the reminder!
We probably shouldn't advertise it too widely. Like I said, it's not
as bad as the evaluate() context manager, but it has some of the same
fundamental issues.
The main point of it is that there is a global flag in the core to
turn the distribution off, which should make it easier to remove it if
anyone ever wants to put in that work. For instance we could make a
decorator for the tests that makes sure a specific test passes with
automatic distribution turned off (similar to this one
https://github.com/sympy/sympy/blob/ae13ee38f54aa9c8944ef7d103dda778d2a39dbd/sympy/testing/pytest.py#L291).
That way we can start fixing the code incrementally, instead of taking
an "all or nothing" approach, which has failed in the past.
Aaron Meurer
>
> /c
>
> On Wednesday, February 21, 2024 at 4:39:22 PM UTC-6 Aaron Meurer wrote:
>>
>> There is a distribute() context manager which lets you disable
>> automatic distribution, though it's not pretty:
>>
>> >>> from sympy.core.parameters import distribute
>> >>> with distribute(False):
>> ... print(expr.diff(t))
>> 3*a*(t - t0)**2 + 2*b*(t - t0)
>>
>> While this is less dangerous than the similar evaluate() context
>> manager, it is possible this could break something if you put too much
>> under the context.
>>
>> As Chris said, we do want to eventually remove this automatic
>> behavior, but it hasn't been easy to do as a lot of things depend on
>> it currently. Rearranging things after the fact as Chris suggests is
>> probably the better solution. There's really no guarantees about what
>> the form of an expression from diff() will look like.
>>
>> Aaron Meurer
>>
>> On Sun, Feb 18, 2024 at 12:10 PM Chris Smith wrote:
>> >
>> > Autodistribution of Number into an Add is how SymPy works and there is no
>> > flag for differentiation (or for many functions) that would prevent it.
>> > Simply pass the expression to `factor_terms` to get it cleaned up. (But
>> > that will extract a factor of `t-t0`, too, which you might not want so you
>> > could use `Add(*[factor_terms(i) for i in expr.diff(t).args])` in this
>> > case.)
>> >
>> > Some day autodistribution will go away and I expect that we will then ask
>> > how to get constants to distribute into simple expressions.
>> >
>> > /c
>> >
>> > On Sunday, February 18, 2024 at 4:52:12 AM UTC-6 matthia...@gmail.com
>> > wrote:
>> >>
>> >> Hi all.
>> >>
>> >> I have a simple expression:
>> >>
>> >> >>> import sympy as sp
>> >> >>> a, b, t, t0 = sp.symbols('a b t t0')
>> >> >>> expr = a*(t - t0)**3 + b*(t - t0)**2
>> >>
>> >> And I would like to differentiate it with respect to t:
>> >>
>> >> >>> expr.diff(t)
>> >> 3*a*(t - t0)**2 + b*(2*t - 2*t0)
>> >>
>> >> Why is the constant "2" distributed in the second term?
>> >> It seems like an additional step that SymPy does, which doesn't really
>> >> "improve" the situation in this case.
>> >> Maybe there is a more general advantage that's just not visible in
>> >> this simple case?
>> >> But if that is so, would it be possible to tell SymPy to skip the
>> >> distributing?
>> >>
>> >> To be clear, this is the result I was expecting:
>> >>
>> >> >>> expr.diff(t)
>> >> 3*a*(t - t0)**2 + 2*b*(t - t0)
>> >>
>> >> For context, this question came up in a slightly more complicated
>> >> situation:
>> >> https://github.com/AudioSceneDescriptionFormat/splines/issues/31
>> >>
>> >> cheers,
>> >> 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/389f5dd9-1498-455a-b6cc-ffbbff89a9d7n%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/7a4673b7-4c4e-4101-a4e5-9056847d000en%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%3D6KEApm0Uj3Vrj_TC4HaF8acDPVUBQPu%3D4PL%3D-uYELtXTg%40mail.gmail.com.
Re: [sympy] Re: How to avoid distributing a constant factor after differentiation?
There is a distribute() context manager which lets you disable
automatic distribution, though it's not pretty:
>>> from sympy.core.parameters import distribute
>>> with distribute(False):
... print(expr.diff(t))
3*a*(t - t0)**2 + 2*b*(t - t0)
While this is less dangerous than the similar evaluate() context
manager, it is possible this could break something if you put too much
under the context.
As Chris said, we do want to eventually remove this automatic
behavior, but it hasn't been easy to do as a lot of things depend on
it currently. Rearranging things after the fact as Chris suggests is
probably the better solution. There's really no guarantees about what
the form of an expression from diff() will look like.
Aaron Meurer
On Sun, Feb 18, 2024 at 12:10 PM Chris Smith wrote:
>
> Autodistribution of Number into an Add is how SymPy works and there is no
> flag for differentiation (or for many functions) that would prevent it.
> Simply pass the expression to `factor_terms` to get it cleaned up. (But that
> will extract a factor of `t-t0`, too, which you might not want so you could
> use `Add(*[factor_terms(i) for i in expr.diff(t).args])` in this case.)
>
> Some day autodistribution will go away and I expect that we will then ask how
> to get constants to distribute into simple expressions.
>
> /c
>
> On Sunday, February 18, 2024 at 4:52:12 AM UTC-6 matthia...@gmail.com wrote:
>>
>> Hi all.
>>
>> I have a simple expression:
>>
>> >>> import sympy as sp
>> >>> a, b, t, t0 = sp.symbols('a b t t0')
>> >>> expr = a*(t - t0)**3 + b*(t - t0)**2
>>
>> And I would like to differentiate it with respect to t:
>>
>> >>> expr.diff(t)
>> 3*a*(t - t0)**2 + b*(2*t - 2*t0)
>>
>> Why is the constant "2" distributed in the second term?
>> It seems like an additional step that SymPy does, which doesn't really
>> "improve" the situation in this case.
>> Maybe there is a more general advantage that's just not visible in
>> this simple case?
>> But if that is so, would it be possible to tell SymPy to skip the
>> distributing?
>>
>> To be clear, this is the result I was expecting:
>>
>> >>> expr.diff(t)
>> 3*a*(t - t0)**2 + 2*b*(t - t0)
>>
>> For context, this question came up in a slightly more complicated
>> situation: https://github.com/AudioSceneDescriptionFormat/splines/issues/31
>>
>> cheers,
>> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/389f5dd9-1498-455a-b6cc-ffbbff89a9d7n%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%3D6%2BfoChaZwhJRiOOp_HTRcbj%2B7EMm99u-xz-NgTuM59-eA%40mail.gmail.com.
Re: [sympy] Use of flake8 seperately when we have ruff enabled
I think maybe there were some checks that were done by flake8 that weren't yet implemented by ruff. I don't know if that's still the case. I agree we could probably just use ruff if it is doing everything flake8 does. Aaron Meurer On Thu, Feb 15, 2024 at 6:50 AM Shishir Kushwaha wrote: > > I was going through the pyproject.toml file and learned that we are using > ruff which is also a test or part of a test that runs on github CLI . In the > documentation as well as github CLI we are using ruff which can be used to > replace flake8 from what I have read . > In that case why do we use both of them when the work could just be done with > ruff . > > _ > Shishir Kushwaha > > -- > 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/33ecc4b9-d500-4233-ad3b-2ff5df3e56dbn%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%3D6%2BiOuTGxM9HPJxgQc8-D4bqnbt1iMkO6F%3DqCUofpB0kCw%40mail.gmail.com.
Re: [sympy] Reverse order of polynomial before printing
The order argument to the printers is definitely under-documented.
This has been an issue for some time.
Aaron Meurer
On Tue, Feb 13, 2024 at 10:41 AM Thomas Ligon wrote:
>
> Thanks! This does exaclty what I wanted.
> Now, for the question, should I be embarassed for not finding it myself. This
> is in fact documented in
> https://docs.sympy.org/latest/modules/printing.html
> It looks like all of my searching was for reversing the order of an
> expression, which is hard, but reversing the order or printing is easy.
>
> On Tuesday, February 13, 2024 at 12:46:43 AM UTC+1 asme...@gmail.com wrote:
>>
>> The order in printing can be controlled with the order flag to the
>> printer. Using latex(expr, order='rev-lex') will cause polynomials to
>> print in reverse lexicographic order, which is the order you want.
>>
>> It's not a good idea to use evaluate=False to try to control printing
>> behavior, as this can break other things. Instead, you should use the
>> existing flags in the printer in question, or customize the printer
>> with a subclass if the built-in behavior doesn't meet your needs.
>>
>> Aaron Meurer
>>
>> On Sat, Feb 10, 2024 at 1:58 PM Thomas Ligon wrote:
>> >
>> > I am trying to reverse the order of an expression before printing it for
>> > my documentation, and I want ascending order, but SymPy always gives me
>> > descending order. All of the expressions are polynomials, specifically
>> > partial sums of power series. Since, according to Internet searches, there
>> > is no easy way to do this, I have tried a number of things, including
>> > manipulating the expression tree. The original expression is always Add of
>> > a tuple, and each tuple is a rational number and x**n. When I loop through
>> > the expression and Add the components, I always get the same order. The
>> > elegant solution would be to reverse the tuple and Add it all at once, but
>> > that is deprecated and gives me a tuple instead of a sum.
>> >
>> > Here is some sample code, a test program that demonstrates the problem.
>> >
>> > from sympy import symbols, Rational, Add, latex, Eq
>> > x = symbols('x')
>> > lhs = symbols('X')
>> > rhs = Rational(3)/Rational(4)*x**3 + Rational(2)/Rational(5)*x**2 +
>> > Rational(1)/Rational(4)*x
>> > X1 = rhs.args
>> > #X2 = X1[::-1] # Why don't I need this? My debugger shows the expression
>> > and the tuple in reverse order.
>> > X2 = X1
>> > # Try the expected order of Add. This produces a sum, but with an extra
>> > set of parantheses, and not the desired order.
>> > X3 = X2[0]
>> > X2R = X2[1:len(X2)]
>> > for indT in range(0, len(X2R)):
>> > termT = X2R[indT]
>> > X3 = Add(X3, termT, evaluate=False)
>> > # Try the other order of Add. This looks the same as X3.
>> > X4 = X2[0]
>> > for indT in range(0, len(X2R)):
>> > termT = X2R[indT]
>> > X4 = Add(termT, X4, evaluate=False)
>> > # Try single step. This is deprecated, gives the correct order, but
>> > returns a tuple instead of a sum.
>> > #X2 = X1[::-1] # Why don't I need this?
>> > X2 = X1
>> > X5 = Add(X2, evaluate=False)
>> >
>> > print(latex(Eq(lhs, rhs))) # original order
>> > print(latex(Eq(lhs, X3))) # still original order
>> > print(latex(Eq(lhs, X4))) # still original order
>> > print(latex(Eq(lhs, X5))) # desired order, but tuple instead of sum
>> >
>> > --
>> > 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/166a5149-26b2-47f7-9956-943b9d379d92n%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/92fc1ab4-81bb-491c-a538-b5422e81e9dbn%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%3D6KUTA0p2knb%2B345ONe9dk5fxpg0E8e%3DkpKMgZEt6_WV%3DQ%40mail.gmail.com.
Re: [sympy] Reverse order of polynomial before printing
The order in printing can be controlled with the order flag to the
printer. Using latex(expr, order='rev-lex') will cause polynomials to
print in reverse lexicographic order, which is the order you want.
It's not a good idea to use evaluate=False to try to control printing
behavior, as this can break other things. Instead, you should use the
existing flags in the printer in question, or customize the printer
with a subclass if the built-in behavior doesn't meet your needs.
Aaron Meurer
On Sat, Feb 10, 2024 at 1:58 PM Thomas Ligon wrote:
>
> I am trying to reverse the order of an expression before printing it for my
> documentation, and I want ascending order, but SymPy always gives me
> descending order. All of the expressions are polynomials, specifically
> partial sums of power series. Since, according to Internet searches, there is
> no easy way to do this, I have tried a number of things, including
> manipulating the expression tree. The original expression is always Add of a
> tuple, and each tuple is a rational number and x**n. When I loop through the
> expression and Add the components, I always get the same order. The elegant
> solution would be to reverse the tuple and Add it all at once, but that is
> deprecated and gives me a tuple instead of a sum.
>
> Here is some sample code, a test program that demonstrates the problem.
>
> from sympy import symbols, Rational, Add, latex, Eq
> x = symbols('x')
> lhs = symbols('X')
> rhs = Rational(3)/Rational(4)*x**3 + Rational(2)/Rational(5)*x**2 +
> Rational(1)/Rational(4)*x
> X1 = rhs.args
> #X2 = X1[::-1] # Why don't I need this? My debugger shows the expression and
> the tuple in reverse order.
> X2 = X1
> # Try the expected order of Add. This produces a sum, but with an extra set
> of parantheses, and not the desired order.
> X3 = X2[0]
> X2R = X2[1:len(X2)]
> for indT in range(0, len(X2R)):
> termT = X2R[indT]
> X3 = Add(X3, termT, evaluate=False)
> # Try the other order of Add. This looks the same as X3.
> X4 = X2[0]
> for indT in range(0, len(X2R)):
> termT = X2R[indT]
> X4 = Add(termT, X4, evaluate=False)
> # Try single step. This is deprecated, gives the correct order, but returns a
> tuple instead of a sum.
> #X2 = X1[::-1] # Why don't I need this?
> X2 = X1
> X5 = Add(X2, evaluate=False)
>
> print(latex(Eq(lhs, rhs))) # original order
> print(latex(Eq(lhs, X3))) # still original order
> print(latex(Eq(lhs, X4))) # still original order
> print(latex(Eq(lhs, X5))) # desired order, but tuple instead of sum
>
> --
> 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/166a5149-26b2-47f7-9956-943b9d379d92n%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%3D6%2BR-9-nUYv8_L76t9idRy54MA8kYJY433-ujENf%2B8Ct8w%40mail.gmail.com.
Re: [sympy] Code Quality test failing on github even though local tests doesn't give any error
The slotscheck command should be ran like python -m slotscheck --exclude-modules "(sympy.parsing.autolev._antlr.*|sympy.parsing.latex._antlr.*|sympy.galgebra|sympy.plotting.pygletplot.*)" sympy (see https://github.com/sympy/sympy/blob/680fb21363e1ea685d6fc868d15069d80ac0c97f/.github/workflows/runtests.yml#L47C14-L47C165). Otherwise it will try to import several submodules which should not be imported. Really we should move this to a configuration file so that it will always work correctly if you just call "slotscheck". See https://slotscheck.readthedocs.io/en/latest/configuration.html#configuration-file. This should be a straightforward thing to change if you want to make a PR. Aaron Meurer On Fri, Feb 9, 2024 at 3:51 PM Shishir Kushwaha wrote: > > I am getting the same errors on the master branch as well . Has it got > something to do with the dependencies ? I set up my repo again after clearing > previous stuff so I might have forgotten something ? > > > > On Saturday 10 February 2024 at 04:18:48 UTC+5:30 Shishir Kushwaha wrote: >> >> Can you also please tell me why it is failing as well . The errors I get are >> mostly some warning about deprecation or failing to import some modules but >> I have made no changes to any of the related files and synced with the >> upstream repository about an hour ago . >> >> The output I get on running the test locally : >> >> The sympy.utilities.runtests submodule is deprecated. Use >> sympy.testing.runtests instead. >> >> See >> https://docs.sympy.org/latest/explanation/active-deprecations.html#deprecated-sympy-utilities-submodules >> for details. >> >> This has been deprecated since SymPy version 1.6. It >> will be removed in a future version of SymPy. >> >> return _bootstrap._gcd_import(name[level:], package, level) >> ERROR: Failed to import 'sympy.galgebra'. >> ERROR: Failed to import 'sympy.parsing.autolev._antlr.autolevlexer'. >> ERROR: Failed to import 'sympy.parsing.autolev._antlr.autolevlistener'. >> ERROR: Failed to import 'sympy.parsing.autolev._antlr.autolevparser'. >> ERROR: Failed to import 'sympy.parsing.latex._antlr.latexlexer'. >> ERROR: Failed to import 'sympy.parsing.latex._antlr.latexparser'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.color_scheme'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.managed_window'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_controller'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_controller'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_curve'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_mode'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_mode_base'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_modes'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_rotation'.ERROR: >> Failed to import 'sympy.plotting.pygletplot.plot_surface'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.plot_window'. >> ERROR: Failed to import 'sympy.plotting.pygletplot.util'. >> Oh no, found some problems! >> Scanned 1501 module(s), 1923 class(es). >> On Saturday 10 February 2024 at 03:33:43 UTC+5:30 asme...@gmail.com wrote: >>> >>> The slotscheck test is run on CI but isn't included in the normal >>> local tests run. If you want to run it locally you will need to >>> install slotscheck and run 'slotscheck sympy/' >>> >>> Aaron Meurer >>> >>> On Fri, Feb 9, 2024 at 2:02 PM Shishir Kushwaha >>> wrote: >>> > >>> > I am getting an error in >>> > Check for incorrect use of "__slots__" using slotcheck . >>> > Any Idea why ? >>> > >>> > -- >>> > 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/9ca60097-eb28-436e-9c29-79eae93edf83n%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/cf63fea5-46f0-49cc-a0aa-aa9a0b2b9c75n%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%3D6LOa%3DYWMSsoDEkBc1Q7Vhx7%2BR8J%2BNLCzuYMX_CmfgZ%2BbQ%40mail.gmail.com.
[sympy] Re: Need GSoC mentors and help updating ideas page
Another thing I forgot to mention: new this year is small projects, which are 90 hour projects, in addition to the 175 and 350 hour projects. Right now, none of the ideas specify 90 hours, but we should probably add some smaller projects to the list. Aaron Meurer On Wed, Jan 24, 2024 at 11:49 AM Aaron Meurer wrote: > > It is time again for us to apply to Google to be a GSoC mentoring org. > > I need help updating the GSoC ideas page. > https://github.com/sympy/sympy/wiki/GSoC-Ideas. If any ideas there are > already completed, please remove or update them. Also please add new > ideas, although you may want to discuss them here first if you aren't > sure about them. > > Secondly, we need to update the potential mentors page. > https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. If > you were a student in the past I encourage you to mentor. Please add > your name there if you can mentor this year. If you can't mentor but > want to help review applications, just let me know. > > If you are someone who is interested in applying to SymPy for GSoC, > start here. https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions > > 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Lz%3DZV4nN%2BKe3Co4Zo7CA2j7t3pEnpEJrLw%2BEvNrYO%2Bug%40mail.gmail.com.
Re: [sympy] What's the Meaning of S and X while running tests .
If you run the tests with the -v flag you will get more information. Tests are skipped for various reasons, usually because some optional dependency is not installed https://docs.sympy.org/latest/contributing/dependencies.html. Unless you are working on a submodule that uses one of these dependencies, you can ignore those tests. xfail means that a test is expected to fail. These are tests that are added for behavior that doesn't work yet. You can ignore these. Aaron Meurer On Fri, Feb 9, 2024 at 10:28 AM Shishir Kushwaha wrote: > > S and X have been coming on a few test when I ran tests , they did even when > I was setting sympy up , why is it happening . I tried reinstalling thee > dependancies and checked the versions required . Althoough no test is failing > with a F but I'm still getting 'skipped' and 'xfailed tests'. > > -- > 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/d500691b-1b97-4b7e-8b2f-fb5f74341958n%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%3D6%2B1dDexj2CnEA9oC17r7RhJn5wD2h5O%3DeJK7S02WUr2_g%40mail.gmail.com.
Re: [sympy] Code Quality test failing on github even though local tests doesn't give any error
The slotscheck test is run on CI but isn't included in the normal local tests run. If you want to run it locally you will need to install slotscheck and run 'slotscheck sympy/' Aaron Meurer On Fri, Feb 9, 2024 at 2:02 PM Shishir Kushwaha wrote: > > I am getting an error in > Check for incorrect use of "__slots__" using slotcheck . > Any Idea why ? > > -- > 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/9ca60097-eb28-436e-9c29-79eae93edf83n%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%3D6JGy0hrKkyY8%3DhsbqX1cdf-3zMSKQLCLByjpH1TPWaWMA%40mail.gmail.com.
Re: [sympy] Reviewing PRs and old SymPy issues
I'll also add that if you want to, we'll give triage permissions to just about anyone so they can go through and label old issues (triage permissions give you permissions to label issues). Just ask me or Oscar. Aaron Meurer On Mon, Feb 5, 2024 at 2:25 PM Oscar Benjamin wrote: > > Hi all, > > There are currently a large number of new contributors opening various > pull requests and commenting on issues in the SymPy repo. This is > great to see, and I want to thank everyone who has been contributing. > > I would like to highlight though that opening pull requests is not the > only way to contribute to SymPy. There are many other ways to > contribute. In fact more important than opening pull requests is > *reviewing* pull requests and issues. For example if you can see that > a pull request likely needs some changes, then it is helpful to > comment on the pull request and suggest what changes are needed until > it looks ready to merge. I am sure that some of the new contributors > could tell quite quickly what changes would be needed in many of the > recently opened pull requests. > > In fact one of the most useful things that a relatively new > contributor can do is to review old issues. The SymPy repo currently > has over 4000 open issues. Many of these are old and are no longer > relevant or already fixed. You can often review these issues just by > testing the code in them. If the issue seems to be fixed then a pull > request with a test could be opened to close the issue. If you do want > to review old issues then I suggest using the issue labels to focus on > a particular area of the code base like "integrals" or "solvers" etc. > > This sort of work is actually much more helpful to the project than > opening pull requests for "easy to fix" issues. > > -- > Oscar > > -- > 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/CAHVvXxQFLH7L%3DjO8EosasVETJn1fCmWaCvbYp%3DMbxvQmg1pB9Q%40mail.gmail.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%3D6%2B8WUQJa_d%2BATjAekCbRgi4D6XCevJqiCmf0EsieSf8gQ%40mail.gmail.com.
Re: [sympy] Releasing SymPy 1.13
On Fri, Feb 2, 2024 at 3:28 PM Oscar Benjamin wrote: > > On Fri, 2 Feb 2024 at 21:52, Aaron Meurer wrote: > > > > On Fri, Feb 2, 2024 at 9:41 AM Oscar Benjamin > > wrote: > > > > > > I think that probably the right way to do this is just for SymPy to > > > use python-flint by default if it is installed but with an almost > > > exact version check like `python-flint == 0.6.x` because `0.6.0` is > > > the minimum version needed for the PR above but also the maximum > > > version that has been tested before release. It would be good to allow > > > the flexibility to have `0.6.1` though in case there is a small bugfix > > > release of python-flint. Over time if things seem more stable then we > > > could relax that version constraint. The environment variable could > > > still be used to override the version check but the default if no > > > environment variable is set should just be to use python-flint but > > > only the expected 0.6.x versions. > > > > > > Does anyone have any thoughts on how exactly to do this? > > > > I think it should just be enabled by default. Almost no one will have > > flint installed, so only people who go out of their way to install it > > will get the benefits, so requiring an opt-in is just an extra step > > for those people. The only way this wouldn't be the case is if we add > > flint as a dependency in the conda package like we do for gmpy, but it > > sounds like it's a bit early to do that. > > > > Although I'm wondering about Sage. Does Sage always install both SymPy > > and python-flint? > > Sage always includes SymPy but not python-flint but it might do now > that SymPy adds the optional dependency: > https://github.com/sagemath/sage/pull/37224#issuecomment-1924466879 Well if Sage is going to do that intentionally to enable Flint support in SymPy then we shouldn't worry about it. > > Sage already includes and uses Flint separately with its own wrapper > but python-flint would be an additional package whose purpose for now > would just be to be used by SymPy inside of Sage. I hope that in > future there will be some convergence between python-flint and Sage's > Flint wrapper. It isn't possible for SymPy to use Sage's Flint wrapper > (outside of Sage) but it could be possible in future for both to use > python-flint or for the Sage wrapper to become something separate from > Sage. > > > As for the verison checks, it depends on how likely you expect there > > to be breaking changes in python-flint. If that package is going to > > have a lot of breaking changes, it will make using it in SymPy a lot > > harder. > > I don't anticipate many breaking changes but python-flint is in a more > active development phase than SymPy and I doubt that we will want to > test all version combinations (just like we don't with mpmath or numpy > etc). > > Actually that reminds me that some of the changes in SymPy 1.13 are > needed for the next release of mpmath (whenever that happens). Now > that mpmath is also in a more active development phase than it has > been for a long time we should review the version checking there as > well. Currently SymPy checks for a 10 year old version of mpmath as > the minimum version: > https://github.com/sympy/sympy/blob/0b25b279a5f089885cfd1b5e7685515338695f58/setup.py#L37 > > Without making python-flint a hard dependency there is no way to > specify what versions should be acceptable in an install so I think > that the safest thing for now is to keep an upper bound that is > checked at runtime. We also definitely need a lower bound because so > far SymPy (master branch) uses the latest python-flint features as > they roll out. I don't know about pip, but conda does let you specify version pins for optional dependencies (it won't install the dependency but if it is installed it will make sure that version is satisfied). But I would be careful with this because it would make it impossible for people to upgrade python-flint in their environment. We used to pin the antlr-python-runtime like this, but then it made it difficult for other packages using antlr, so we removed it (see https://github.com/conda-forge/sympy-feedstock/issues/46). Generally speaking, aggressive version pins can end up biting you. There's a long blog post about this here if you are interested https://iscinumpy.dev/post/bound-version-constraints/. My suggestion at this point would be to not pin in the package metadata. If you're really worried about it, you can add soft checks in the code, which are either just warnings or can be overridden somehow like you suggested. Aaron Meurer > > I'll add a python-flint == 0.6.x check for now. In future I don'
Re: [sympy] Doubt Regarding .mailmap file
Is the name and email there the same as the one you added? If you changed the spelling of your name or the email, you have to add another entry to .mailmap. The point of .mailmap is to indicate when two different name/emails are actually the same person. Otherwise, I suspect the issue is that you have not synchronized the upstream master branch which contains your change to .mailmap. Normally, you should only ever need to add yourself to .mailmap once. After that, you never need to do it again, unless, like I said, you create commits with a different spelling of your name or a different email. Aaron Meurer On Fri, Feb 2, 2024 at 10:36 AM Shishir Kushwaha wrote: > > Do I need to add my details everytime to thee .mailmap file when making a PR > , I did it in my first PR as mentioned in the documentation but when creating > a new comitt on another issue , the authro test was failing even though my > name is there in the file already . Any idea why this could happen? > > > -- > 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/d9705b06-6ca2-49af-9648-e0f23499a6b7n%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%3D6JvrX_-OYL9s9RDM50exqwyi34T3eru73X%3D50_7ymQmWg%40mail.gmail.com.
Re: [sympy] Releasing SymPy 1.13
that. Although I'm wondering about Sage. Does Sage always install both SymPy and python-flint? As for the verison checks, it depends on how likely you expect there to be breaking changes in python-flint. If that package is going to have a lot of breaking changes, it will make using it in SymPy a lot harder. Aaron Meurer > > -- > Oscar > > -- > 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/CAHVvXxTb9K-2uLsCCzfZGHK9HmFekM1LKHQJYVbys60aPr25pg%40mail.gmail.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%3D6%2BunHGnYDEhPoBZn9NWciunSuDp9%3DVKSV2ur-k99%3DFsJw%40mail.gmail.com.
Re: [sympy] Please help me setup documentation
I'm not sure what's going on then. I just tested the docker container and it works for me. You may need to delete the container and rebuild it. Aaron Meurer On Thu, Feb 1, 2024 at 1:15 PM Shishir Kushwaha wrote: > > Yes that's what I did , I followed the steps mentioned in the documentation > and got this error . > However trying to build the docs with sphinx with a seperate command was > successfull , I'm trying to figure out what to do next . > On Thursday 1 February 2024 at 00:53:11 UTC+5:30 asme...@gmail.com wrote: >> >> How are you running the docker container? You need to run >> >> docker run --rm -v /absolute/path/to/SYMPY_ROOT:/sympy sympy_htmldoc >> >> where you replace /absolute/path/to/SYMPY_ROOT with the path to your >> sympy git clone directory. >> >> Or alternatively, you can just install the docs dependencies directly >> to your local environment and build without using docker. >> >> Aaron Meurer >> >> On Wed, Jan 31, 2024 at 1:43 AM Shishir Kushwaha >> wrote: >> > >> > I was trying to build documentation using docker and on running the >> > commands mentioned in the documentation , I was getting this error . >> > >> > /usr/local/bin/makehtml.sh: line 7: cd: /sympy/doc: No such file or >> > directory >> > make: *** No rule to make target 'html'. Stop. >> > >> > -- >> > 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/1a978660-0dd2-49d8-8478-185ad7175ed3n%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/b4fd809f-fb9b-4213-8815-ea5a341dd906n%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%3D6L7ZUVAPzjiHeDNrZHLhWo-yXVMwfPeMNcjsnBRaHJp1Q%40mail.gmail.com.
Re: [sympy] Please help me setup documentation
How are you running the docker container? You need to run docker run --rm -v /absolute/path/to/SYMPY_ROOT:/sympy sympy_htmldoc where you replace /absolute/path/to/SYMPY_ROOT with the path to your sympy git clone directory. Or alternatively, you can just install the docs dependencies directly to your local environment and build without using docker. Aaron Meurer On Wed, Jan 31, 2024 at 1:43 AM Shishir Kushwaha wrote: > > I was trying to build documentation using docker and on running the commands > mentioned in the documentation , I was getting this error . > > /usr/local/bin/makehtml.sh: line 7: cd: /sympy/doc: No such file or directory > make: *** No rule to make target 'html'. Stop. > > -- > 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/1a978660-0dd2-49d8-8478-185ad7175ed3n%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%3D6LmwVGPgdtXzS5bVcpsj1d%3DhN%3De1Z__3uBoBCjctNENtA%40mail.gmail.com.
Re: [sympy] Need GSoC mentors and help updating ideas page
A lot of the advanced ideas are important enough that if we found someone willing and actually able to do them, then we should make an effort to actually find someone who could mentor them. Particularly the ideas relating to the polys like CAD, better Groebner bases, etc. Just glancing at the page, I would be willing to mentor most of the non-physics projects, and would probably re-add them if you did this. The main exception is the SymEngine projects. Let's see if any of the existing SymEngine mentors are willing to mentor on those projects. Otherwise let's remove them. We should also probably remove the LFortran projects as I think Ondřej generally mentors projects for LFortran from another mentoring org. I went ahead and deleted the SymPy Live and SymPy Gamma ideas. SymPy Live is already redone with pyodide, SymPy Gamma still exists but ought to be shut down, and interactive examples is something that other projects are working on, and we can adopt once they have something usable. Maybe the "solvers" idea should be rewritten, but it's definitely an important thing that can be worked on. TBH, I think you could probably come up with ideas for most submodules in SymPy, and probably find someone to mentor most of them. Quite a few wouldn't really be that important, which is maybe why they aren't talked about. Of course, it all boils down to finding a good student for them as well. I honestly think that's way more important than the actual ideas anyway. Almost all the "low hanging fruit" has been completed over the years, and we mostly only have the harder projects left. Should we try to find more (relatively) easy project ideas to add to the list? Or should we just raise our bar of who we accept and accept fewer people? I personally don't really like the low hanging fruit ideas because they generate a lot of low quality applications and noise, but at the same time, we have definitely had some good people in the past who have started with such projects. Aaron Meurer On Wed, Jan 24, 2024 at 4:16 PM Oscar Benjamin wrote: > > I'm not suggesting that we ask people to update the current content of > the ideas page. I am suggesting that we remove *everything* and then > say that if anyone wants something to be listed then they need to add > an up to date description along with a commitment that they will > mentor the project this year. > > It doesn't matter if the old ideas are still relevant. If there is not > a mentor right now who understands what the current state is and > precisely what needs to be done then the project description is not > suitable for advertising to candidates. > > Likewise if the idea has been on that page for 10 years with no one > doing it then probably the description of the project is no good. > Someone should turn it into a clearer, more useful description of a > more realistic project. Otherwise it shouldn't be listed there. > > I am happy to remove everything from the GSOC ideas page but > understand that that is what I mean: I will remove *everything* and > then only add back one or two projects that I am personally willing to > mentor. Anyone else who wants to commit to be a mentor can add up to > date project ideas but otherwise if it is not clear that there is an > available mentor then the project should not be listed. > > We should not roll anything over from previous years automatically in > the way that is currently done either in terms of the list of mentors > or the list of projects. > > -- > Oscar > > On Wed, 24 Jan 2024 at 22:40, Aaron Meurer wrote: > > > > Hi Oscar. > > > > I agree with all of this in principle, but my experience is that it's > > hard to get people to help out with updating the ideas page. And even > > if I wanted to do it all myself, I don't know enough about some of the > > ideas (like the ones in the physics submodule) to say anything about > > them. I will say for a lot of the ideas I do know about, they are > > actually still relevant, the issue is just that they are very > > difficult so no one has ever been able to do them. It is worth keeping > > them around in case someone actually comes along who can actually > > manage them. > > > > If you want to take a shot at doing this, you have my blessing. I > > don't think it's necessary to move the current page to an "old" page > > since the wiki already has an edit history. Maybe you can do it during > > editing, but once it's done, we should delete the "old" page, as it's > > just confusing otherwise. I already submitted the application with the > > link to https://github.com/sympy/sympy/wiki/GSoC-Ideas, so whatever is > > on that page will be "the ideas page". > > > > Aaron Meurer > > > > On Wed, Jan
Re: [sympy] Need GSoC mentors and help updating ideas page
Hi Oscar. I agree with all of this in principle, but my experience is that it's hard to get people to help out with updating the ideas page. And even if I wanted to do it all myself, I don't know enough about some of the ideas (like the ones in the physics submodule) to say anything about them. I will say for a lot of the ideas I do know about, they are actually still relevant, the issue is just that they are very difficult so no one has ever been able to do them. It is worth keeping them around in case someone actually comes along who can actually manage them. If you want to take a shot at doing this, you have my blessing. I don't think it's necessary to move the current page to an "old" page since the wiki already has an edit history. Maybe you can do it during editing, but once it's done, we should delete the "old" page, as it's just confusing otherwise. I already submitted the application with the link to https://github.com/sympy/sympy/wiki/GSoC-Ideas, so whatever is on that page will be "the ideas page". Aaron Meurer On Wed, Jan 24, 2024 at 12:54 PM Oscar Benjamin wrote: > > Hi Aaron, > > I think we should start by removing everything from the ideas page and > moving it to an "old ideas" page with a clear note indicating that > some might still be relevant but others are likely not. I don't think > it is good to leave things on there and just let them roll over from > one year to another. > > Each idea should be added each year by someone who is at willing to > mentor the project in that specific year. Applicants can also look at > the "old ideas" if they are considering proposing something that is > not listed in the main ideas page. > > It would be better to have a small list of good, still relevant ideas > that we are confident can be mentored and that have been recently > checked to see that they are not out of date. I don't think that we > can get to that without first just removing everything. If anyone > wants to see something on the "official" ideas page then they should > add it and list their name with a clear understanding that they are > willing to mentor that project this year if there is a qualified > candidate for the project. > > Many of the names listed as potential mentors are people I have not > seen for some time. I don't really expect that they would mentor a > project and I also don't expect that they would remove their name from > the list: we should not carry that list of "potential mentors" over > from one year to another. The same considerations apply to many of the > project ideas that were added a long time ago by people who are no > longer around and likely have no intention of mentoring any projects > or updating the ideas page. > > Oscar > > On Wed, 24 Jan 2024 at 18:49, Aaron Meurer wrote: > > > > It is time again for us to apply to Google to be a GSoC mentoring org. > > > > I need help updating the GSoC ideas page. > > https://github.com/sympy/sympy/wiki/GSoC-Ideas. If any ideas there are > > already completed, please remove or update them. Also please add new > > ideas, although you may want to discuss them here first if you aren't > > sure about them. > > > > Secondly, we need to update the potential mentors page. > > https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. If > > you were a student in the past I encourage you to mentor. Please add > > your name there if you can mentor this year. If you can't mentor but > > want to help review applications, just let me know. > > > > If you are someone who is interested in applying to SymPy for GSoC, > > start here. https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions > > > > 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+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sympy/CAKgW%3D6JObtA47p10wX6mb5W6c3p%2BqRRQY4GBLnXHKZmyNUtNGg%40mail.gmail.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/CAHVvXxRcet5vmz91g0%3D33JFms2H59zbdiM0wau9ejSuvqi1vNg%40mail.gmail.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%3D6Lrid0UFb_mXtseY_oALESjxLMCCiD8kkpevkNwpg6GDg%40mail.gmail.com.
[sympy] Need GSoC mentors and help updating ideas page
It is time again for us to apply to Google to be a GSoC mentoring org. I need help updating the GSoC ideas page. https://github.com/sympy/sympy/wiki/GSoC-Ideas. If any ideas there are already completed, please remove or update them. Also please add new ideas, although you may want to discuss them here first if you aren't sure about them. Secondly, we need to update the potential mentors page. https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. If you were a student in the past I encourage you to mentor. Please add your name there if you can mentor this year. If you can't mentor but want to help review applications, just let me know. If you are someone who is interested in applying to SymPy for GSoC, start here. https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JObtA47p10wX6mb5W6c3p%2BqRRQY4GBLnXHKZmyNUtNGg%40mail.gmail.com.
Re: [sympy] Numbering in init_printing(latex_mode='equation')
On Mon, Jan 15, 2024 at 1:48 PM Glenn Ramsey wrote: > > On 8/01/24 11:57, Glenn Ramsey wrote: > > > When using init_printing(latex_mode='equation') the equations are numbered > > in > > the output and these appear sequentially in pdf output produced by > > nbconvert. > > > > Is there a way to label the equations so they can be referred to in > > markdown cells? > > Perusing the source it seems not. > > I think it might be possible to implement this by adding a label="foo" keyword > argument to sympy.display(...). That sounds reasonable. Although maybe this is already possible with init_printing() by setting latex_printer to something that adds the label. > > A question now is if I did that and referred to that in the markdown with > something like this: $\@ref(foo)$, would that get picked up? I'm really only > interested in this for static presentation output (pdf, html) so it wouldn't > matter if it doesn't work in interactive modes. I think the only way to know if it will work or not is to test it. I suspect it will work for pdf output, but I have no idea if it will work in the browser. It depends on whether MathJax supports \ref. Aaron Meurer > > Glenn > > -- > 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/89dce9a0-548d-4d46-a862-a3305438bd44%40gmail.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%3D6JscKAE03JTQUoXLfVqbZrY9dJQuAoCA4AUU4C8k3bxTg%40mail.gmail.com.
Re: [sympy] Which interpreter is best?
The SymPy online shell and jupyterlite both run Python in the browser, which will be a little slower than running it locally. Beyond that, your choice of interactive interpreter shouldn't matter that much since they will all be interfacing with the same Python. If you aren't sure what to use, I recommend using Jupyterlab or Jupyter notebook. If you are running into performance issues, it is likely the issue has to do with SymPy itself rather than your interpreter. Aaron Meurer On Mon, Jan 15, 2024 at 2:33 AM Abhay Kumar wrote: > > Hi > I have gone through this contributing to SymPy. and I also set up SymPy in > local as well. But whenever I'm trying to resolve little, complex issues, the > interpreter takes too much time. Can anyone suggest the best interpreter to > work with SymPy? I use SymPy online Shell, Jupyterlite, and vscode. But > didn't get accurate or correct results. > > Thank you, > Abhay > > -- > 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/e36c841f-44a1-4cbf-ad26-207cfbc79c8bn%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%3D6KJyBg2HuxqmUJ7xx1%3Dbb9nhztKzNH_E%2B7S%3DtGyoQ9R4Q%40mail.gmail.com.
[sympy] SymPy GPT
ChatGPT just announced the custom GPT store. https://chat.openai.com/gpts. This lets people make custom GPTs with custom system prompts and custom uploaded documents. I made a SymPy GPT https://chat.openai.com/g/g-AePkBhsFf-sympy-assistant. Unlike normal ChatGPT, it has access to the latest version of SymPy (1.12), and the full SymPy documentation. It also tries to actually execute the code that it generates (unfortunately, the UI for this is kind of bad. You need to click [^_] to see the actual code it writes). You do need a ChatGPT Plus account to use this. Here is the system prompt I used https://gist.github.com/asmeurer/445721f00790cafac574dbf1db9dff03, in addition to uploading the sympy docs pdf and 1.12 wheel. I'd be interested to hear if anyone finds this sort of thing useful. I mainly did it to play around with the custom GPT feature, but I'd be happy to improve on it if people like it. 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KLx9XxDxtnJtGFHGW6wkOPuiagWFqUajfbtYWBhbsfyg%40mail.gmail.com.
Re: [sympy] Nice display of integral, sum, product, etc. for Sympy on MS Windows
I recommend the font Deja Vu Sans Mono for viewing SymPy Unicode pretty printed output https://dejavu-fonts.github.io/. It has the INTEGRAL_EXTENSIOn glyph you mention and it's the only font I know of that actually renders it correctly. It's free and as far as I know it should work on Windows. Of course, you can also just run SymPy in a Jupyter notebook, which will render output using MathJax, which generally looks better than the Unicode output, and works on any platform. Aaron Meurer On Mon, Jan 1, 2024 at 11:45 PM Robert Dodier wrote: > > Hi, I am working on a nicer terminal display for Maxima based on Unicode > characters. I've made some progress and I am hoping to get some info about > how Sympy displays stuff which could inform the stuff I'm doing. > > On my Ubuntu system, it looks like isympy makes use of Unicode characters for > approximating the display of integral, sum, product, etc. in a terminal. E.g. > looks like an integral is drawn with TOP_HALF_INTEGRAL, BOTTOM_HALF_INTEGRAL, > and INTEGRAL_EXTENSION, and sum and product make use of Unicode drawing > characters BOX_DRAWINGS_LIGHT_VERTICAL and so on. That all makes sense to me, > I've already arranged something similar. > > A Maxima user reports that it is nontrivial to get the font stuff sorted out > on MS Windows. Among other problems, he wasn't able to find a font which has > a glyph for INTEGRAL_EXTENSION. > > How does Sympy display integrals etc. on MS Windows? Does Sympy run in a > command terminal or does it manage the display itself or leave it to a third > party (e.g. Jupyter) to handle the display? Does the user have to install > certain fonts along with Sympy? > > Thanks for any light you can shed on this stuff. I'll be glad to look at the > source code if anyone has some pointers. > > best, > > Robert Dodier > > -- > 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/a51ed99a-5a05-4458-b1b7-115281e3cdb1n%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%3D6%2B_UEyaU%2BqKu_Dpr11XBEc2r_r7_G9dMf-H%3Db2aThJN6w%40mail.gmail.com.
Re: [sympy] Go a step back after a bad manipulation
This is more a question of the notebook frontend, not SymPy (SymPy is just doing the symbolic math). The debugger in Jupyter might offer what you are looking for. Or there might be other notebook extensions that do it.I don't personally use the notebook very often so I don't have any specific solutions for you. Aaron Meurer On Thu, Dec 7, 2023 at 10:17 AM Mario Lemelin wrote: > > If I had one functionality to have in Sympy, it would be the possibility to > get access to a list of symbols that I am using in my notebook. A function > called, let's say LstSymbols(), which give the name of the symbols that are > in use in the notebook in addition to their values . This way, I can see if, > by manipulations, I change some values of the symbols. Or maybe that function > already exists? That would be a good thing to have when you are trying to get > back some steps. Just as suggestion! > > Le jeudi 7 décembre 2023 à 09:49:36 UTC-5, syle...@gmail.com a écrit : >> >> Jupyter notebook is already a good framework to write code like literature, >> and unfortunately, I don't think that we need a different tooling from SymPy >> to do that. >> >> I just advice to make multiple cells, structure your notebooks well, >> and print the intermediate results of your computation often in your cell >> (use print or display) >> >> I don't think that it is easy for any computer algebra, or related tools to >> support 'step-back' functionality. >> I haven't seen that in other competitors, like Mathematica, too. >> The problem can be generalized to time-travel debugging (Time travel >> debugging - Wikipedia), >> and it is an area of research, if it matters how to do it correctly, or >> efficiently. >> >> On Wednesday, December 6, 2023 at 10:20:16 PM UTC gu...@uwosh.edu wrote: >>> >>> Aaron's comments are really important. These are pitfalls that can easily >>> lead to inconsistent outcomes and notebooks that do not work. >>> >>> On Wednesday, December 6, 2023 at 3:09:16 PM UTC-6 asme...@gmail.com wrote: >>>> >>>> It really depends on how you structure your code. SymPy expressions >>>> are immutable, so if you just assign each step to a different >>>> variable, you can easily refer back to previous variables. >>>> >>>> You should also be careful with Jupyter notebooks that if you delete >>>> cells, or insert cells before other cells, you may end up with a >>>> notebook that doesn't actually execute again if you open it again >>>> later, because when you start a notebook from scratch the cells are >>>> always executed from top to bottom, which may not be the original >>>> execution order. It can sometimes be a good idea to "restart and run >>>> all" in your notebook to reset the state and ensure everything runs >>>> again. >>>> >>>> Aaron Meurer >>>> >>>> On Mon, Dec 4, 2023 at 10:24 AM Mario Lemelin wrote: >>>> > >>>> > Hello, >>>> > This is my first time. Just wondering if there is a command that I can >>>> > do when, in a jupyter notebook, when I want to go back one step (If I >>>> > did a bad algebraic manipulation for example). Thank you in advance for >>>> > your help. Mario >>>> > >>>> > -- >>>> > 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/82c3aedb-215b-4083-a462-42bbc5684632n%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/b8bf74c3-511c-49d6-b5e4-cd8ee5681e6en%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%3D6J0vvVQ13OZ62GMqF_Y4zqiqLWygyR6LsXzc_CJ%2B9CbDA%40mail.gmail.com.
Re: [sympy] Go a step back after a bad manipulation
It really depends on how you structure your code. SymPy expressions are immutable, so if you just assign each step to a different variable, you can easily refer back to previous variables. You should also be careful with Jupyter notebooks that if you delete cells, or insert cells before other cells, you may end up with a notebook that doesn't actually execute again if you open it again later, because when you start a notebook from scratch the cells are always executed from top to bottom, which may not be the original execution order. It can sometimes be a good idea to "restart and run all" in your notebook to reset the state and ensure everything runs again. Aaron Meurer On Mon, Dec 4, 2023 at 10:24 AM Mario Lemelin wrote: > > Hello, > This is my first time. Just wondering if there is a command that I can do > when, in a jupyter notebook, when I want to go back one step (If I did a bad > algebraic manipulation for example). Thank you in advance for your help. Mario > > -- > 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/82c3aedb-215b-4083-a462-42bbc5684632n%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%3D6KZhvfhWa%2BHWPZEyKJKtFDELvPpp4DWA8SHHURgZo0AGA%40mail.gmail.com.
Re: [sympy] SymPy CZI Grant Code Generation & Biomechanics Outcomes
Thank you for sharing the blog post Jason. Some of the work you are doing related to getting the codegen to output a matrix solve instead of inverses is related to the work I did years ago here https://github.com/ergs/transmutagen/blob/master/transmutagen/codegen.py. I wish I had taken the time to upstream it. I'm excited to see that codegen for matrix expressions is finally starting to improve. Aaron Meurer On Fri, Oct 27, 2023 at 12:31 AM Jason Moore wrote: > > Hi, > > I've made a blog post summarizing all the work we did for 1/3 of the CZI > grant: > > https://mechmotum.github.io/blog/czi-sympy-wrapup.html > > Feedback welcome and please try out the new code! > > Jason > moorepants.info > +01 530-601-9791 > > -- > 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/CAP7f1Ag9n7HdZWdLTD%3DrpVTDB_wLhZdC%2BZuOcFkL2nw0Atb-BQ%40mail.gmail.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%3D6LGLJyG4FR%2Bdd99ctge5L0%3DDBsZ65hNyU3FU1kUYi9s1A%40mail.gmail.com.
Re: [sympy] Matrix vector multiplication
The problem is, as I noted, you are using NumPy arrays to store SymPy
expressions instead of using SymPy matrices. NumPy arrays do not
define * as matrix multiplication like sympy matrix does, but rather
as elementwise multiplication with broadcasting. It's generally a good
idea to use @ for matrix multiplication instead of *, but even so, you
wouldn't have this issue if you used only SymPy matrices because
SymPy's Matrix does define * as matrix multiplication.
I would recommend not mixing NumPy and SymPy like this. You should do
symbolic operations using only SymPy and SymPy classes. If you want to
use NumPy to do numeric calculations on these expressions, this should
be done explicitly at the end after converting your SymPy expression
into a NumPy function using lambdify().
Aaron Meurer
On Thu, Nov 2, 2023 at 4:45 AM Lenni Lemoy wrote:
>
> Hi Aaron, thank you for your answer!
>
> Here is more detail on what I did (from my ipython session):
> In [1]: from sympy import symbols, eye, Matrix
> In [2]: b = np.array([symbols(f"b_{i}") for i in range(3)])
> In [3]: M = eye(3)
> In [4]: M*b
> Out[4]:
> array([[b_0, 0, 0],
>[0, b_1, 0],
>[0, 0, b_2]], dtype=object)
>
> I fixed it now using sympy.Matrix instead of the np.array:
> In [5]: b = Matrix(b)
> In [6]: M*b
> Out[6]:
> Matrix([
> [b_0],
> [b_1],
> [b_2]])
>
> Thanks again! That was an important hint :)
>
>
> asme...@gmail.com schrieb am Donnerstag, 2. November 2023 um 04:03:44 UTC+1:
>>
>> What is the type of your vector x? If it is a Matrix, this is just the
>> way that SymPy works. It represents "vectors" as a 1 x n matrix. If it
>> is an object from the sympy.vector module then I'm not sure.
>>
>> I would recommend not using NumPy to manipulate SymPy objects like
>> that. NumPy should only be used for numeric values and ideally you
>> should only do so after converting your SymPy expression to a NumPy
>> function with lambdify(). You lose out on the benefits of using SymPy
>> if you store SymPy objects in a NumPy array. See
>> https://docs.sympy.org/dev/explanation/best-practices.html#separate-symbolic-and-numeric-code
>>
>> Aaron Meurer
>>
>> On Wed, Nov 1, 2023 at 8:15 PM Lenni Lemoy wrote:
>> >
>> > Hi everybody,
>> >
>> > I just started using SymPy, and tried to multiply a matrix M by a vector x
>> > holding sympy.symbols.
>> >
>> > I expected that M*x will be a vector again, but it is a matrix holding
>> > elements M_i,j*x_j.
>> >
>> > Is that the intended behavior or am I doing something wrong? I looked for
>> > another method I could use but found nothing adequate. Currently, I use
>> > np.sum(M*x, axis=1) to obtain the vector result, but this seems a little
>> > awkward.
>> >
>> > Thanks already for any info on this! :)
>> >
>> > --
>> > 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/5dfb60ca-617f-429a-b23c-c59c67cc98c3n%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/d060941d-279b-4763-b7c1-4d0482f39589n%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%3D6%2BLMjfBED%2BqVfGXosz%2BsxirVe8wybx7Arde7rBcWUacsA%40mail.gmail.com.
Re: [sympy] LLL and sympy
On Sun, Nov 5, 2023 at 8:22 PM T-Rex wrote: > > Thanks @oscar! I didn't think I would get a reply from the blog's owner :-) > > Re setting of the environment variable SYMPY_GROUND_TYPES=flint: (1) Would > that be in conflict with other parts of sympy/numpy/scipy? (2) After it is > set to flint, is there a way to turn it back to the default? I can see > scenarios where I need to bench mark various options, and it would be really > nice to be able to change the flag as I go along in my jupyter notebook, as > oppsed to restarting the program from scratch. NumPy, SciPy, and other libraries do not use flint, only SymPy. Other parts of SymPy do use flint, but it's all completely transparent. The only difference is the output. Right now, there's no way to change the option after SymPy is imported, which is why it is set as an environment variable. So if you want to test different things, you'll have to restart the notebook. > > Taboo question: When might Sympy 1.13 be coming out? I am know that such > questions are taboo, but my project has various stages/steps, and depending > on the availability of 1.1.3 I might want to work on the LLL-parts first > while waiting for 1.1.3 to become available. There's no reason to not ask this question. And anyways, Oscar mentioned to me that he wants to make a release soon so (hopefully) it should be out before the end of the year, if not month. Aaron Meurer > > MANY THANKS for your help and advice. > > On Sunday, November 5, 2023 at 10:23:54 AM UTC-5 Oscar wrote: >> >> On Sun, 5 Nov 2023 at 15:04, T-Rex wrote: >> > >> > According to https://oscarbenjamin.github.io/blog/czi/post2.html sympy now >> > has LLL, but when I consulted the sympy documentation I could not find >> > actual commands that produces an LLL-reduced basis. >> >> SymPy has a new matrix type called DomainMatrix for which the >> LLL-algorithm is implemented. Ideally the LLL-algorithm would be >> exposed through the ordinary Matrix type but it is not. The >> DomainMatrix.lll method is documented here: >> https://docs.sympy.org/latest/modules/polys/domainmatrix.html#sympy.polys.matrices.domainmatrix.DomainMatrix.lll >> >> Starting with an ordinary Matrix M the command to get an LLL-reduced >> basis in SymPy 1.12 is: >> >> In [1]: from sympy.polys.matrices import DomainMatrix >> >> In [2]: M = randMatrix(5) # make a random 5x5 Matrix >> >> In [3]: M >> Out[3]: >> ⎡74 3 71 3 27⎤ >> ⎢ ⎥ >> ⎢86 74 14 89 26⎥ >> ⎢ ⎥ >> ⎢58 2 14 54 17⎥ >> ⎢ ⎥ >> ⎢35 53 17 58 31⎥ >> ⎢ ⎥ >> ⎣72 83 33 61 85⎦ >> >> In [4]: dM = DomainMatrix.from_Matrix(M) # Convert to DomainMatrix >> >> In [5]: dM.lll().to_Matrix() # Compute LLL-basis and convert back to Matrix >> Out[5]: >> ⎡ 7 -19 17 23 22⎤ >> ⎢ ⎥ >> ⎢51 21 -3 31 -5⎥ >> ⎢ ⎥ >> ⎢-23 51 3 4 14⎥ >> ⎢ ⎥ >> ⎢53 -2 -4 -24 18⎥ >> ⎢ ⎥ >> ⎣-14 -24 -58 -4 13⎦ >> >> In SymPy 1.13 there will be a to_DM() method to make this a bit easier >> so it is just: >> >> M.to_DM().lll().to_Matrix() >> >> Ideally we should add an .lll() method directly to Matrix to do this >> without users needing to perform the conversion explicitly. >> >> Also SymPy 1.13 will be able to use python-flint for this. If you have >> python-flint installed (pip install python-flint) and then set the >> environment variable SYMPY_GROUND_TYPES=flint then the >> DomainMatrix.lll method will automatically use Flint which is a lot >> faster for this operation. >> >> -- >> Oscar > > -- > 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/54713a7c-886f-46dd-965e-0e288e61d901n%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%3D6LAkNZFfd3QqaMMjreAH2YqYWpPC-%2B6Eg8627As_R1i5A%40mail.gmail.com.
Re: [sympy] SymPy CZI Grant Documentation Blog Post
Yes, although a few pages are only available in the dev docs (https://docs.sympy.org/dev/index.html). All the relevant pages are linked to from the blog post. Aaron Meurer On Thu, Nov 2, 2023 at 3:12 AM wrote: > > Dear Aaron, > > Thanks! > Is this new documentation available now? > Probably due to my advanced age, I am not good at understanding most of the > technical terms in your blog, but I do know math a bit and I am a heavy user > of sympy mechanics. > > Take care! > > Peter > > -Original Message- > From: sympy@googlegroups.com On Behalf Of Aaron > Meurer > Sent: Donnerstag, 2. November 2023 08:16 > To: sympy > Subject: [sympy] SymPy CZI Grant Documentation Blog Post > > I have written a blog post about the documentation work that I did as part of > the CZI EOSS cycle 4 grant. > > https://labs.quansight.org/blog/sympy-documentation > > Feedback on the new documentation pages or documentation feedback in general > is always welcome. > > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6KU57OZmyJ0wB2MvW-HLW%3DqjJWJU8CiKBdRbGcMUw5DXQ%40mail.gmail.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/001d01da0d6c%24be6b8f00%243b42ad00%24%40gmail.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%3D6Le-U1EqscsU6hNgP4vSVsWiQh0yL%3D%3DvpfHD2PU2He%3DKA%40mail.gmail.com.
[sympy] SymPy CZI Grant Documentation Blog Post
I have written a blog post about the documentation work that I did as part of the CZI EOSS cycle 4 grant. https://labs.quansight.org/blog/sympy-documentation Feedback on the new documentation pages or documentation feedback in general is always welcome. 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KU57OZmyJ0wB2MvW-HLW%3DqjJWJU8CiKBdRbGcMUw5DXQ%40mail.gmail.com.
Re: [sympy] Matrix vector multiplication
What is the type of your vector x? If it is a Matrix, this is just the way that SymPy works. It represents "vectors" as a 1 x n matrix. If it is an object from the sympy.vector module then I'm not sure. I would recommend not using NumPy to manipulate SymPy objects like that. NumPy should only be used for numeric values and ideally you should only do so after converting your SymPy expression to a NumPy function with lambdify(). You lose out on the benefits of using SymPy if you store SymPy objects in a NumPy array. See https://docs.sympy.org/dev/explanation/best-practices.html#separate-symbolic-and-numeric-code Aaron Meurer On Wed, Nov 1, 2023 at 8:15 PM Lenni Lemoy wrote: > > Hi everybody, > > I just started using SymPy, and tried to multiply a matrix M by a vector x > holding sympy.symbols. > > I expected that M*x will be a vector again, but it is a matrix holding > elements M_i,j*x_j. > > Is that the intended behavior or am I doing something wrong? I looked for > another method I could use but found nothing adequate. Currently, I use > np.sum(M*x, axis=1) to obtain the vector result, but this seems a little > awkward. > > Thanks already for any info on this! :) > > -- > 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/5dfb60ca-617f-429a-b23c-c59c67cc98c3n%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%3D6JOiQjmJi53pCsiJrBOz238zHYz800UtbU9pFyuXsEYtA%40mail.gmail.com.
Re: [sympy] New featured project
I think it can be added. Can you make a pull request? Aaron Meurer On Wed, Oct 4, 2023 at 10:18 AM Mathias Louboutin wrote: > > Hi > > Would it be possible to add our project devito: > > https://www.devitoproject.org/ > > to the "Project using sympy" in the documentation. Devito is a symbolic DSL > and stencil for high performance computing that heavily relies on sympy for > the high level symbolic interface and for the code generation. > > Cheers > > Mathias Louboutin > > -- > 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/4fab57a6-314f-44d4-9f1c-873347670f65n%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%3D6JRJ7o_kc1CX6Vybky74RTPaCuozGO0OcHRMYnrN9riyg%40mail.gmail.com.
Re: [sympy] Re: looking for a numerical expression to fail this test
I'm not saying that this sort of calculation shouldn't be doable, just that the user needs to be explicit about asking for it to happen. Also keep in mind that some evalf() calls can be very slow. This can obviously happen if the expression is large, but it can also happen for some Integrals and Sums in the current code. Here's an example (from https://github.com/sympy/sympy/issues/10800) Integral(sin(exp(x)), (x, 1, oo)).evalf() # hangs Obviously we need to fix that to evaluate faster, but the point is that even if we did that, evalf is inherently a very expensive operation in general. On Fri, Sep 22, 2023 at 3:16 PM Chris Smith wrote: > > > This is a great example of code that ends up being dependent on > automatic evaluation behavior which makes that behavior harder to > remove. > > If that is removed then the test will be changed to whatever mechanism will > allow the sign of `self - i` to be determined. And for an arbitrary function > I don't know how you can do that without evaluation (even if that evaluation > does something like ball/interval arithmetic to determine that the range of > possible values allows the inequality to be determined). Computing with > `n(2)` is much faster than trying to infer the value of a complicated > expression. > > Do you have ideas about how we can tell if `sqrt(log(100)+log(log(100))) > 2` > that is faster than evaluation? Computing whether a > b is a hard problem. It's computation undecidable in general by Richardson's theorem (a = b is equivalent to ~(a > b) & ~(a < b)). If you have something like sin(1)**2 + cos(1)**2 > 1, and you try to compute it numerically, you cannot get a definite answer. So the only reasonable approach is to use something that is fast, but might give an indeterminate answer, and give users an option to extend to something more computationally expensive. I know the code here is coming from __int__, which can only return a number or raise an exception. I would say here that it should just raise an exception when too much computation is required, and there should be a separate SymPy API that can return an unevaluated expression and has options for controlling how much computation is done. But if your model is "compute everything immediately with automatic evaluation", you have absolutely no control over how much computation is done. And you end up with defaults that try to do way too much computation, which ends up slowing things down. Aaron Meurer > > I don't really appreciate the preference for using `is_gt(a,b)` instead of > `(a > b) is S.true` or else I may have used the former. (I forgot until > writing this that we had that function.) I can change that in the code if > that would make something clearer. > > /c > > > On Tuesday, September 19, 2023 at 12:26:31 PM UTC-5 Aaron Meurer wrote: >> >> This is somewhat off-topic, but perhaps related to what you are trying >> to figure out, and anyway I see that this code is part of a PR >> https://github.com/sympy/sympy/pull/25699. I don't like how this code >> depends on the fact that self < i automatically evaluates to true or >> false. This is a great example of code that ends up being dependent on >> automatic evaluation behavior which makes that behavior harder to >> remove. Whether a < b can be computed and whether it should evaluate >> automatically are separate considerations. It would be better if there >> were an explicit method, like say (a > b).doit(), to tell an >> inequality to try to evaluate to true or false. >> >> Things like this are one of the main reasons the core is slower than >> it needs to be. It's the reason why, for instance, the expression from >> https://github.com/sympy/sympy/issues/24565 takes over 20 seconds just >> to construct. >> >> There are three types of automatic evaluation that are bad, in terms >> of performance: >> >> 1. Creating expressions that are larger than the original >> 2. Using assumptions. >> 3. Using evalf (this is often implicitly done as part of using assumptions) >> >> Using evalf is by far the worst of these. It's the thing that causes >> SymPy to hang on very simple things that should return instantly (see >> https://github.com/sympy/sympy/issues/10800 for another example of >> this). We need to move to a model where evalf is never called >> automatically, except for cases where it is known that it will be very >> cheap. >> >> Aaron Meurer >> >> On Tue, Sep 19, 2023 at 8:48 AM Chris Smith wrote: >> > >> > `eq=(cos(2)**2+sin(2)**2-1/S(10**120))` rounds to 1 but neither `eq<1` nor >> > `eq>1` evaluates but the correct value for `int(eq)` is 0. >> > >
Re: [sympy] Re: looking for a numerical expression to fail this test
This is somewhat off-topic, but perhaps related to what you are trying to figure out, and anyway I see that this code is part of a PR https://github.com/sympy/sympy/pull/25699. I don't like how this code depends on the fact that self < i automatically evaluates to true or false. This is a great example of code that ends up being dependent on automatic evaluation behavior which makes that behavior harder to remove. Whether a < b can be computed and whether it should evaluate automatically are separate considerations. It would be better if there were an explicit method, like say (a > b).doit(), to tell an inequality to try to evaluate to true or false. Things like this are one of the main reasons the core is slower than it needs to be. It's the reason why, for instance, the expression from https://github.com/sympy/sympy/issues/24565 takes over 20 seconds just to construct. There are three types of automatic evaluation that are bad, in terms of performance: 1. Creating expressions that are larger than the original 2. Using assumptions. 3. Using evalf (this is often implicitly done as part of using assumptions) Using evalf is by far the worst of these. It's the thing that causes SymPy to hang on very simple things that should return instantly (see https://github.com/sympy/sympy/issues/10800 for another example of this). We need to move to a model where evalf is never called automatically, except for cases where it is known that it will be very cheap. Aaron Meurer On Tue, Sep 19, 2023 at 8:48 AM Chris Smith wrote: > > `eq=(cos(2)**2+sin(2)**2-1/S(10**120))` rounds to 1 but neither `eq<1` nor > `eq>1` evaluates but the correct value for `int(eq)` is 0. > > /c > > On Tuesday, September 19, 2023 at 8:14:35 AM UTC-5 Chris Smith wrote: >> >> Given >> ``` >> def f(self): >> from sympy.core.numbers import int_valued >> r = self.round(2) >> i = int(r) >> if int_valued(r): >> # non-integer self should pass one of these tests >> if (self > i) is S.true: >> return i >> if (self < i) is S.true: >> return i - 1 >> # is it safe to assume that self == i? >> return i ``` Can anyone think of a real numerical expression which will >> round up and then not compare with self and cause f to return an integer >> that is 1 too large? > > -- > 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/e58a36bd-af3d-43ae-97fd-c9fb06d4f4afn%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%3D6KN8ZW%2BUE9hkmuqh7zw_ENX%3DPJzsSZ5UiCG1uZf3OVOZg%40mail.gmail.com.
Re: [sympy] Future of SymPy part 2: polynomials
Also I resubmitted part 1 at the request of the HN mods and it has some comments as well https://news.ycombinator.com/item?id=37430759 Aaron Meurer On Fri, Sep 8, 2023 at 1:09 AM Aaron Meurer wrote: > > I posted this to Hacker News, where it got some comments. > https://news.ycombinator.com/item?id=37426080 > > Aaron Meurer > > On Wed, Sep 6, 2023 at 5:08 PM Oscar Benjamin > wrote: > > > > Hi all, > > > > I have a new blog post following the last one: > > https://oscarbenjamin.github.io/blog/czi/post2.html > > > > This one discusses SymPy's polynomial system, improvements that can be > > made and in particular how to make use of python-flint to speed up > > polynomial operations in SymPy. > > > > -- > > Oscar > > > > -- > > 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/CAHVvXxR%3DPJen0wgMm%3D%2BOWEyOQ%3DhaCHMVtcqSdbCcwQZ1adxW8w%40mail.gmail.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%3D6%2B3Wv9-kf_JPPKx3cZBcqL4MFr3jiCJVqkK1rSmico9JA%40mail.gmail.com.
Re: [sympy] Future of SymPy part 2: polynomials
By the way, if you install SymPy from conda-forge, they gmpy2 will be installed automatically. If you use conda-forge chances are you've already been using it this whole time. Aaron Meurer On Fri, Sep 8, 2023 at 1:13 AM wrote: > Dear Oscar, > > Thanks! > I installed it (I used anaconda, rather than pip), all went well. > As you predicted, I did not find any difference so far, will keep on > observing. > > Thanks again! > > Peter > > -Original Message- > From: sympy@googlegroups.com On Behalf Of Oscar > Benjamin > Sent: Donnerstag, 7. September 2023 12:41 > To: sympy@googlegroups.com > Subject: Re: [sympy] Future of SymPy part 2: polynomials > > On Thu, 7 Sept 2023 at 11:14, wrote: > > > > Dear Oscar, > > > > While 99% is way above my head (I studied engineering 40+ years ago), it > is fascinating reading! > > I had no idea, how much 'math' was in sympy. > > > > In your post you write: > > > > if gmpy2 is installed then SymPy will use it and will be a lot faster > for some operations but with no other observable change in behaviour. > > > > I only use sympy through symy.physics.mechanics, to pass my time doing > simulations, and I do it on Jupyter notebook. > > Would gmpy2 potentially speed up the formation of Kane's equation of > motion? > > It is very easy to install gmpy2 (pip install gmpy2) to see if it does > speed anything up. > > I don't think that the mechanics module explicitly uses any of the > low-level polynomial code so the question would be whether something like > cancel or factor is being used somewhere. My expectation is that things > like that would be avoided in mechanics. The next post will talk about > matrices which is more relevant for the mechanics module although the > matrices would be matrices of polynomials so having fast polynomials also > makes a big difference to linear algebra. This would be very relevant to > our previous discussion here: > https://github.com/sympy/sympy/issues/24679 > > -- > Oscar > > -- > 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/CAHVvXxQWcQNG9Fyb6_aZx4jOOZKjR11RN7mTfppSGdoVLns_MQ%40mail.gmail.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/01d9e224%2401d58210%2405808630%24%40gmail.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%3D6%2B2xM2W4KZmN9d9YrYEsxuyU70xfsKr457xEnXvgF%3D4Ng%40mail.gmail.com.
Re: [sympy] Future of SymPy part 2: polynomials
I posted this to Hacker News, where it got some comments. https://news.ycombinator.com/item?id=37426080 Aaron Meurer On Wed, Sep 6, 2023 at 5:08 PM Oscar Benjamin wrote: > > Hi all, > > I have a new blog post following the last one: > https://oscarbenjamin.github.io/blog/czi/post2.html > > This one discusses SymPy's polynomial system, improvements that can be > made and in particular how to make use of python-flint to speed up > polynomial operations in SymPy. > > -- > Oscar > > -- > 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/CAHVvXxR%3DPJen0wgMm%3D%2BOWEyOQ%3DhaCHMVtcqSdbCcwQZ1adxW8w%40mail.gmail.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%3D6J7uvHOwEsSNq5CtBySBvZjoGGE-GGZrD1XRUKkHJMaKg%40mail.gmail.com.
Re: [sympy] Blog post about the the future of SymPy
On Sun, Sep 3, 2023 at 11:43 AM emanuel.c...@gmail.com
wrote:
>
> [ Sagemath user and small-time developper here… ]
>
> As far as I can tell, Oscar’s points are right on the spot. I’d second them
> with a remark : more generally, the user-visible functions and the algorithm
> implementations should be more separated in distinct layers, the
> “translation” between external (user-visible) representations and internal
> implementations of the same objects being impliicitely handled.
>
> His point about the toxic side-effects of automatic evaluation is right.
> However, I note that this can be (at leas partially) simulated now, via the
> evaluate keyword accepted by numerous Basic functions and methods :
>
> >>> from sympy import cos, pi, sqrt, sympify >>> cos(pi/3) 1/2 >>> cos(pi/3,
> >>> evaluate=False) cos(pi/3) >>> sympify("sqrt(4)*cos(pi/3)") 1 >>>
> >>> sympify("sqrt(4)*cos(pi/6)", evaluate=False) sqrt(4)*cos(pi/6)
>
> I wonder if this problem could be handled with a auto_evaluate context
> handler, signalling to the symbolic expression system that the automatic
> evaluation is not allowed at this stage. Of course, you should have a tool to
> evaluate unevaluated expression (analogous to thehold/unhold mechanism
> available in large parts of Sage or the quoting/nouns mechanism
> (contraption…) of Maxima)…
SymPy already has an evaluate(False) context manager. But that doesn't
really solve the fundamental problem, which is that virtually every
algorithm in SymPy is written expecting evaluation. If you search the
issue tracker, you'll find hundreds of issues with various things that
don't work when you disable evaluation. Quite a few of them come from
just from printing, meaning the user isn't even really trying to do
anything with the expression. Basically, evaluate=False or 'with
evaluate(False)' only "works" in the very technical sense. If you
actually try using it it will lead to an endless number of bugs and
unexpected behavior.
Basically, when evaluation happens all the time and certain invariants
about expressions always hold, then functions are written assuming
those invariants. It isn't even done intentionally most of the time.
The only way out of this is to have a core that never evaluates in the
first place, so that code written against it will never assume
evaluation.
Aaron Meurer
>
> Le vendredi 1 septembre 2023 à 14:56:09 UTC+2, gu…@uwosh.edu a écrit :
>
> Take a look at SageMath (https://www.sagemath.org/), which does pulls
> together lots of disparate packages. I have used it and even contributed to
> it. I recommend it for people doing pure math or sophisticated niche work.
> However, It has historically been too heavy-weight and difficult to use
> correctly for the applications I have in the physical sciences and teaching.
> They are working towards making installable with pip, which may help with
> some of my issues.
>
> One non-trivial issue of Sagemath is that a large number of the packages it
> uses are Unix-only ; this “weds” Sagemath to Unix (in the Catholic + shotgun
> version of “wedding” : don’t even think of divorce…). Since a generation of
> potential users have been force-fed Windows as their primary interface with
> computers, this may be a problem…
>
> A Cygwin version of Sagemath has long been (heroically !) maintained, but
> this effort has been recently stopped. The recommended way to run Sagemath on
> Windows is nowadays to install Windows Subsystem for Linux version 2, install
> a Linux distribution, then install Sagemath from source on this.
>
> None of this is especially difficult, but Windows users are in for a serious
> cultural schock… Furthermore, this may disrupt the integration of tool chains
> end users are used to. If you are used to integrate computational results in
> documents (e.g. via markdown/pandoc, R’s knitr or emacs’ org-mode), you’d
> better use a Unix version of your tools, creating some Windows-to-Unix bridge
> scripts if necessary.
>
> Nevertheless, this might be (is, IMNSHO) worthwile : the range of
> mathematical tools accessible via Sage is astounding. BTW : this includes
> Sympy ;-), as well as some proprietary tools such as Magma, Mathematica,
> Maple or Matlab. Having one central software and language to access all these
> tools is indeed precious.
>
> Jonathan
>
> On Thursday, August 31, 2023 at 8:57:57 PM UTC-5 syle...@gmail.com wrote:
>
> Thanks for the blog post.
>
> Unfortunately, I'm outside from using SymPy recently because
> I'm now mainly involved in projects that use React and Typescript heavily,
>
> However, I particularly find things like mathjs
> josdejong/mathjs: An extensive math libr
Re: [sympy] hyint: hybrid (symbolic-numeric) integration
On Fri, Sep 1, 2023 at 4:12 AM Oscar Benjamin wrote: > > On Fri, 1 Sept 2023 at 06:45, Aaron Meurer wrote: > > > > I like the idea of using some faster linear algebra as a preprocessor > > to reduce the size of the problem to be solved. You could then take > > the reduced problem and solve it with exact symbolic arithmetic. The > > worst that can happen is you might drop an ansatz that shouldn't have > > been dropped, but you would still always give a symbolically correct > > answer when you do. > > > > If heurisch could support much larger, possibly linearly dependent > > ansatz, then that would open up a lot of possibilities, like for > > instance, trying to use ansatz coming from both sqrt(x) and x/sqrt(x) > > simultaneously. But right now it's way too slow even with just the > > linear system it generates. > > I'm not sure if I've interpreted this point correctly but when > heurisch is slow it is not usually because of the linear algebra part. > Probably that is the easiest part to speed up as well. Maybe things have changed since the introduction of things like DomainMatrix, but when I benchmarked it years ago this was the case. That and the fact that it was using the dense poly representation with hundreds of variables. > > The slow parts of heurisch are converting back and forth between Expr > and the domains, differentiation, and cancel. > > If heurisch was being rewritten then I think it could be written > without the back and forth conversions. The differentiation could be > handled in the domain representation. The cancellation could be > handled there as well. We could probably merge a lot of the code in risch and heurisch, but loosening the restrictive rigorous code from risch. Actually Risch itself can solve some algebraic integrals if the restrictions are removed (just the nonelementary integral errors would be incorrect). > > I suspect that heurisch was implemented at a time when SymPy did not > have as many of the pieces that it now has that you would want to use > to implement the algorithm within the algebra subsystem rather than > the symbolic subsystem. Yes, heurisch predates the polys module. I integrated it with the polys back in 2012 or 2013, but I didn't really refactor it in any major way. Aaron Meurer > > Possibly the limiting factor for SymPy implementing heurisch in the > ideal way right now is support for symbolic algebraic extensions like > Q(x)[sqrt(x)] within the domain system although polys.agca has > FiniteMonogenicExtension that could represent that. > > -- > Oscar > > -- > 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/CAHVvXxSN%2BVBubjX6i3mq%3DwE7nXZSorg7drnSP_X3-2daxbzE0Q%40mail.gmail.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%3D6JmY0mA_bfTKggY_%3DtTR74j%2BQ0MkViPeeCs35-yOQihkg%40mail.gmail.com.
Re: [sympy] hyint: hybrid (symbolic-numeric) integration
On Thu, Aug 31, 2023 at 8:22 PM Shahriar Iravanian wrote: > > Thank you very much for your comments. > > While hyint ansatz generation is similar in spirit to heurisch, it is less > rigorous and more > heuristic. One reason is that the numerical portion of hyint is much more > forgiving and > can filter out many undesirable ansatzes (by using QR decomposition to remove > linearly > dependent ones and sparse regression to solve the integral). Therefore, we > can generate > many different forms of ansatz, which allows hyint to solve integrals beyond > what > heurisch can do. > > For example, I use a set of 170 test cases (listed in test.py) to test hyint. > The current version > can solve 154 of them; heurisch solves 126 (of course, this list is curated > for hyint). > > Some integrals that hyint can solve and heurisch cannot: > > x/sqrt(x - 1) => 2*x*sqrt(x - 1)/3 + 4*sqrt(x - 1)/3 > 1/sqrt(x**2 + 4) => asinh(x/2) > sqrt(x)*log(x) => 2*x**(3/2)*log(x)/3 - 4*x**(3/2)/9 > log(log(x))/x => log(x)*log(log(x)) - log(x) > log(cos(x))*tan(x) => -log(cos(x))**2/2 > sin(x + 1)/(x + 1) => Si(x + 1) > sqrt(1 - sin(x)) => 2*cos(x)/sqrt(1 - sin(x)) By the way, a big problem with heurisch is that it's very sensitive to the way the derivative of the expression is represented, since that's how it generates the ansatz. This is fundamental to the approach, but an issue is that it just directly uses whatever sympy.diff() returns. This is a big problem for algebraic functions because they can be represented in multiple different ways, and that representation can affect the result of integration (a big piece of the "real" Risch algorithm for algebraic functions is normalizing things so that this isn't a problem). For example, the derivative of s = sqrt(x) can be represented as 1/(2*s) or s/(2*x). SymPy happens to use the former form, because of the way the core combines exponents, but there are integrals with square roots where heurisch can't find the answer but would if it used the latter form (not so much because the latter form is better, although in some ways it is since it's a polynomial in s, but usually just by dumb luck of the way it generates the ansatz). > > Some integrals that heurisch can solve and hyint cannot: > > exp(x)/(exp(2*x) - 1) => log(exp(x) - 1)/2 - log(exp(x) + 1)/2 > tan(x)**3 => -log(tan(x)**2 + 1)/2 + tan(x)**2/2 > > > Actually it wouldn't be much work to generalize this to something that > > gives an exact answer at least some of the time. > > I completely agree. I believe the main application of hyint is as an ansatz > discovery > engine rather than a standalone integrator. This is a line of research I'm > actively > pursuing and would appreciate help, comments, and collaboration! I like the idea of using some faster linear algebra as a preprocessor to reduce the size of the problem to be solved. You could then take the reduced problem and solve it with exact symbolic arithmetic. The worst that can happen is you might drop an ansatz that shouldn't have been dropped, but you would still always give a symbolically correct answer when you do. If heurisch could support much larger, possibly linearly dependent ansatz, then that would open up a lot of possibilities, like for instance, trying to use ansatz coming from both sqrt(x) and x/sqrt(x) simultaneously. But right now it's way too slow even with just the linear system it generates. I'm also wondering if you've thought about symbolic constants and if there's any tricks you could do to support them. I think there might be, especially when still thinking about things in terms of just using faster linear algebra as a pre-processor to a symbolic solve. Aaron Meurer > > -- Shahriar > > On Thursday, August 31, 2023 at 6:48:24 PM UTC-4 asme...@gmail.com wrote: >> >> On Thu, Aug 31, 2023 at 5:07 AM Oscar Benjamin >> wrote: >> > >> > On Tue, 29 Aug 2023 at 07:09, Shahriar Iravanian >> > wrote: >> > > >> > > Hi All, >> > > >> > >> > Hi Shahriar, >> > >> > > I have uploaded a new package, hyint, to github and PyPi. It is a hybrid >> > > (symbolic-numeric) integration package on top of SymPy and numpy/scipy. >> > > I would appreciate it if it is added to the list of projects using SymPy. >> > > >> > > You can find it at https://github.com/siravan/hyint or install it as >> > > 'pip install hyint'. >> > > >> > > hyint uses an ansatz generation algorithm similar to the Risch-Bronstein >> > > poor man's integrator combined with a sparse regression algorithm >> > > adopted from the Sparse identification of nonlinear dynamics (SINDy) to
Re: [sympy] hyint: hybrid (symbolic-numeric) integration
On Thu, Aug 31, 2023 at 5:07 AM Oscar Benjamin wrote: > > On Tue, 29 Aug 2023 at 07:09, Shahriar Iravanian > wrote: > > > > Hi All, > > > > Hi Shahriar, > > > I have uploaded a new package, hyint, to github and PyPi. It is a hybrid > > (symbolic-numeric) integration package on top of SymPy and numpy/scipy. I > > would appreciate it if it is added to the list of projects using SymPy. > > > > You can find it at https://github.com/siravan/hyint or install it as 'pip > > install hyint'. > > > > hyint uses an ansatz generation algorithm similar to the Risch-Bronstein > > poor man's integrator combined with a sparse regression algorithm > > adopted from the Sparse identification of nonlinear dynamics (SINDy) to > > solve indefinite integration problems to univariate expressions. It can > > solve a large subset of standard elementary integrals despite a very small > > size (a few hundred lines of code). > > > > I'm one of the principal contributors to SymbolicNumericIntegartion.jl > > (https://github.com/SciML/SymbolicNumericIntegration.jl), which is a Julia > > package for symbolic-numeric integration and is the basis of hyint. > > This sounds excellent. Yes, you can add it to the list of projects > using SymPy using a pull request, I think to the website repo. > > How exactly is it different from Bronstein's poor man's integrator? > > SymPy has an integration algorithm called heurisch which is based on > the poor man's integrator but uses exact rather than approximate > solutions to the linear equations. Is exact vs approximate the main > distinction here between what hyint does and what heurisch does? Judging from the examples, it looks like it In: hyint.integrate(1 / (x**3 - 2*x + 1), x) Out: 2.17082039324994*log(x - 1) + 1.34164078649988*log(x + 1/2 + sqrt(5)/2) - 1.17082039324993*log(x**3 - 2*x + 1) And looking at the code, I'd say a difference is that the Bronstein algorithm is more rigorous and general in how it generates its ansatz. But actually one of the reasons heurisch() is so slow is that it can generate ansatz that are huge (especially when it's given an integrand that doesn't have an answer to begin with). Employing some heuristics like the ones used here in heurisch could help it out. Actually it wouldn't be much work to generalize this to something that gives an exact answer at least some of the time. For example, you could use nsimplify() to guess at exact values for numeric coefficients. As long as diff(answer) - integrand symbolically simplifies to 0 you know you have a correct answer. Aaron Meurer > > -- > Oscar > > -- > 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/CAHVvXxRyJ3FUZ1pN6GACMoHZBYGbUJAavKq5Y1RW5__1nFAT8w%40mail.gmail.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%3D6LxbG%2BZ_%2B9Q6jChaw7eQHm%2B%2BkGsbC47QyTbgN4i1wMrzw%40mail.gmail.com.
Re: [sympy] Blog post about the the future of SymPy
k**2/(k - 1) + k/(k - 1))**2 - 4*(-k**2/(k - 1) + k/(k - 1))*(2*k*(-k**2/(k - 1) + k/(k - 1))/(k - 1) + (-k**2/(k - 1) + k/(k - 1))**2) - 4*(-k**2/(k - 1) + k/(k - 1))*(2*k*(-k**2/(k - 1) + k/(k - 1))/(k - 1) + 2*(-k**2/(k - 1) + k/(k - 1))**2) + 5*(-k**2/(k - 1) + k/(k - 1))*(k**2*(-k**2/(k - 1) + k/(k - 1))/(k - 1)**2 + 2*k*(-k**2/(k - 1) + k/(k - 1))**2/(k - 1) + k*(2*k*(-k**2/(k - 1) + k/(k - 1))/(k - 1) + (-k**2/(k - 1) + k/(k - 1))**2)/(k - 1)))/(2*(1 - k)**2)) - k**2*x**2/(2*(1 - k)**2) + k**3*x**3/((1 - k)**2*(k - 1)) + O(x**10) >>> series(cos(k*x/(1-k*(1-k*x**2)/(1-x))),x,0,10).simplify() (-40320 + 362880*k - 1451520*k**2 + 20160*k**2*x**2 + 3386880*k**3 - 141120*k**3*x**2 + 40320*k**3*x**3 + 40320*k**3*x**4 + 40320*k**3*x**5 + 40320*k**3*x**6 + 40320*k**3*x**7 + 40320*k**3*x**8 + 40320*k**3*x**9 - 5080320*k**4 + 423360*k**4*x**2 - 241920*k**4*x**3 - 223440*k**4*x**4 - 161280*k**4*x**5 - 100800*k**4*x**6 - 40320*k**4*x**7 + 20160*k**4*x**8 + 80640*k**4*x**9 + 5080320*k**5 - 705600*k**5*x**2 + 604800*k**5*x**3 + 552720*k**5*x**4 + 194880*k**5*x**5 - 67200*k**5*x**6 - 248640*k**5*x**7 - 349440*k**5*x**8 - 369600*k**5*x**9 - 3386880*k**6 + 705600*k**6*x**2 - 806400*k**6*x**3 - 823200*k**6*x**4 + 107520*k**6*x**5 + 581336*k**6*x**6 + 685440*k**6*x**7 + 527520*k**6*x**8 + 208320*k**6*x**9 + 1451520*k**7 - 423360*k**7*x**2 + 604800*k**7*x**3 + 823200*k**7*x**4 - 564480*k**7*x**5 - 1024968*k**7*x**6 - 651504*k**7*x**7 + 30576*k**7*x**8 + 679056*k**7*x**9 - 362880*k**8 + 141120*k**8*x**2 - 241920*k**8*x**3 - 552720*k**8*x**4 + 672000*k**8*x**5 + 984648*k**8*x**6 + 53088*k**8*x**7 - 865033*k**8*x**8 - 1208256*k**8*x**9 + 40320*k**9 - 20160*k**9*x**2 + 40320*k**9*x**3 + 223440*k**9*x**4 - 369600*k**9*x**5 - 621656*k**9*x**6 + 430416*k**9*x**7 + 1073353*k**9*x**8 + 711752*k**9*x**9 - 40320*k**10*x**4 + 80640*k**10*x**5 + 268800*k**10*x**6 - 389760*k**10*x**7 - 675696*k**10*x**8 + 75936*k**10*x**9 - 60480*k**11*x**6 + 120960*k**11*x**7 + 278880*k**11*x**8 - 309120*k**11*x**9 - 80640*k**12*x**8 + 161280*k**12*x**9 + O(x**10))/(40320*(k**9 - 9*k**8 + 36*k**7 - 84*k**6 + 126*k**5 - 126*k**4 + 84*k**3 - 36*k**2 + 9*k - 1)) By computing matrix inverse (or series) using the polys, you can avoid the enormous expressions because the polys can only represent polynomials in the more simplified "expanded" form. So cancellation of terms happens automatically rather than being buried in the large expression in a way that can never actually reveal itself until you expand everything out. So the exact same principles that Oscar has been talking about apply to this series expansion. The main difference is that series expansions aren't used by as many other algorithms (they are used in limits, but that's about it), whereas matrices are used all over the place, so focusing on matrices for now can lead to bigger performance wins. Aaron Meurer > > It might be best if the result is assigned to a variable so as to > exclude the cost of converting it to a string. > > I am sure I am teaching my grandmother to suck eggs (not that either of > them ever did), but I hope you can see my point. > > 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/c4796186-9cfd-d0de-6e0e-5de3ad5c343f%40dbailey.co.uk. -- 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%3D6%2BrwXYPHVwQ37fZq%2B%2BUM4xtUnnaGRwLhGZhqs11bUEZkg%40mail.gmail.com.
Re: [sympy] Blog post about the the future of SymPy
On Wed, Aug 16, 2023 at 12:08 PM Aaron Meurer wrote: > > Thank you for the blog post Oscar. I submitted it to Hacker News as > well https://news.ycombinator.com/item?id=37150867 > > I agree with all the things you wrote. I agree with the idea of having > computation subsystems that are targeted and fast. This concept is > related to what James Powell calls a "restricted computational > domain". See https://twitter.com/dontusethiscode/status/1362809888360005636 > (unfortunately you need to be signed into Twitter to read that whole > thread. If you don't have an account you can read it here > https://web.archive.org/web/20210219170345/https://twitter.com/dontusethiscode/status/1362809888360005636). By the way, this talk in particular by James is very relevant to your work https://www.youtube.com/watch?v=Ix04KpZiUA8. I'd say your approach to making SymPy faster exactly lines up with the general framework for improving Python performance that he outlines in that talk. Aaron Meurer > > One thing I like about the polys module is that everything is > organized in layers, where the lower layers operate directly on data > structures and the top layer is designed for user interaction. The top > layer has things that are a little slower but more user friendly, like > type checking, which the bottom layers do not have. > > One of the reasons SymPy ended up the way it is is that there's really > only one symbolic system. This has made things very simple and makes > the whole thing quite easy for developers to work on, but it also > means that there's no distinction between lower level fast data > structures and higher level data structures. And in particular, it > means that slower abstractions like automatic evaluation have leaked > in which really should only ever be part of the top level layers. > > I look forward to reading the followup blog posts. > > Aaron Meurer > > On Wed, Aug 16, 2023 at 9:14 AM Oscar Benjamin > wrote: > > > > Hi all, > > > > I have written a blog post about recent work on SymPy and what I think > > should be future development plans: > > > > https://oscarbenjamin.github.io/blog/czi/post1.html > > > > This is the first in a series of posts and in this one I describe what > > I think are the core parts of SymPy and outline from a high level what > > I think should be done going forwards. Subsequent posts will describe > > specific components in more detail. > > > > Oscar > > > > -- > > 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/CAHVvXxTNyu8eXUZM_SesY7DAkUbpeFd--55wzkF4opfZ1jYeUg%40mail.gmail.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%3D6Jyu1tK16aA5cuL%3Dh08hH4pCefDv8hmVf9-Zo6TiyiovA%40mail.gmail.com.
Re: [sympy] Blog post about the the future of SymPy
Thank you for the blog post Oscar. I submitted it to Hacker News as well https://news.ycombinator.com/item?id=37150867 I agree with all the things you wrote. I agree with the idea of having computation subsystems that are targeted and fast. This concept is related to what James Powell calls a "restricted computational domain". See https://twitter.com/dontusethiscode/status/1362809888360005636 (unfortunately you need to be signed into Twitter to read that whole thread. If you don't have an account you can read it here https://web.archive.org/web/20210219170345/https://twitter.com/dontusethiscode/status/1362809888360005636). One thing I like about the polys module is that everything is organized in layers, where the lower layers operate directly on data structures and the top layer is designed for user interaction. The top layer has things that are a little slower but more user friendly, like type checking, which the bottom layers do not have. One of the reasons SymPy ended up the way it is is that there's really only one symbolic system. This has made things very simple and makes the whole thing quite easy for developers to work on, but it also means that there's no distinction between lower level fast data structures and higher level data structures. And in particular, it means that slower abstractions like automatic evaluation have leaked in which really should only ever be part of the top level layers. I look forward to reading the followup blog posts. Aaron Meurer On Wed, Aug 16, 2023 at 9:14 AM Oscar Benjamin wrote: > > Hi all, > > I have written a blog post about recent work on SymPy and what I think > should be future development plans: > > https://oscarbenjamin.github.io/blog/czi/post1.html > > This is the first in a series of posts and in this one I describe what > I think are the core parts of SymPy and outline from a high level what > I think should be done going forwards. Subsequent posts will describe > specific components in more detail. > > Oscar > > -- > 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/CAHVvXxTNyu8eXUZM_SesY7DAkUbpeFd--55wzkF4opfZ1jYeUg%40mail.gmail.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%3D6KXWRdsSYU9EmUmWTnOhCxhzB%3D_x38uJoE9ZpJjfJBUhQ%40mail.gmail.com.
Re: [sympy] Sympy webpage repository
Everyone with push access to SymPy also has access to the website repo. I think the website tends to get ignored relative to SymPy because it isn't as interesting to most people, and also because as you noticed, it tends to get a lot of low quality pull requests that don't really add much value. There's also, unfortunately, an issue currently with the website repo where the GitHub actions deploy script is broken (see https://github.com/sympy/sympy.github.com/pull/187). That should be fixed before any further PRs are merged, or else it will break the website. Aaron Meurer On Mon, Aug 14, 2023 at 5:37 AM Greg Vernon wrote: > > It seems to me that Sympy's webpage GitHub repository > (https://github.com/sympy/sympy.github.com) could use a bit more attention > from maintainers. There are tiny MRs that are over a year old that have nary > a comment on them regarding whether they'll ever be merged. One MR from > March of 2022 simply updates the copyright year from 2021 to 2022... and now, > 1.5 years later it's not merged, has had zero commentary, and obviously is > now out of date. > > Copyright MR: https://github.com/sympy/sympy.github.com/pull/170 > > Another MR from 2021 adds an exclamation mark to text on the 404 page. I > personally don't think an exclamation mark is warranted, but no maintainers > have so much as commented on the MR (let alone reject it). > > 404 ! MR: https://github.com/sympy/sympy.github.com/pull/164 > > Another MR from this May proposes adding a colon to separate clauses. It's > probably a good MR, but again... nothing > > Semicolon MR: https://github.com/sympy/sympy.github.com/pull/188 > > And then there are MRs that are so old (2011) that they should just be closed. > > Old MR: https://github.com/sympy/sympy.github.com/pull/28 > > Is the issue that we need more maintainers? Who are the maintainers? > > > -- Greg > > -- > 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/1c504e39-a722-406a-b056-ccf6369fd45bn%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%3D6K9BLqc9wDOVkasF5OEzv2GUk8SE%2BTqMcgfYtipbcpmtg%40mail.gmail.com.
Re: [sympy] SymPy numbers and NumPy interoperability
I don't know why Oscar closed that issue. NumPy does have a lot of methods for defining how custom objects interact with it. I did some basic tests and it seems like adding __array__ to Number would do exactly what we want here. Aaron Meurer On Fri, Jul 28, 2023 at 2:37 AM Idan Pazi wrote: > > Issue: > SymPy numbers and NumPy interoperability · Issue #25432 · sympy/sympy > (github.com) > So it seems like there is no nice solution for this currently, and changes > are needed in NumPy. > > On Wednesday, 26 July 2023 at 20:50:45 UTC+3 asme...@gmail.com wrote: >> >> In general, using SymPy expressions with NumPy functions is not >> supported, but I think it does make sense to make Number classes >> (Integer, Float, Rational) work. Can you open an issue about this at >> https://github.com/sympy/sympy/issues. >> >> I don't know exactly what needs to be done to make this work. >> Hopefully NumPy provides the proper hooks. Ideally, Rational and Float >> would be converted to np.float64 and Integer would be converted to >> np.int64 when used in functions like linspace. Although changing this >> could potentially be an issue if people are using numpy arrays of >> Rational currently (which I wouldn't necessarily recommend). >> >> Aaron Meurer >> >> On Wed, Jul 26, 2023 at 11:37 AM Idan Pazi wrote: >> > >> > Hello, >> > Is there a way I could configure NumPy or SymPy so that NumPy functions >> > would accept SymPy numbers (e.g. sympy.Rational)? >> > >> > For example: >> > >>> import numpy as np >> > >>> import sympy >> > >>> np.linspace(0, sympy.Rational(1,2), 2) >> > Traceback (most recent call last): >> > File "", line 1, in >> > File "<__array_function__ internals>", line 180, in linspace >> > File >> > "C:\Users\idank\mambaforge\lib\site-packages\numpy\core\function_base.py", >> > line 130, in linspace >> > dt = result_type(start, stop, float(num)) >> > File "<__array_function__ internals>", line 180, in result_type >> > TypeError: Cannot interpret '0.500' as a data type >> > >> > >>> np.isnan(sympy.Rational(1,2)) >> > Traceback (most recent call last): >> > File "", line 1, in >> > TypeError: ufunc 'isnan' not supported for the input types, and the inputs >> > could not be safely coerced to any supported types according to the >> > casting rule ''safe'' >> > >> > Background: >> > I'm using IPython+SymPy+NumPy as a calculator. >> > For convenience, I automatically convert all divisions and floats to >> > sympy.Rational >> > (and display results both as fractions and as decimals) >> > After such conversions stuff like np.log(2.33) fails. >> > For more details, see - https://github.com/idanpa/calcpy >> > >> > (SymPy version 1.12, NumPy version 1.25.1) >> > >> > Thanks! >> > Idan >> > >> > -- >> > 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/208b8d87-9e7b-4fe9-86fc-9575a0b57002n%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/c5abf9ae-7c65-4935-9685-3791da6fa20an%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%3D6%2BGCh4BpDf48BCbF4ZuSbtjqQsjo-bw0fB2jirip81QQg%40mail.gmail.com.
Re: [sympy] SymPy numbers and NumPy interoperability
In general, using SymPy expressions with NumPy functions is not supported, but I think it does make sense to make Number classes (Integer, Float, Rational) work. Can you open an issue about this at https://github.com/sympy/sympy/issues. I don't know exactly what needs to be done to make this work. Hopefully NumPy provides the proper hooks. Ideally, Rational and Float would be converted to np.float64 and Integer would be converted to np.int64 when used in functions like linspace. Although changing this could potentially be an issue if people are using numpy arrays of Rational currently (which I wouldn't necessarily recommend). Aaron Meurer On Wed, Jul 26, 2023 at 11:37 AM Idan Pazi wrote: > > Hello, > Is there a way I could configure NumPy or SymPy so that NumPy functions would > accept SymPy numbers (e.g. sympy.Rational)? > > For example: > >>> import numpy as np > >>> import sympy > >>> np.linspace(0, sympy.Rational(1,2), 2) > Traceback (most recent call last): > File "", line 1, in > File "<__array_function__ internals>", line 180, in linspace > File > "C:\Users\idank\mambaforge\lib\site-packages\numpy\core\function_base.py", > line 130, in linspace > dt = result_type(start, stop, float(num)) > File "<__array_function__ internals>", line 180, in result_type > TypeError: Cannot interpret '0.500' as a data type > > >>> np.isnan(sympy.Rational(1,2)) > Traceback (most recent call last): > File "", line 1, in > TypeError: ufunc 'isnan' not supported for the input types, and the inputs > could not be safely coerced to any supported types according to the casting > rule ''safe'' > > Background: > I'm using IPython+SymPy+NumPy as a calculator. > For convenience, I automatically convert all divisions and floats to > sympy.Rational > (and display results both as fractions and as decimals) > After such conversions stuff like np.log(2.33) fails. > For more details, see - https://github.com/idanpa/calcpy > > (SymPy version 1.12, NumPy version 1.25.1) > > Thanks! > Idan > > -- > 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/208b8d87-9e7b-4fe9-86fc-9575a0b57002n%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%3D6L4nAGF%3DYOxoTna7hDfU2UwBaWU94%2B36jUkeT-xqfPWew%40mail.gmail.com.
Re: [sympy] Can I splice Symbols into Symbols? Returning None
Your code kind of defeats the whole purpose of using SymPy. You are
creating one single Symbol that represents your entire expression.
Symbol is supposed to represent variables, and expressions should be
made with the various expression classes, like sympy.And, sympy.Or,
sympy.Implies, and sympy.Equivalent, or the equivalent logical
operators like & and |. If you have a single symbol named "x⟷y" then
you can't do anything with it, but if you have Equivalent(Symbol('x'),
Symbol('y')) then you can perform logical operations on it. See
https://docs.sympy.org/latest/modules/logic.html
As a general rule of thumb, if you find yourself doing mathematical
operations using string manipulation, that means you are using SymPy
wrong. SymPy is designed to do mathematical operations directly, and
doesn't work by operating on strings.
Aaron Meurer
On Sun, Jul 23, 2023 at 2:41 AM Nick wrote:
>
> I am trying to expand my program that accelerates my ability to solve math
> and logical problems by hand by generating not too complicated problems to
> practice on. The use case of my program is demonstrated on my twitter and the
> working code is my github.
>
> I think my issue lies at line like 40 and 43.
>
> Broken Code Pastebin
>
> As you can see, I can generate and display logical equations in LaTeX using
> binary literals. The trouble is expanding these simple generations into more
> complex expressions. I am trying to rewrite a new Symbol using previously
> generated Symbols by string slicing.
>
> -Nick
>
>
> Reference:
>
> Chang and Lee . Computer Science and Applied Mathematics. "Symbolic Logic and
>
> Mechanical Theorem Proving." Academic Press, Inc. 1973. Page 13-15.
>
> --
> 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/ca70ada2-e57e-4ed9-bf89-ddba72cf38b7n%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%3D6Lzrf7q%3DOr%2BkU5_mCtoWTgBSQ2asuWHJZ86xVtJz24u%2Bw%40mail.gmail.com.
Re: [sympy] We should rename 'master' to 'main'
On Tue, Jul 18, 2023 at 6:22 AM Oscar Benjamin
wrote:
>
> I've been wondering for a long time now when someone would bring this up.
>
> Having watched this discussion play out in cpython I definitely do not
> want to import that kind of furious debate to the SymPy mailing list
> but I will just say that the use of the word master in this context is
> not really "agreed" to be politically offensive: there is definitely
> not a consensus on this.
>
I'm also not interested in having the political discussion here. The
politics are basically irrelevant at this point anyway because
everyone else is already moving to main, and it's the default for all
new repos on GitHub. So it's really just a question of what needs to
be done for us to do that too.
On Tue, Jul 18, 2023 at 6:35 AM Oscar Benjamin
wrote:
>
> This is the main reason that I have deliberately not brought this up
> before.
It's also why I never brought it up. We could do something like create
a master branch that automatically synchronizes with main. That would
help people who pull master and never realized we switched to main.
But it would also confuse a lot of people. I'm also not completely
sure how to set something like that up.
We could also push a commit to master that does something like
# in sympy/__init__.py
raise ImportError("The SymPy development branch has been renamed from
'master' to 'main'. It looks like you have been pulling commits from
the 'master' branch, but you need to start pulling commits from the
'main' branch instead. See https:... for more details")
But again, the fact that 'master' would still be there alongside main
could itself still confuse people.
I myself have been caught before by a project switching to main and
not realizing that my pull on an old clone wasn't actually doing
anything. I know enough about git and the master/main switch to
quickly figure out what was going on, but a person who is less
experienced would have taken longer to. So if there is a simple way to
do something about this, we should try to.
Another thing of interest is the symbolic-ref git command, which lets
you alias one branch name to another. So something like 'git
symbolic-ref refs/heads/master refs/heads/main' would make 'master' be
an alias to 'main' (or the reverse if you switch the arguments).
That's useful if you find some repos using master and others using
main to be confusing.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BMEiTVWVcgL-r%2BOb1Ha4axBAao8HDXT1BtuMpKEGOSuw%40mail.gmail.com.
Re: [sympy] We should rename 'master' to 'main'
I'm not opposed to doing this. Most other projects have also done it, so it would be inline with that. It also has the advantage that "main" is a much clearer term to newbies than "master". But note that this is not a trivial thing to do, which is why it hasn't happened yet. It's not as simple as just renaming the branch. We also have to fix all the references to "master" everywhere, including making sure that all our automation and release scripts still work. There's also an unfortunate downside of doing this, which is that anyone who already has a clone of the repo and is using "git checkout master; git pull" will have their workflows broken when master stops being updated. I don't know if there's a clean way we can do anything about that. Aaron Meurer On Mon, Jul 17, 2023 at 9:25 PM Sangyub Lee wrote: > > I think that github decided to do that in 2020. > And the main reason to do this is that 'master' is agreed to be politically > offensive terminology: > > Rename offensive terminology (master) - Simon Pieters (kernel.org) > > -- > 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/8037a96f-4d4c-48ca-9139-56bec7f5217en%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%3D6%2BXo0N89GQb%2BzHHjCSW%3DA-gkmMsnDEOi0ene7r%3DfOXBhQ%40mail.gmail.com.
Re: [sympy] Re: ChatGPT and SymPy
I'm hopeful that this will. It seems to automatically go for SymPy whenever faced with a math problem, or at least one that uses symbolic math (it also uses NumPy when it can). The only downside is that the code interpreter hides the code by default, so people won't be able to see that it is using SymPy unless they click the button to show the code that ChatGPT generated. It might end up that a lot of people end up using SymPy with it but most of them never actually realize it. Aaron Meurer On Mon, Jul 17, 2023 at 1:56 AM Francesco Bonazzi wrote: > Nice. Are there any chances that ChatGPT may add visibility to SymPy? I > feel like a lot of people who could be potential users of SymPy don't know > of SymPy's existence. > > On Monday, July 10, 2023 at 4:35:00 p.m. UTC+2 Aaron Meurer wrote: > >> Interesting update on this. I asked ChatGPT with code interpreter the >> exact same query. It automatically generated SymPy code and ran it to get >> the correct answer >> https://chat.openai.com/share/5be9ab93-135f-4a47-a36a-a09979e93954 >> >> Aaron Meurer >> >> On Wed, Dec 14, 2022 at 4:45 PM Aaron Meurer wrote: >> >>> I've seen many examples on Twitter and elsewhere of chatgpt doing >>> terribly on actual mathematics. I instead asked it to "Find the extreme >>> values of the function x^3 + 5x^2 + 3x - 9". It got the first part with the >>> derivative and the quadratic equation correct, but then did faulty >>> arithmetic when plugging the values back into the expression (the correct >>> values are 0 and -256/27). It makes a sign error and also gets the addition >>> wrong even with the wrong sign. >>> >>> My hope is that tools like SymPy can be used as oracles for tools like >>> GPT to help them verify their mathematics. Obviously in this case you don't >>> need SymPy to just verify arithmetic, but I've also seen it do just as >>> poorly on symbolic algebra problems. >>> >>> I've also pasted the full log below: >>> >>> [image: Screen Shot 2022-12-14 at 3.41.32 PM.png] >>> [image: Screen Shot 2022-12-14 at 3.41.42 PM.png] >>> >>> To find the extreme values of a function, we need to find the critical >>> points of the function, which are the points at which the derivative of the >>> function is equal to 0 or does not exist. >>> >>> The derivative of the function x^3 + 5x^2 + 3x - 9 is 3x^2 + 10x + 3. To >>> find the critical points, we need to solve the equation 3x^2 + 10x + 3 = 0. >>> >>> To solve this equation, we can use the quadratic formula: >>> >>> x = (-b ± √(b^2 - 4ac)) / 2a >>> >>> where a, b, and c are the coefficients of the quadratic equation ax^2 + >>> bx + c = 0. In our case, a = 3, b = 10, and c = 3, so the formula becomes: >>> >>> x = (-10 ± √(10^2 - 4 * 3 * 3)) / 2 * 3 >>> >>> = (-10 ± √(100 - 36)) / 6 >>> >>> = (-10 ± √(64)) / 6 >>> >>> = (-10 ± 8) / 6 >>> >>> = (-18, -2) / 6 >>> >>> = (-3, -1/3) >>> >>> These are the critical points of the function x^3 + 5x^2 + 3x - 9. >>> >>> To find the extreme values of the function, we need to evaluate the >>> function at these critical points and at any points where the derivative >>> does not exist. In this case, the derivative exists for all values of x, so >>> we only need to evaluate the function at the critical points. >>> >>> If we plug in the critical points into the function, we get: >>> >>> x^3 + 5x^2 + 3x - 9 = (-3)^3 + 5(-3)^2 + 3(-3) - 9 = -27 + 45 + 9 - 9 = 8 >>> >>> and >>> >>> x^3 + 5x^2 + 3x - 9 = (-1/3)^3 + 5(-1/3)^2 + 3(-1/3) - 9 = -1/27 + 5/9 + >>> 1 - 9 = 5/9 - 1/27 - 8/9 = -64/27 >>> >>> The extreme values of the function x^3 + 5x^2 + 3x - 9 are 8 and -64/27. >>> >>> On Wed, Dec 14, 2022 at 3:35 PM gu...@uwosh.edu wrote: >>> >>>> Just for some additional perspective. I have also tried this on some >>>> general chemistry word problems. In general, I see it getting basic one >>>> logical step processes correct (e.g. a single step dilution or grams -> >>>> moles). Things with multiple steps or requiring understanding the physical >>>> situation it does poorly on. That said, I think it does better than some of >>>> my weakest students. It does not seem to be able to use significant figures >>>> in computations (also a problem for my weaker students). >>>> >>>>
Re: [sympy] Zeilberger's algorithm + documentation
If it's not too hard to separate them that might be better just because the documentation pull request will probably be able to be merged much quicker and the Zeilberger algorithm may require more review changes before it can be merged. Aaron Meurer On Fri, Jul 14, 2023 at 8:39 AM robert@gmail.com wrote: > > Dear SymPy community, > > I recently wrote a sympy implementation of Zeilberger's algorithm and > improved the writing of the documentation in the concrete module. These have > similar themes / change related files but are disjoint. Would the project > prefer these patches to be in separate pull requests or one? > > Robert > > -- > 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/d514abd4-bb2c-423f-9a6c-f11aeaf4f08en%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%3D6LTT%2BAGsn_%3DRNXWqQB5ReBwQZj5Q_gymvo%3DV6n96OErrw%40mail.gmail.com.
Re: [sympy] Easy way to use S()
On Thu, Jul 6, 2023 at 4:15 PM David Bailey wrote:
>
> On 05/07/2023 21:40, Aaron Meurer wrote:
> > For interactive use, just passing a string to S() (or equivalently
> > sympify() or parse_expr()) is the simplest way to deal with this.
> > However, I would avoid this for non-interactive usage (i.e., any code
> > that gets saved to be executed later). Putting your expression in a
> > string breaks the ability for Python to parse it directly, meaning
> > things like simple syntax errors won't be caught until the code gets
> > run.
> >
> > You should also be very careful when doing this if you use
> > assumptions. S("x + 1") will create a symbol x with the default
> > assumptions. If you already defined x with assumptions, like
> >
> > x = symbols('x', real=True)
> >
> > then this will be a *different* symbol. For example:
>
> Thanks for that caution, Aaron,
>
> This whole problem reminds me vaguely of a friend of mine that bought an
> early Sinclair calculator. He discovered that ln(2) was seriously
> inaccurate, so he wrote to them. They replied that there was nothing
> wrong with his calculator, he had just chosen an unfortunate example!
>
> What I'm trying to say is that there must be people out there who gave
> given up on SymPy after discovering what it does to 1/2*x, or worse
> still, got an error in their work (particularly if using Python 2).
No one should be using Python 2 at this point. So fortunately that
particular headache is behind us.
>
> Thinking about it, I can see how hard it is to do something really
> effective about this problem, but couldn't you prevail on the Python
> term to insert a hook in the Python parser to make it possible to change
> an input string before Python parses it and applies its integer division
> rule?
That particular way of solving the problem would very likely be
rejected. It's basically equivalent to adding macros to the language,
which has been rejected multiple times before.
I have wondered if it wouldn't be possible for Python to keep track of
how purely numeric constants are created at compile time and store
that information on the constant. Since it would only apply to pure
numbers and would only happen at compile time, it would have basically
no runtime penalties. That would also allow something like
1.001, which automatically truncates to 1.0, to create
sympy.Float('1.001'). But it's only a vague idea I've
ruminated on and I haven't written to the core Python team about it.
Aaron Meurer
>
> 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/d6b19b21-d61c-e4f8-3116-f5f64ac6ab48%40dbailey.co.uk.
--
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%3D6LXNmwPMEc8Kaixa0dxrd3bV8R%3DHJQxXqSz43w3aXu8nQ%40mail.gmail.com.
Re: [sympy] Easy way to use S()
For interactive use, just passing a string to S() (or equivalently
sympify() or parse_expr()) is the simplest way to deal with this.
However, I would avoid this for non-interactive usage (i.e., any code
that gets saved to be executed later). Putting your expression in a
string breaks the ability for Python to parse it directly, meaning
things like simple syntax errors won't be caught until the code gets
run.
You should also be very careful when doing this if you use
assumptions. S("x + 1") will create a symbol x with the default
assumptions. If you already defined x with assumptions, like
x = symbols('x', real=True)
then this will be a *different* symbol. For example:
>>> x = symbols('x', real=True)
>>> expr = S("x + 1")
>>> x + expr
x + x + 1
This can lead to all sorts of confusion. So really only use string
input if you are very careful about these issues.
Aaron Meurer
On Mon, Jul 3, 2023 at 6:25 AM Oscar Benjamin
wrote:
>
> On Mon, 3 Jul 2023 at 00:16, David Bailey wrote:
> >
> > On 02/07/2023 23:44, Oscar Benjamin wrote:
> > > On Sun, 2 Jul 2023 at 23:06, David Bailey wrote:
> > >> Dear Group,
> > >>
> > >> If I want to enter m+1/2, I define m as a symbol and write:
> > >>
> > >>m+S(1)/2.
> > >>
> > >> However if I have a complicated expression with lots of fractions, such
> > >> as:
> > >>
> > >> 1 + x*(m + 1/2)/(2*m + 1) + x**2*(m + 1/2)*(m + 3/2)/(2*(2*m + 1)*(2*m +
> > >> 2))
> > >>
> > >> it would be much neater if I could automatically wrap all the integers
> > >> in S so that no floating point numbers get introduced.
> > >>
> > >> Is that feasible? I did try wrapping the whole expression in S, but that
> > >> does not work.
> > > You can wrap the whole expression in nsimplify:
> > >
> > > >>> e = 1 + x*(m + 1/2)/(2*m + 1) + x**2*(m + 1/2)*(m + 3/2)/(2*(2*m
> > > + 1)*(2*m + 2))
> > > >>> print(e)
> > > x**2*(m + 0.5)*(m + 1.5)/((2*m + 2)*(4*m + 2)) + x*(m + 0.5)/(2*m + 1)
> > > + 1
> > > >>> print(nsimplify(e))
> > > x**2*(m + 1/2)*(m + 3/2)/((2*m + 2)*(4*m + 2)) + x*(m + 1/2)/(2*m + 1)
> > > + 1
> > >
> > > The nsimplify function will attempt to guess what rational number a
> > > float represents. In your example this is easy because all floats are
> > > exactly represented in binary (having only twos in the denominator)
> > > but otherwise the conversion can be inexact:
> > >
> > > >>> f = 1/3
> > > >>> f
> > > 0.
> > > >>> print(Rational(f)) # exact value of the binary float
> > > 6004799503160661/18014398509481984
> > > >>> nsimplify(f) # probably the value that the float was intended to
> > > have
> > > 1/3
> > >
> > Thanks Oscar for that incredibly fast reply, but I'm not super keen on
> > algebra that is only probably correct!
>
> Agreed but that means that you need to avoid creating floats in the
> first place. Many users find it awkward to do this and prefer to use
> nsimplify.
>
> Another option is to call S with a string::
>
> In [27]: s = '1 + x*(m + 1/2)/(2*m + 1) + x**2*(m + 1/2)*(m +
> 3/2)/(2*(2*m + 1)*(2*m + 2))'
>
> In [28]: print(S(s))
> x**2*(m + 1/2)*(m + 3/2)/((2*m + 2)*(4*m + 2)) + x*(m + 1/2)/(2*m + 1) + 1
>
> --
> Oscar
>
> --
> 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/CAHVvXxT4LpkgZfdiKrvzxxENB24cRKUUx88ZLeBKp8ZZwsKJhA%40mail.gmail.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%3D6%2BaT%2BAs7Azyi1BCcrBz7B9rKfOOw2vX5KWu2njdL%3D5fOQ%40mail.gmail.com.
[sympy] Introducing Diane Tchuindjo to the project
Hi everyone. As many of you may know, I work at Quansight, a company that works with and funds a lot of open source work in the Python ecosystem. Quansight Labs has a yearly internship program where interns work on various open source projects. I'm happy to announce that this summer, Diane Tchuindjo will be interning at Quansight Labs to work on SymPy. Her project will be to introduce Hypothesis into the SymPy test suite. Everyone join me in welcoming Diane to the project. You can read more about the project here https://github.com/sympy/sympy/issues/20914. Basically, hypothesis (https://hypothesis.readthedocs.io/en/latest/) is a Python testing library that uses property based tests. This lets you write tests that take generic inputs and test functions using exact mathematical properties, rather than only testing explicit inputs and outputs. For example, to take an example from the issue, a Hypothesis test for factorint() might look like from hypothesis import given from hypothesis.strategies import integers @given(integers()) def test_factorint(x): f = factorint(x) assert Mul(*[b**e for b, e in f.items()]) == x for b in f: assert abs(b) in [0, 1] or isprime(b) (as opposed to the existing factorint tests, which just test explicit inputs and outputs https://github.com/sympy/sympy/blob/master/sympy/ntheory/tests/test_factor_.py#L168). This test generates an integer, runs factorint() on it, and tests that the result is mathematically correct (i.e., that the factors are prime and multiply back together to the original integer). This is somewhat like random testing, except Hypothesis is actually a lot more sophisticated than a purely random test, because it always tries to generate interesting examples, and it also does things like shrinking test inputs, and makes input strategies easy to compose. In my experience, Hypothesis is *really* good at finding bugs that you would otherwise never find. Hypothesis has always been a good fit for SymPy, but we've as of yet never used it. Our plan is to start small, to prove its usefulness, but I'm confident we will be able to convince the SymPy community that Hypothesis is a tool that we should be using regularly in the SymPy test suite. 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Js_3keq-UcmRQDaVtu2mhagBgVauTBpS%3DKyO4vYSWQ3A%40mail.gmail.com.
Re: [sympy] Inconsistency between mathematical functions
The automatic evalf logic in Function only calls evalf if every argument is a float. It wasn't really designed for functions like besselj where one argument is supposed to be an integer. It should probably be updated to also automatically evalf if one argument is a float and the rest are integers. Aaron Meurer On Mon, Jun 19, 2023 at 5:29 PM David Bailey wrote: > > I wonder if anyone here can explain why some mathematical functions - > e.g. sin and gamma evaluate completely if given a floating point > argument, while others such as besselj(0,0.2) only evaluate completely > if .evalf() is used. > > Is this behaviour intentional? > > Best Wishes, > > 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/5da9b23e-4e62-9ff4-c643-8aa973b379c8%40dbailey.co.uk. -- 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%3D6Luo60%2BwxYeNMvyb_%2B1qmAt%2BGpiH5f82%3DdCCJJ22mnoHQ%40mail.gmail.com.
Re: [sympy] Re: Code generation for dynamic size arrays
It looks like the code that automatically does contractions is messing
with what you are trying to do here.
What I would try doing is using the sympy.codegen classes to construct
the loop you want. You can then print this directly using
contract=False to disable the automatic contraction. For example
>>> from sympy.codegen import For, CodeBlock, Assignment
>>> print(ccode(For(i, Range(m), CodeBlock(Assignment(K[i], M[i]*N[i]))),
>>> contract=False))
for (i = 0; i < m; i += 1) {
K[i] = M[i]*N[i];
}
Unfortunately, the sympy.utilities.codegen classes currently do not
know about the sympy.codegen classes. The idea is to eventually
replace everything with the sympy.codegen ast nodes.
Aaron Meurer
On Tue, Jun 13, 2023 at 12:45 AM Morten Olsen Lysgaard
wrote:
>
> Ah, there is an inconsistency in the above email. I am saying I want
> dot-product, when in reality, what I want is an elementwise multiplication.
> The same question still applies though. Is this something Sympy can do?
>
> On Tuesday, 13 June 2023 at 06:28:52 UTC+2 Morten Olsen Lysgaard wrote:
>>
>> I am using Sympy for code generation.
>>
>> I would like to figure out the boundaries of what Sympy can do with respect
>> to code generation for dynamically sized arrays.
>>
>> Let's say I would like to generate a simple dot-product C-function.
>>
>> void dot(int m, const double *A, const double *B, double *C) {
>> for(int i=0; i> C[i] = A[i]*B[i];
>> }
>> }
>>
>> Using `sympy.Matrix` I am able to generate a loop-unrolled version of this
>> function for a fixed `m`, but this is not what I want. I want the general
>> thing.
>>
>> I have been trying to get this working using `IndexedBase` et. al. but no
>> luck. This is the closest I have gotten:
>>
>> import sys
>> import sympy as sp
>> import sympy.utilities.codegen
>> from sympy.utilities import codegen
>>
>> m = sp.symbols('m', integer=True)
>> i = sp.Idx('i', m)
>> M = sp.IndexedBase('M', shape=(m))
>> N = sp.IndexedBase('N', shape=(m))
>> K = sp.IndexedBase('K', shape=(m))
>> dot =sp.Eq(K[i], M[i]*N[i])
>>
>> rut_obj = codegen.make_routine('dot', dot, (m, M, N, K), language='C')
>> rcg = codegen.CCodeGen()
>> rcg.dump_c([rut_obj], sys.stdout, '')
>>
>> But it outputs spurious loops which I can not explain, and will not compute
>> the correct answer:
>>
>> void dot(int m, double *M, double *N, double *K) {
>>for (int i=0; i> K[i] = 0;
>>}
>>for (int i=0; i> for (int i=0; i> K[i] = K[i] + M[i]*N[i];
>> }
>>}
>> }
>>
>> Is there anyone that are able to generate a simple dot-product function like
>> the one in the top of my email using Sympy code generation?
>>
>> Any help would be greatly appreciated!
>
> --
> 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/7a5e17dd-91c2-4988-83d9-2a6e83b8b1b3n%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%3D6%2B4hOPk822pu7wV8zYhRRUdv-_7Uu9wq3%2BghgfNRg-RcA%40mail.gmail.com.
Re: [sympy] Simplify expressions involving complex numbers
On Tue, May 23, 2023 at 7:21 AM Oscar Benjamin wrote: > On Tue, 23 May 2023 at 06:51, Paul Royik wrote: > > > > How do I simplify the following expressions: i**(-2*i), (-i)**(-2*i), > ((-sqrt(3) - i)/2)**(-2*i), ((sqrt(3) - i)/2)**(-2*i) ? > > > > Is there any built-in function? > > > > For example, i**(-2*i) should give e^pi and ((sqrt(3) - i)/2)**(-2*i) > should give e^(-pi/3). > > The word "simplify" is ambiguous but I assume from your examples that > In this case, there's a fairly unambiguous meaning for 'simplify'. The expressions are all real, so they should be reexpressed without using i. Aaron Meurer what you want is to rewrite powers as exponentials if possible. If so > that can be done with e.rewrite(exp): > > >>> from sympy import * > >>> i = I > >>> a = i**(-2*i), (-i)**(-2*i), ((-sqrt(3) - i)/2)**(-2*i), ((sqrt(3) - > i)/2)**(-2*i) > >>> [ai.rewrite(exp) for ai in a] > [exp(pi), exp(-pi), exp(-5*pi/3), exp(-pi/3)] > > -- > Oscar > > -- > 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/CAHVvXxSjECmJoTVL6SJ27uzYrXHOWUiqKaMTK0gW6LfJXJrsfQ%40mail.gmail.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%3D6LKcWWMGXbe2fRYk2WRzzsgoB5iAQTa9VdKHokrNne5dQ%40mail.gmail.com.
[sympy] 2023 GSoC Projects Announced
Hi everyone. As many of you may have noticed, Google has announced the results for Google Summer of Code. I am proud to announce that 5 people have been accepted to work on SymPy this year. The following projects have been accepted: Contributor, Project: Mentors Abhishek Patidar, "Improving Polynomial GCD". Mentors: Oscar Benjamin and Kalevi Suominen Anurag Surendra Bhat, "Improving And Expanding Functionalities Of SymPy's Control Module". Mentors: Smit Lunagariya, Jason Moore, and Nikhil Maan Ishan Pandhare, "Extending Continuum mechanics module: Introducing classes for Cables and Improving the Truss class". Mentors: Prakhar Saxena and Advait Pote Tilo Reneau-Cardoso, "Improving Relational Assumptions in SymPy’s New Assumptions". Mentors: Aaron Meurer and Francesco Bonazzi Tirthankar Mazumder, "Rewrite LaTeX Parser".Mentors: Francesco Bonazzi and Aaron Meurer Join me in congratulating them on their acceptance. To everyone who was accepted, you should be receiving an email from your mentors soon to discuss how you will be communicating over the summer about your project. You should meet with your mentors about once a week during the summer to go over your progress. You should either meet on a public channel (like Gitter), or else post minutes of your meeting in some public channel, so that the whole community can see your progress too. Note that in many cases you may interact with some mentors as your primary mentors, and other mentors will be backup mentors. Please contact the backup mentors if you are not able to get ahold of your primary mentor(s). If you cannot get ahold of either, please let me and Oscar Benjamin (oscar.j.benja...@gmail.com) know immediately. I would like all of us to strongly encourage students to submit pull requests early and often. This will go a long ways towards making sure that you don't end the summer with a ton of code written that never gets merged. Students should help review pull requests by other students, so that we don't get bogged down reviewing so much code. We also require that all students keep a weekly blog of their work over the summer. If you don't already have a blog, you should start one. I recommend using either Wordpress, Blogger, or creating your own blog on GitHub pages. If you are savvy enough to set it up, I recommend GitHub pages, but if you aren't, both Wordpress and Blogger are good enough. The GSoC coding period officially starts May 29 (https://developers.google.com/open-source/gsoc/timeline). I would like to thank all the students who applied this year and everyone who submitted a patch. I would also like to thank all the mentors for helping review patches and proposals. This summer is looking to be another very productive one for SymPy, and I look forward to it! 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LEC9Fj3KhU3GOLrHU80O3cXor4Hzo9J5TAbFrWu8P33g%40mail.gmail.com.
Re: [sympy] Unexpanded coefficients of a polynomial
Poly is designed to expand all polynomials out. If you just want the terms of an expression as you've written it you can use Add.make_args(). I wouldn't really call these the "coefficients" of the expression though. Aaron Meurer On Thu, Apr 27, 2023 at 11:02 AM Paul Royik wrote: > > Hello. > > How can I get all unexpanded coeffs of a polynomial? > > For example, Poly(360*x*y**71*(y**72 - 1)**4 + 360*x**4*(x**5 - 1)**71, > x).all_coeffs() should return [360*y**71*(y**72 - 1)**4, 360*x**4*(x**5 - > 1)**71], but, instead, it returns expanded long expression. > > How to avoid this and return untouched coeffs? > > Thank you. > > -- > 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/eda7343d-f557-48b2-85e0-d52162a12bb5n%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%3D6J9gJvbDpJzgcsLZ7X7U92F%2Bk1F54bC4QSF%2Bjueh%3DQBBA%40mail.gmail.com.
[sympy] Re: Request for an update on my GSoC proposal status before REU deadline
Hi. I appreciate your situation, but unfortunately, Google does not allow us to tell people if their proposals are accepted or not before the deadline. I would recommend choosing whichever program you would prefer to participate in. If you do plan to withdraw from GSoC, please let us know. Aaron Meurer On Saturday, April 15, 2023 at 7:05:11 PM UTC-6 tilor...@gmail.com wrote: > Hello SymPy Community, > > Yesterday I was admitted to an REU for over the summer. However, I'm more > interested in participating in GSoC with SymPy. While I understand that > decisions for GSoC won't be announced until May 4th, I have to inform the > REU program by April 28th if I intend to participate. > > Would it be possible to know whether my proposal will be accepted before > April 28 or at least some idea about how likely it is to be accepted? I'm > hoping to avoid the situation of declining the REU offer only to find out > later that my GSoC proposal was not accepted. > > Thank you for considering my request. > > Sincerely, > Tilo > -- 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/5ba1b46a-0c41-4c62-b972-4f879671f659n%40googlegroups.com.
