Add generic Ore polynomial module

[rburing]

This contains only the basic structure so far, such as memory management, additive arithmetic, and multiplication from the left by an element of the base ring.

• Part of Wishlist for D-finite/holonomic functions #1881

Feedback welcome!

We would like to use this data type as input to differential equation solvers, so we don't need the multiplicative structure initially, though it would be nice to have it in the future.

Multiplicative operations (to be defined later) depend on the Ore context object, so I figured that all operations should take the Ore context as input, to make the interface uniform. So now the interface looks like gr_mpoly, and the basic operations implemented so far call gr_poly methods.

Since the base ring will typically be polynomial, should gr_ore_poly_scalar_mul and GR_ORE_POLY_ELEM_CTX be named differently? Maybe using base / BASE?

I also tried to make the module "optional" in the sense that gr_mpoly is, let me know if I missed something in this regard.

cc @mezzarobba

[mezzarobba]

On Saturday, 12 April 2025 Ricardo Buring wrote: > +typedef enum { + ORE_OPERATOR_DERIVATIVE, + ORE_OPERATOR_EULER_DERIVATIVE, + /* TODO: Shift operator, etc. */ +} +ore_operator_t; I named this enum (and the value prefix) improperly. What should the name be?

Maybe gr_ore_poly_which_operator, for consistency with gr_which_structure?

…

-- Marc

[rburing]

Some/most of the arithmetic/setter methods (gr_ore_poly_add for example) are not getting called in the ring tests.

I'm not sure what I did wrong since I did put them in the method table.

Edit: Never mind, I put some NULL pointers in there which is not allowed except to indicate the end of the table.

[fredrik-johansson]

So, working with Ore polynomials over say R[x], one might indeed want to do mixed operations with operands from either R or R[x]. The term "scalar" being ambiguous, instead of adding many extra methods, perhaps just define gr_ore_poly_add_other etc. that handles all cases?

[fredrik-johansson]

I don't see the need for ore_poly.h and ore_poly_types.h.

[fredrik-johansson]

Most of the one-line trivial methods could go in a single file.

[fredrik-johansson]

Multiplicative operations (to be defined later) depend on the Ore context object, so I figured that all operations should take the Ore context as input, to make the interface uniform.

Yes, this is the right way to do it. The way gr_poly and gr_mat work directly with the element context is an exception rather than the rule, and at some point we should add a public interface for those types using a poly/mat context as well.

[rburing]

I reorganized the code to collect the wrapper functions in one file, and applied all the other suggestions above. I removed all the methods with scalar in the name and added some other methods, indeed this looks much better.

Let me know if this needs any further changes.

[fredrik-johansson]

Looks good. The only thing missing is documentation.

[fredrik-johansson]

Something that doesn't seem to be well specified in the documentation is the generator name (set_gen_name / string conversion methods). If I'm in R[x][D], say, shouldn't x already be named the base ring while the Ore ring generator is D?

[fredrik-johansson]

In fact, shouldn't the generator x (given as an element of the base ring) be a parameter to the Ore polynomial ring constructor? In general, the base ring could be something multivariate.

[rburing]

I updated the context and constructor to include an index of a generator of the base ring, and (hopefully) clarified the documentation. I think the restriction to generators of the base ring (rather than elements of the base ring) is reasonable, and e.g. in the univariate case it saves the user from having to define a variable that will probably never be used (e.g. multiplication by the variable will be replaced by a shift). Let me know if this is alright.

[mezzarobba]

On Tuesday, 29 April 2025 Ricardo Buring wrote: @rburing requested your review on: flintlib/flint#2299 Add generic Ore polynomial module.

Sure, I can take a look, but maybe not before next week. Thanks for your work on this!

[rburing]

Another question: How should the q parameter for q-shifts or q-derivations be handled? The current gr_ctx_init_gr_ore_poly and the struct _gr_ore_poly_ctx_struct do not refer to it. Can this be left for later? I guess the main question is: do we want to put an extra parameter (again an index into the list of generators or a gr_srcptr?) already in gr_ctx_init_gr_ore_poly, or add a separate second constructor later (or break source compatibility by adding an extra parameter to gr_ctx_init_gr_ore_poly later)?

[rburing]

I merged the implementation of Ore polynomial multiplication by @vioneers into this branch, and rebased it to resolve merge conflicts and a few technical issues (due to other developments in the codebase in the meantime).

[rburing]

I don't really understand why the tests (flint_fprintf with ASAN and codecov make check) are failing.

[rburing]

For the flint_fprintf test: it seems this

flint/src/generic_files/io.c

Line 206 in baf1c95

#define IS_FLINT_TYPE(ip, str) (memcmp(ip, str "}", sizeof(str)) == 0)

can read past the end of the buffer, e.g. when there is a {%gr_ formatter near the end of the format string and str is too large (here "gr_ore_poly" happens to be large).

How should we deal with this (pre-existing) issue?

[fredrik-johansson]

Good catch. I guess memcmp should be something like strcmp or strncmp.

[mezzarobba]

The powering tests from the generic test suite are slow in the Mahler case (reached with FLINT_TEST_MULTIPLIER=10); we need a way to disable them or limit them to really really tiny examples. Maybe something like this:

diff --git a/src/gr_ore_poly/mul.c b/src/gr_ore_poly/mul.c
index 377ed6d78..d2d9e1999 100644
--- a/src/gr_ore_poly/mul.c
+++ b/src/gr_ore_poly/mul.c
@@ -146,6 +146,9 @@ int gr_ore_poly_mul(gr_ore_poly_t res, const gr_ore_poly_t poly1, const gr_ore_p
     if (len1 == 0 || len2 == 0)
         return gr_ore_poly_zero(res, ctx);

+    if (len1 + len2 - 1 > ctx->size_limit)
+        return GR_UNABLE;
+
     if (GR_ORE_POLY_CTX(ctx)->sigma_delta == NULL)
         return GR_UNABLE;

diff --git a/src/gr_ore_poly/test/t-ring.c b/src/gr_ore_poly/test/t-ring.c
index 82768e04f..e0e4f860b 100644
--- a/src/gr_ore_poly/test/t-ring.c
+++ b/src/gr_ore_poly/test/t-ring.c
@@ -28,6 +28,9 @@ TEST_FUNCTION_START(gr_ore_poly_ring, state)
         slong reps;

         gr_ore_poly_ctx_init_randtest2(ctx, ore_ctx, state);
+        if (GR_ORE_POLY_CTX(ore_ctx)->which_algebra == ORE_ALGEBRA_MAHLER
+            || GR_ORE_POLY_CTX(ore_ctx)->which_algebra == ORE_ALGEBRA_Q_SHIFT)
+            ore_ctx->size_limit = 2;

         if (gr_ctx_is_finite(ctx) == T_TRUE ||
             gr_ctx_has_real_prec(ctx) == T_TRUE)

[mezzarobba]

gr_addmul?

[fredrik-johansson]

It's probably better to do it with gr_add/gr_mul for now. Many rings don't implement an optimized gr_addmul and the generic version will do a temporary allocation each time.

[mezzarobba]

ok, thanks!

[mezzarobba]

I've made some tweaks so that the tests don't take too long and merged with main in my branch (see https://github.com/mezzarobba/flint/tree/gr_ore_poly).

@fredrik-johansson There are a lot of small things that could be improved, and we may have overlooked some issues, but I think this could already be useful, so feel free to merge it if you want. @vioneers is working on a follow-up PR implementing Euclidean division and gcd.

[fredrik-johansson]

Great! Better merge this now as it looks functional; any minor polish that's missing can surely come later.