Introduce fq_default_ctx_init_randtest()
#2050
Conversation
doc/source/fq_default.rst
Outdated
| .. function:: void fq_default_ctx_init_randtest(fq_default_ctx_t ctx, flint_rand_t state, int type) | ||
|
|
||
| Initializes ``ctx`` to a random finite field. Assumes that | ||
| ``fq_default_ctx_init`` has not been called on ``ctx`` already. | ||
| Initializes ``ctx`` to a random finite field where the prime and degree is | ||
| set according to ``type``. | ||
| Assumes that ``fq_default_ctx_init`` has not been called on ``ctx`` already. | ||
| To see what prime and degrees may be output, see | ||
| ``type`` in :func:`_nmod_poly_conway_rand`. |
There was a problem hiding this comment.
Just to be clear: You are not referring to the internal "type" for fq_default (i.e. fmpz, nmod etc.)?
I have to think about the randomness thing (i.e. which type). Now, this module is not very much tested inside FLINT, unfortunately (however it is tested in Nemo/Oscar), but in general we would like to (1) minimize the time for testing and (2) reduce the complexity of usage. A separate parameter for type obviously increases the complexity, and, furthermore, is inherited from nmod_poly.
There was a problem hiding this comment.
The type here is the one passed into the generation of prime,degree from the nmod conway function and is not related at all the the fq_default type
The design here, hopefully, simply does what practically would happen if you asked for a random context from fq, fq_nmod and fq_zech
src/fq_default/test/t-init.c
Outdated
| fq_default_clear(fq, ctx); | ||
| fq_default_randtest(fq, state, ctx); |
There was a problem hiding this comment.
Order has to change here, no?
There was a problem hiding this comment.
yes, sorry about that. Will fix now.
|
This doesn't do what I expect. I would expect it to create a |
|
Thanks for the feedback, I have tried adapting the function to better match your expectation. |
src/fq_default/ctx.c
Outdated
| /* Create GF(p^d) for FQ_ZECH context */ | ||
| case FQ_DEFAULT_FQ_ZECH: | ||
| fmpz_randprime(prime, state, 2 + n_randint(state, 4), 1); | ||
| deg = 1 + n_randint(state, 4); |
There was a problem hiding this comment.
It looks like this can generate GF(31^4) which is quite large for the Zech representation as far as basic testing goes anyway. Maybe drop both the n_randint(state, 4) to n_randint(state, 3).
There was a problem hiding this comment.
I have modified these two values.
While working on #2047 I noticed that the documentation included
fq_default_ctx_randtest()but the function itself was not available. This PR introduces the functionfq_default_ctx_init_randtest()named to matchfq_ctx_init_randtest(),fq_nmod_ctx_init_randtest()andfq_zech_ctx_init_randtest().Originally I was going to select between these three but then I noticed
fq_ctx_init_randtest()only works withnmodsized primes, so I have followed this design for the default too.To init a random context, I rely on
_nmod_poly_conway_rand()to compute a random prime / degree and then initialise thefq_default_ctx_tfrom these.I have added a test to
t-init.ctrying to follow the behaviour of the original tests, where I simply check I can create randomfq_default_telements without a crash.