Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a "scale factor" to Laurent series #28992

Open
soehms opened this issue Jan 12, 2020 · 5 comments
Open

Introduce a "scale factor" to Laurent series #28992

soehms opened this issue Jan 12, 2020 · 5 comments

Comments

@soehms
Copy link
Member

soehms commented Jan 12, 2020

The implementation of Laurent series in OSCAR (more explicitly in NEMO) uses a "scale factor" in order to compensate the inflation of its degree by the ramification index of Puiseux series. The aim of this ticket is to implement something similar for Sage Laurent series in order to reduce memory usage of our upcoming Puiseux series (see comment #4618 comment:42 of #4618).

Inspiration can be taken form fmpz_laurent_series

This ticket should introduce the "scale factor" in the method verschiebung of #4618. As soon this is done the new code will run against the doctests of #4618.

Depends on #4618

CC: @tscrim @videlec

Component: commutative algebra

Keywords: Laurent series

Issue created by migration from https://trac.sagemath.org/ticket/28992

@soehms soehms added this to the sage-9.1 milestone Jan 12, 2020
@soehms
Copy link
Member Author

soehms commented Jan 28, 2020

comment:1

First, it should be clarified which is the best place to implement such a factor. Concerning code-structure a better place would be in the classes of power series or even polynomials.

For example, factorization of polynomials could profit from such a factor, too. Thus, FLINT uses functions nmod_poly_inflate, nmod_poly_deflate and nmod_poly_deflation in that context, realizing the usage of a scale factor, as well.

But, if a realization of the scale factor for polynomials is considered, it must be done carefully, in order not to slowdown performance with respect to current applications.

@videlec
Copy link
Contributor

videlec commented Jan 28, 2020

comment:2

I would not do that at the level of polynomials as most of them rely on low-level implementations (via flint, NTL, ...). And you don't want to interfere with the datastructure here.

To my mind, we should have a single meta-object for all of

  • power series
  • Laurent polynomials/power series
  • Newton polynomial/power series
  • Newton-Laurent polynomial/series
    that would rely on polynomials. Most of the code is just "pass appropriately the call to polynomials". And this is where I would try to stick this "scale factor".

@soehms
Copy link
Member Author

soehms commented Jan 30, 2020

comment:3

Replying to @videlec:

I would not do that at the level of polynomials as most of them rely on low-level implementations (via flint, NTL, ...). And you don't want to interfere with the datastructure here.

I agree (see my according comment in #4618).

To my mind, we should have a single meta-object for all of

  • power series
  • Laurent polynomials/power series
  • Newton polynomial/power series
  • Newton-Laurent polynomial/series
    that would rely on polynomials. Most of the code is just "pass appropriately the call to polynomials". And this is where I would try to stick this "scale factor".

That is a good idea! But let us see, if I understood it correctly: Do you mean to implement a new class PolynomialCovering, say and than declare the polynomial class attached to power series (for instance) by

dynamic_class('%s_covering' %self.__f.__class__.__name__, (self.__f.__class__, PolynomialCovering)) ?

This new class should possess the attributes covering_index (the scale factor) and polynomial_preimage (the deflated polynomial as an instance of the bases class) and overload the arithmetic operations. Is that correct?

What are you referring to by Newton polynomial and Newton-Laurent polynomial*?

@mkoeppe
Copy link
Member

mkoeppe commented Apr 14, 2020

comment:4

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

@mkoeppe mkoeppe modified the milestones: sage-9.1, sage-9.2 Apr 14, 2020
@mkoeppe mkoeppe modified the milestones: sage-9.2, sage-9.3 Aug 29, 2020
@mkoeppe
Copy link
Member

mkoeppe commented Feb 13, 2021

comment:6

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

@mkoeppe mkoeppe modified the milestones: sage-9.3, sage-9.4 Feb 13, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.4, sage-9.5 Jul 19, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.5, sage-9.6 Dec 18, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.6, sage-9.7 Apr 1, 2022
@mkoeppe mkoeppe modified the milestones: sage-9.7, sage-9.8 Aug 31, 2022
@mkoeppe mkoeppe removed this from the sage-9.8 milestone Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants