Mod poly and mpn_mod random generation #2448
Conversation
I think you need to rebase on main and force-push to get a clean diff. |
dlesnoff
force-pushed
the
mod_poly-random-generation
branch
from
c1be23c to
ba6af38
Compare
| 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`. |
There was a problem hiding this comment.
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.
| } | ||
| } | ||
|
|
||
| void fmpz_randm_nonzero(fmpz_t f, flint_rand_t state, const fmpz_t m) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| 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)); |
There was a problem hiding this comment.
Why this change, or why using nonzero almost everywhere?
There was a problem hiding this comment.
To have at least a randfull-like functionality. See my comments above.
|
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) |
|
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
force-pushed
the
mod_poly-random-generation
branch
from
21ee353 to
59f5c7d
Compare
|
The tests halt indefinitely after |
|
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 |
3 participants
Follow-up of #2430 .
Adds a
randfunction:It seems that implementations of nmod_mpoly
randtestfunctions generate uniformly random coefficients.I did not add
randfunctions for basic types like fmpz_mod nor nmod.I plan to add a
randfunction formpn_mod_polyandmpn_mod_mat.Please forgive me, I based my branch on my previously non-merged branch and it needs some cleanup.