GsOC 2025 : Interest in Implementing Power Series Domain in SymPy

[Jatin Bhardwaj]

Hello SymPy developers,

I am interested in contributing to SymPy by implementing a power series domain, specifically formal power series rings (e.g., QQ[[x]]). Currently, the ring_series module provides low-level operations, but there is no dedicated domain representation for power series. Integrating this with SymPy’s domain system—similar to how python-flint handles fmpq_series—could significantly enhance symbolic series computations.

There is an ongoing discussion on this topic in gh-26957, which provides a strong starting point for this project. The discussion outlines key considerations and potential approaches, making it a well-structured project to work on.

I had previously written a proposal for improving PDE-solving functionality in SymPy. Which of these two would better fit SymPy’s roadmap and priorities? I would also appreciate any further guidance on design choices, integration challenges, or other considerations not covered in the discussion.

Thank you for your time and consideration. I look forward to your response.

Jatin Bhardwaj

[Jatin Bhardwaj]

Hello Sympy Developers,

I have recently started planning the design and integration of the Power Series domain and would appreciate some guidance on key structural decisions.

Currently, my implementation revolves around three primary classes:

• Domain
• Ring
• Element

However, as I proceed further, I have a few questions:

1. Where should core functionality be implemented?

• Should functions like exp, sin, cos be implemented natively in the Element class, or should we rely on the existing ring_series implementation?
• If we use ring_series, what would be the best way to handle cases where a function is not well-defined due to the presence of a constant term in the expression?

2. Additional Questions

• Currently, multivariate expansion considers one term as a variable while treating the rest as constants. Would implementing a more generalized multivariate expansion be feasible within the project timeline? If so, how should constant terms be handled in such an expansion?
• Would introducing more trigonometric functions in ring_series be a good idea?

I would appreciate any insights on these design choices to ensure better integration with SymPy’s existing structure.

Best regards,

Jatin Bhardwaj

[Oscar Benjamin]

On Mon, 10 Mar 2025 at 14:51, Jatin Bhardwaj <bhardwaj...@gmail.com> wrote:
>
> Hello Sympy Developers,
>
>
> I have recently started planning the design and integration of the Power Series domain and would appreciate some guidance on key structural decisions.
>
> Currently, my implementation revolves around three primary classes:
>
> Domain
> Ring
> Element
>
> However, as I proceed further, I have a few questions:
>
> 1. Where should core functionality be implemented?
>
> Should functions like exp, sin, cos be implemented natively in the Element class, or should we rely on the existing ring_series implementation?

The ring_series implementations could potentially still be used but it
might be better to copy them into a new structure.

> If we use ring_series, what would be the best way to handle cases where a function is not well-defined due to the presence of a constant term in the expression?

For basic series types like QQ[[x]] meaning the ring of power series
with rational coefficients this should just raise an error if the
series cannot be represented using rational coefficients. There should
be a higher-level series type that can handle implicitly creating the
necessary coefficient domain.

> 2. Additional Questions
>
> Currently, multivariate expansion considers one term as a variable while treating the rest as constants.

I haven't investigated this in detail but I think it is probably a
mistake to use multivariate polynomials for representing univariate
series the way that the ringseries module does. At least if this
representation is more efficient or something then it should be
handled in a way that is transparent to the user.

> Would implementing a more generalized multivariate expansion be feasible within the project timeline? If so, how should constant terms be handled in such an expansion?

Constant terms should be handled the same way. I would just focus on
univariate series for now.

> Would introducing more trigonometric functions in ring_series be a good idea?

Yes, more trig functions would be good.

--
Oscar

[Jatin Bhardwaj]

Hello Oscar,

Thank you for your detailed explanations on every point I raised. I truly appreciate your insights. I have now completed my draft proposal for the project, taking into account all the points we discussed.

As you suggested, my initial focus will be on univariate series. I also acknowledge that handling the multivariate case could be tedious and possibly unachievable within the given time frame, so I will limit my scope to univariate cases for now.

Regarding expressions with constant terms, I have decided to raise an error for such cases, as they are not expandable in domain like QQ. I believe that the current approach in ring_series—treating expressions like sin(1) and cos(1) as generators—is not ideal, as it alters the ring structure. I have elaborated on this issue in my Extended Goals section and proposed how I would like to research and address it in the future.

Additionally, I have updated my proposal based on your suggestion to copy and adapt the ring_series implementations into a new structure, rather than importing the existing rs_functions directly.

I would love to hear your feedback on my proposal and any further guidance on potential improvements or implementation ideas.

GSoC Proposal

Lastly, I have a query regarding mentorship. As I understand, having a mentor is crucial for increasing the chances of project selection. I would be truly honored if you could be a potential mentor for this project. If not, could you kindly guide me towards other mentors who might be interested in overseeing this work?

Looking forward to your feedback!

Best regards,

Jatin Bhardwaj