You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... 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?.
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.
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.
... 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
For backwards compatibility we also can have
etc.
The text was updated successfully, but these errors were encountered: