Mod poly and mpn_mod random generation #2448

dlesnoff · 2025-10-29T16:56:45Z

Follow-up of #2430 .
Adds a rand function:

nmod_poly
nmod_poly_mat
mpn_mod
fmpz_mod_poly

It seems that implementations of nmod_mpoly randtest functions generate uniformly random coefficients.
I did not add rand functions for basic types like fmpz_mod nor nmod.
I plan to add a rand function for mpn_mod_poly and mpn_mod_mat.
Please forgive me, I based my branch on my previously non-merged branch and it needs some cleanup.

fredrik-johansson · 2025-10-29T17:09:09Z

Please forgive me, I based my branch on my previously non-merged branch and it needs some cleanup.

I think you need to rebase on main and force-push to get a clean diff.

vneiger · 2025-10-29T21:40:03Z

doc/source/fmpz_poly.rst

    Sets `f` to a random polynomial with up to the given length and where
    each coefficient has up to the given number of bits. The coefficients
-    are signed randomly.
+    are random numbers in `[1, n)`, where `n` is the modulus given by the context `ctx`.


Several new things are misplaced here I think. For this specific one, there is no input ctx, for others about they are fmpz_mod_poly but this file is about fmpz_poly.

vneiger · 2025-10-29T21:44:30Z

src/fmpz/rand.c

    }
 }

+void fmpz_randm_nonzero(fmpz_t f, flint_rand_t state, const fmpz_t m) {


The current behaviour does not have uniform distribution (it is more likely to generate 1 than other values). Maybe generate uniformly in [0,m-2] (being careful with m=1 or such corner cases), and then add 1?

Does m stands for uniform? For me, it stands for modulus since the element is upper bounded by a modulus and is not just a random element with a set number of bits. Sorry, I did not meant to make something uniform.
The functions fmpz_mod_poly_randtest used randm. I prefered creating a randm_nonzero function than using randtest_nonzero.

What I meant is that currently, fmpz_randm generates a uniform integer in [0, m) (all values have equal probability), as can be seen from the code. The fact that the distribution is uniform is not explicitly indicated in the documentation, but that's ok, it is the "canonical distribution" for a finite set.

So if a fmpz_randm_nonzero function is added, it seems to me that it should also have uniform distribution (choosing uniformly in [1, m)), unless this is tricky to make. In this case it is not tricky: apply fmpz_randm with m-1 to get a uniform choice in [0, m-1), and then add 1, this gives you a uniform choice in [1, m).

src/fmpz_mod_poly/randtest.c

vneiger · 2025-10-29T21:47:44Z

src/fmpz_mod_poly/randtest.c

    fmpz_mod_poly_fit_length(poly, len, ctx);
    _fmpz_vec_zero(poly->coeffs, len);
-    fmpz_randm(poly->coeffs + 0, state, fmpz_mod_ctx_modulus(ctx));
+    fmpz_randm_nonzero(poly->coeffs + 0, state, fmpz_mod_ctx_modulus(ctx));


Why this change, or why using nonzero almost everywhere?

To have at least a randfull-like functionality. See my comments above.

As suggested in other functions, I think that in these randtest functions we may as well rely on the existing fmpz_randtest_mod.

vneiger · 2025-10-29T21:59:00Z

I cancelled the CI workflow because they were still in testing after almost 4 hours. Please review the code carefully to see what changes to existing functions could have led to this, thanks! (I pointed at some modifications in my comments, but there may be others)

dlesnoff · 2025-10-30T10:05:15Z

fmpz_randtest does not generate a coefficient with increased sparsity (here, 0 with increased probability) but generates a coefficient using a number of bits. For mod functions, it requires to be reduced after being generated.
fmpz_randm generates directly a coefficient in the range [0, m) where m is a bound, but I am unsure if this function has some pseudo-uniformity guarantee (the algorithm is unspecified).
So randtest has a slight different meaning for fmpz than for structures in mod n source files.

There is probably an infinite loop, I'll do a manual bisect.

The randtest functions are using `randm` which generates positive coefficients in [0, m) range with m the modulus given by the context. The documentation told that the coefficients are randomly signed, so I fixed that. I introduced a `randm_nonzero` function in fmpz to ensure that coefficients are nonzero and replaced all occurences of `randm` in `fmpz_mod_poly_randtest` functions by this new function. Apart from the `rand` function, this introduces a `rand_monic` and a `rand_irreducible` function.

I added _fmpz_mod_vec_rand with the intent to use it in _mpn_mod_vec_rand but did not use it in the end. This reverts commit f98e52c.

dlesnoff · 2025-10-30T11:34:05Z

The tests halt indefinitely after gr_special_fac. ~~I am unsure if it's related to my PR.~~
This commit is the culprit: Add fmpz_mod_poly_rand, rand_monic, irred funcs

dlesnoff · 2025-10-30T14:26:28Z

Ok, I guess that if a polynomial has nonzero coefficients, it is irreducible with much less probability. This could slow down the tests. I should indeed give up on a "randfull-like" functionality for fmpz_mod_poly_randtest functions but then what would be the point of making another rand function?

doc/source/nmod_poly.rst

doc/source/nmod_poly_mat.rst

vneiger · 2025-10-30T17:00:51Z

src/fmpz/rand.c

    }
 }

