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*

On Sunday, 16 February 2025 at 17:30:01 UTC+5:30 Jatin Bhardwaj wrote:

> 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 
> <https://github.com/sympy/sympy/issues/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
>

-- 
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/1cfec4b9-1826-44b6-824f-f15f7f7d3470n%40googlegroups.com.

Reply via email to