Hello, Thank you for your insights on SymPy's priorities. Following your discussion about PDE solver, I'd like to inquire about SymPy's current direction regarding *Computational Group Theory.*
I'm considering a project proposal focused on *implementing Quotient Groups, Automorphism Groups, and algorithms for Infinite Groups*. Could you please guide *if this aligns* with SymPy's *current priorities* and whether *mentors* would be *available *for such a project? I've taken relevant Abstract Algebra ( Group,Ring, Field, Galois Theory) courses at university, and have started with the reference mentioned on the ideas page : *Handbook of Computational Group Theory* Before proceeding further, I wanted to confirm if this area would be considered of any value and relevance for SymPy's development at this time. Best regards, Ashutosh Rajora On Thu, Feb 27, 2025 at 2:11 PM Aaron Meurer <[email protected]> wrote: > I would also argue that symbolic PDE solvers are relevant and in-scope > for SymPy. However, I also do agree with Oscar that as far as > priorities go, many other things such as polynomials and matrices are > much more important, as they affect virtually all parts of SymPy, > whereas a PDE solver is not going to be used by any other part of > SymPy. > > Aaron Meurer > > On Fri, Feb 7, 2025 at 7:44 AM Nicolas Guarin <[email protected]> > wrote: > > > > Hello, > > > > I am in a different position than Oscar. Differential equations (and > PDEs) have a place in the symbolic world. And the solution of them is one > part. SymPy is far from doing what is possible with Maple regarding PDE > solutions, for example. We are also lacking approximation done > symbolically, as well. Asymptotic approximations, for example. > > > > I have used this kind of thing for benchmarking my numerical solutions > using finite element methods, and consider that they are helpful. > > > > I have never been a mentor in GSOC in the past, but maybe I could try to > if someone gives me a hand. > > > > Best regards, > > Nicolás > > > > > > On Thursday, February 6, 2025 at 10:07:44 AM UTC-5 [email protected] > wrote: > >> > >> Hi Oscar, > >> > >> > >> Thank you for your detailed response. I understand your perspective on > prioritizing core functionalities. It makes sense that improving algebra, > polynomials, matrices, and core solvers would provide a stronger foundation > for symbolic computations. > >> > >> I appreciate your insights and keep these priorities in mind while > considering future contributions to SymPy. While waiting for more reviews, > I’ve begun looking into other core functionalities within SymPy that could > be enhanced to improve the library further and make it a better fit for the > project. > >> > >> > >> Best regards, > >> > >> Jatin > >> > >> On Thursday, 6 February 2025 at 03:12:17 UTC+5:30 Oscar wrote: > >>> > >>> On Wed, 5 Feb 2025 at 13:41, Jatin Bhardwaj <[email protected]> > wrote: > >>> > > >>> > Hello SymPy developers, > >>> > > >>> > > >>> > I am interested in improving SymPy's PDE-solving functionality, > particularly for quasilinear first-order PDEs, general first-order > nonlinear PDEs, and second-order PDEs. Currently, SymPy has strong support > for linear PDEs, but handling nonlinear cases—especially quasilinear and > fully nonlinear PDEs—remains limited. > >>> > > >>> > > >>> > My primary question is: Does expanding PDE support in these areas > align with SymPy’s current development roadmap and priorities? > >>> > > >>> > > >>> > If this aligns with SymPy’s goals, I would be enthusiastic about > contributing to this effort. I have a strong foundation in calculus and > differential equations, which I believe will be valuable in tackling this > challenge. I’m prepared to delve into the computational implementation of > these features and develop a concrete plan of action. > >>> > > >>> > To facilitate this process, I would greatly appreciate any guidance > on: > >>> > 1. Recommended resources for proposed features. > >>> > 2. Any potential challenges or considerations unique to implementing > nonlinear PDE solvers. > >>> > >>> Hi Jatin, > >>> > >>> SymPy does not have a broadly agreed development roadmap and list of > >>> priorities. Rather different people have different things that they > >>> are working on and would prioritise. I will answer in terms of my own > >>> sense of a roadmap and priorities. > >>> > >>> SymPy has various solver functions e.g. solve for algebraic equations, > >>> dsolve for ODEs and pdsolve for PDEs and many more. The usefulness of > >>> these functions is often questionable. Even in the case of solve it > >>> would often be better to use something else such as to compute > >>> numerical solutions rather than analytic solutions. For dsolve, only > >>> quite simple ODEs can be solved. The implementation can be improved to > >>> handle more DEs but there would still be a tiny subset of problems > >>> where analytic solutions can be computed and a vast array of practical > >>> problems that realistically can only be handled numerically. When you > >>> go to pdsolve and PDEs the set of cases that can be solved > >>> analytically is so small that a function like pdsolve is almost > >>> useless. It would be much more useful to users if SymPy just provided > >>> something like an ndsolve function that could solve differential > >>> equations numerically using SciPy's solvers rather than making them go > >>> through lambdify. > >>> > >>> That does not mean that we can't do useful things with symbolics when > >>> solving these different types of equations. Often though the useful > >>> thing is to do some symbolic manipulation that then helps with a > >>> subsequent approximate or numeric calculation e.g. we could compute a > >>> series solution or transform the equations somehow. Some symbolic > >>> manipulation is needed even just to set up a numeric solution to a PDE > >>> so you could imagine something useful where SymPy can do that and then > >>> set things up so that the problem could be solved numerically with > >>> e.g. FEniCS. > >>> > >>> All of these are also things that could be built on top of SymPy > >>> though so e.g. someone could make a library that depends on SymPy and > >>> that uses it to do useful things with PDEs and FEniCS etc. The > >>> capabilities that such a library would provide would be the same if it > >>> was part of SymPy or just a separate library. Its capabilities would > >>> be limited though by the capabilities of the core parts of SymPy. When > >>> I look at GSOC proposals I am much more interested in proposals that > >>> improve existing core functionality that would provide a good > >>> foundation for other things to be built on top. > >>> > >>> If SymPy did not have pdsolve and someone proposed it in a GSOC > >>> project now then I would say that we should reject the proposal. The > >>> only way that I would be happy to add pdsolve is if the code was > >>> already written, comprehensive, well tested, with a well defined scope > >>> and had already been proven to be useful. As it is we have a function > >>> that is not that useful and would still not be that useful even if > >>> someone improved it a bit. I'm not interested in having a GSOC project > >>> that tries to improve pdsolve rather than some other project that > >>> improves some core part of SymPy. > >>> > >>> It is possible that someone else would be interested in supervising a > >>> project around pdsolve but personally I would not and I would not > >>> consider it to be any kind of priority for SymPy's roadmap. The > >>> priorities from my perspective are more things like core algebra, > >>> polynomials and matrices, functions like solve, limits, series, code > >>> generation, performance, etc. If these parts of SymPy are good then it > >>> provides a good foundation for someone to make a symbolic PDE library > >>> but if we don't have the resources to handle the core things then we > >>> should not spend those resources on things that could just be in other > >>> libraries that depend on 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 [email protected]. > > To view this discussion visit > https://groups.google.com/d/msgid/sympy/a7da6fc0-874b-449d-bee3-8aed9f526ad9n%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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6JVBX_Ge7s-r3r-f5DFE0GSFk%2B2Z%3DjdFnBtAy%2B29HBFqg%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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/CALhA_BGrzxrLvBxArGNpsEmA2R%3D4NhhfhkA6B4v0h9wqCpZS%2BA%40mail.gmail.com.
