Refactor our Series types: wrap polynomials, possibly use a parametric single type (or two, for Abs vs Rel)

[fingolfin]

... to avoid a ton of code duplication (including many ccall).

Of course we have some unique functionality for some of these rings, but there should be no problem to retain that.

One "downside" is that if we wrap PolyRingElem then those all have a parent, so we waste one extra polyring, plus 8 bytes for a pointer to it in each series elem. But that seems acceptable?.

So the idea would to be have something like

@attributes mutable struct FlintAbsPowerSeriesRing{T} <: SeriesRing{T}
  prec_max::Int
  S::Symbol

  ...
end

struct FlintSeriesAbsPowerSeriesRingElem{T} <: AbsPowerSeriesRingElem{T}
  poly:T
  prec:: Int
  parent::FlintAbsPowerSeriesRing{T}
end

For backwards compatibility we also can have

const QQAbsPowerSeriesRing = FlintAbsPowerSeriesRing{QQFieldElem}
const QQAbsPowerSeriesRingElem = FlintSeriesAbsPowerSeriesRingElem{QQFieldElem}

etc.

[fingolfin]

(Actually if done right we could probably move this generic type to AbstractAlgebra, and use it for the series implementation there)

[thofma]

I am not convinced that the gain (less code?) outweighs the increase in memory consumption.

I think @fieker had some ideas of consolidating the series code, but I don't remember if it meant rewriting the generic code to directly work on entries or using polynomials.

[fieker]

On Wed, Feb 05, 2025 at 06:57:23AM -0800, Tommy Hofmann wrote:

I am not convinced that the gain (less code?) outweighs the increase in memory consumption.

I think @fieker had some ideas of consolidating the series code, but I don't remember if it meant rewriting the generic code to directly work on entries or using polynomials.

If we want to improve here it would mean adding an intermediate layer for both polynomials and series: arrays of coefficients and an offset (and length) This is at the core of the arithmetic for both.... Then polynomials and series are a tiny layer on top of that.

-- Reply to this email directly or view it on GitHub: https://github.com/Nemocas/Nemo.jl/issues/2017#issuecomment-2637097388 You are receiving this because you were mentioned.

Message ID: @.***>