+void fmpz_randm_nonzero(fmpz_t f, flint_rand_t state, const fmpz_t m) {


What I meant is that currently, fmpz_randm generates a uniform integer in [0, m) (all values have equal probability), as can be seen from the code. The fact that the distribution is uniform is not explicitly indicated in the documentation, but that's ok, it is the "canonical distribution" for a finite set.

So if a fmpz_randm_nonzero function is added, it seems to me that it should also have uniform distribution (choosing uniformly in [1, m)), unless this is tricky to make. In this case it is not tricky: apply fmpz_randm with m-1 to get a uniform choice in [0, m-1), and then add 1, this gives you a uniform choice in [1, m).

src/fmpz_mod_poly/randtest.c

vneiger · 2025-10-30T17:05:58Z

src/fmpz_mod_poly/randtest.c

    fmpz_mod_poly_fit_length(poly, len, ctx);
    _fmpz_vec_zero(poly->coeffs, len);
-    fmpz_randm(poly->coeffs + 0, state, fmpz_mod_ctx_modulus(ctx));
+    fmpz_randm_nonzero(poly->coeffs + 0, state, fmpz_mod_ctx_modulus(ctx));


As suggested in other functions, I think that in these randtest functions we may as well rely on the existing fmpz_randtest_mod.

src/mpn_mod.h

vneiger · 2025-10-30T17:30:21Z

Ok, I guess that if a polynomial has nonzero coefficients, it is irreducible with much less probability. This could slow down the tests. I should indeed give up on a "randfull-like" functionality for fmpz_mod_poly_randtest functions

This is likely indeed. I haven't looked closely at the test files and the one that is failing, but let's suppose that some test includes working modulo 2, then the new randtest using randm_nonzero will only generate coefficients that are 1 ! I don't think randtest should ban 0.

but then what would be the point of making another rand function?

In my last batch of comments, you can see that I suggest using fmpz_randtest_mod instead of fmpz_randm_nonzero. Then the randtest and rand functions for fmpz_mod_poly would become rather different and I think it would make sense to have both. (However, one question that remains, is whether this change will suffice to solve the "infinite test" issue.)

dlesnoff · 2025-11-03T14:14:05Z

I changed randm_non_zero t to randtest calls. I gave one extra bit for the random generation before taking the modulus. If you think it is not necessary, I will remove it.
~~I have still a few changes to perform.~~

dlesnoff force-pushed the mod_poly-random-generation branch from c1be23c to ba6af38 Compare October 29, 2025 18:07

vneiger reviewed Oct 29, 2025

View reviewed changes

src/fmpz_mod_poly/randtest.c Show resolved Hide resolved

vneiger reviewed Oct 29, 2025

View reviewed changes

fredrik-johansson added new feature workshop 2025v2 labels Oct 30, 2025

dlesnoff added 8 commits October 30, 2025 12:17

Add _nmod_vec_rand

e6f8dcd

Add nmod_poly rand funcs

4ea9a57

Add nmod_poly_mat rand funcs

4f0ef9b

Add fmpz_mod_vec_rand

bb5d986

Add a rand function to mpn_mod

400598a

Add mpn_mod_vec_rand func

9060505

Revert "Add fmpz_mod_vec_rand"

59f5c7d

I added _fmpz_mod_vec_rand with the intent to use it in _mpn_mod_vec_rand but did not use it in the end. This reverts commit f98e52c.

dlesnoff force-pushed the mod_poly-random-generation branch from 21ee353 to 59f5c7d Compare October 30, 2025 11:17

vneiger reviewed Oct 30, 2025

View reviewed changes

Replace randm_non_zero by randtest calls

eafe4cf

dlesnoff force-pushed the mod_poly-random-generation branch from f5b0816 to eafe4cf Compare November 3, 2025 13:46

dlesnoff added 3 commits November 3, 2025 16:17

Fix documentation of mpn_mod

4dff27e

Merge branch 'main' into mod_poly-random-generation

692c2b8

Remove +1 to uint pointers

716a13e

Mod poly and mpn_mod random generation #2448

Are you sure you want to change the base?

Mod poly and mpn_mod random generation #2448

Uh oh!

Conversation

dlesnoff commented Oct 29, 2025

Uh oh!

fredrik-johansson commented Oct 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vneiger commented Oct 29, 2025

Uh oh!

dlesnoff commented Oct 30, 2025

Uh oh!

dlesnoff commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dlesnoff commented Oct 30, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vneiger commented Oct 30, 2025

Uh oh!

dlesnoff commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dlesnoff commented Oct 30, 2025 •

edited

Loading

dlesnoff commented Nov 3, 2025 •

edited

Loading