Skip to content

Extrapolation at points geometric progression, over nmod#2667

Merged
vneiger merged 6 commits into
flintlib:mainfrom
vneiger:geometric_extrapolation
May 14, 2026
Merged

Extrapolation at points geometric progression, over nmod#2667
vneiger merged 6 commits into
flintlib:mainfrom
vneiger:geometric_extrapolation

Conversation

@vneiger
Copy link
Copy Markdown
Collaborator

@vneiger vneiger commented May 9, 2026

This PR comes from work done in collaboration with @ktran11 .

This completes the set of functions for evaluation/interpolation at points in geometric progression, by adding extrapolation: given the evaluations of some (implicit) polynomial at a list of $m$ successive points from the geometric progression, return the evaluations of this polynomial at another list of $n$ successive points in this progression.

More precisely, here is a simplified excerpt of the documentation for the new function: consider the geometric progression $(c \cdot q^i)_ {i \ge 0}$, for some invertible element $c$ and for $q$ of "sufficiently large" order. The new function takes as input the list of values $(f(c \cdot q^{k+i}))_ {0 \le i < m}$ of some polynomial $f$ of degree less than $m$, for some given starting index $k \ge 0$, and computes the list of values $(f(c \cdot q^{\ell+j}))_ {0 \le j < n}$, for some other starting index $\ell$. The parameters are such that both lists of points are disjoint. Note that $f$ is not part of the input or output, and in fact the provided implementation does not compute it.

The naive approach would be to interpolate to find $f$ and then evaluate it at the output points, and even that is not straightforward (the current implementations of evaluate/interpolate focus on a sublist of the $q^i$'s that must start with $i=0$, and only supports $c=1$). The implemented approach is based on an approach due to Bostan, Gaudry, and Schost (Section 3 of SIAM J.Computing, 2007, https://doi.org/10.1137/S0097539704443793). This is presented there for arithmetic progressions, and adapted here to geometric progressions.

The timings below show how this behaves performance-wise, with $m = n$, compared to what one could expect from an interpolation+evaluation approach, and compared to one middle product with relevant parameters (which is the main step in the algorithm, apart from precomputations). Roughly: the performance is just a tiny bit higher than the middle product, and this is between 2 and 2.5 faster than the naive approach (theory predicts a factor of 3, if I'm not mistaken, but that would require a middle product that perfectly matches the performance of polynomial multiplication).

ilen      olen |precomp with pr w/o pr  | mulmid  | int+ev 
1             1|8.1e-02 3.5e-03 3.9e-03 | 5.4e-03 | 3.1e-02
2             2|1.4e-01 1.8e-01 3.2e-02 | 1.3e-02 | 9.6e-02
3             3|2.0e-01 2.6e-01 4.4e-02 | 2.0e-02 | 1.3e-01
4             4|2.5e-01 3.1e-01 5.8e-02 | 2.7e-02 | 1.8e-01
6             6|3.1e-01 4.2e-01 9.7e-02 | 5.3e-02 | 2.8e-01
8             8|3.6e-01 5.2e-01 1.4e-01 | 8.1e-02 | 3.7e-01
10           10|4.1e-01 6.2e-01 1.9e-01 | 1.1e-01 | 4.7e-01
12           12|4.9e-01 8.1e-01 3.1e-01 | 2.2e-01 | 6.7e-01
16           16|5.7e-01 1.1e+00 4.3e-01 | 3.2e-01 | 9.7e-01
20           20|6.8e-01 1.3e+00 5.5e-01 | 4.1e-01 | 1.3e+00
30           30|9.4e-01 2.0e+00 9.9e-01 | 7.6e-01 | 2.2e+00
45           45|1.3e+00 3.3e+00 1.8e+00 | 1.5e+00 | 4.1e+00
70           70|2.1e+00 6.0e+00 3.7e+00 | 3.2e+00 | 9.2e+00
100         100|2.9e+00 9.9e+00 6.8e+00 | 6.2e+00 | 1.6e+01
200         200|5.5e+00 2.1e+01 1.5e+01 | 1.3e+01 | 3.3e+01
400         400|1.1e+01 3.7e+01 2.5e+01 | 2.3e+01 | 6.1e+01
800         800|2.1e+01 7.5e+01 5.2e+01 | 4.5e+01 | 1.2e+02
1600       1600|4.3e+01 1.6e+02 1.1e+02 | 9.2e+01 | 2.4e+02
3200       3200|8.4e+01 3.2e+02 2.2e+02 | 1.9e+02 | 4.9e+02
6400       6400|1.7e+02 6.4e+02 4.5e+02 | 4.1e+02 | 1.0e+03
12800     12800|4.0e+02 1.4e+03 9.8e+02 | 8.3e+02 | 2.3e+03
25600     25600|8.6e+02 2.8e+03 2.0e+03 | 1.8e+03 | 4.7e+03
51200     51200|1.8e+03 6.0e+03 4.3e+03 | 3.9e+03 | 9.8e+03
102400   102400|3.1e+03 1.3e+04 9.6e+03 | 8.6e+03 | 2.1e+04
204800   204800|5.5e+03 2.7e+04 2.2e+04 | 2.0e+04 | 4.7e+04

vneiger and others added 6 commits May 9, 2026 10:22
  sequence

- add test file for geometric extrapolation

Co-authored-by: ktran11 <kevintran3009@outlook.fr>
Co-authored-by: ktran11 <kevintran3009@outlook.fr>
…n+interpolation

Co-authored-by: ktran11 <kevintran3009@outlook.fr>
Co-authored-by: ktran11 <kevintran3009@outlook.fr>
@vneiger vneiger marked this pull request as ready for review May 9, 2026 21:01
@fredrik-johansson
Copy link
Copy Markdown
Collaborator

This is very nice! Looks interesting for having a variant of nmod_poly represented by evaluations, where the degree can be extended dynamically. Is there some other specific application?

@vneiger
Copy link
Copy Markdown
Collaborator Author

vneiger commented May 12, 2026

This is very nice! Looks interesting for having a variant of nmod_poly represented by evaluations, where the degree can be extended dynamically. Is there some other specific application?

Not really "other", but in the exact same idea as what you mention ("variant represented by evaluations"), this operation may be beneficial in fast algorithms for rational reconstruction problems, for polynomials or for polynomial matrices. Say, for polynomials: given $f$ and a modulus $M$, reconstruct a small-degree fraction $f = p/q \bmod M$. This could reduce the number of changes of representation in these algorithms, by allowing to stay mostly on an evaluated representation. I'm hoping to have more affirmative answer in the next months (there is no doubt in terms of complexity, but the efficiency in practice still needs investigation).

@vneiger vneiger merged commit 6da2eee into flintlib:main May 14, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants