Hi,
For Givaro, there is no such limitation, the test-suite indeed tests the field GFqDom<int64_t> with
the 22 bits cardinality 4194301.
Note that there is a misleading error in the class, where maxCardinality() returns 65536.
This is reported in
https://github.com/linbox-team/givaro/issues/121
Fortunately, this is not enforced at construction
Now from the SageMath point of view, element_givaro also restricts the cardinality to 65536.
One reason for that is that it uses GfqDom<int> which in most archs is 32 bits and therefore limits
cardinality to 65536 (one need to be able to store a product of 2 elements in an int).
For SageMath to be able to use GFqDom with larger cardinalities, one should switch to
GFqDom<int64_t> which may slow down small fields. So ideally one should have 2 classes, one over
int32_t and the other one over int64_t.
Maybe using a templated systems as done for matrix_modn_dense with float and double would help
factor out code.
Clément
Le 18/06/2019 à 20:18, Eric Zhu a écrit :
> It is possible to get element_givaro.py to create finite fields using zech logs for order larger
> than 2^16? The memory shouldn't be an issue.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
>
sage-support...@googlegroups.com <mailto:
sage-support...@googlegroups.com>.
> To post to this group, send email to
sage-s...@googlegroups.com
> <mailto:
sage-s...@googlegroups.com>.
> Visit this group at
https://groups.google.com/group/sage-support.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/sage-support/cdd8d106-392f-4eb5-81c7-3134d4de4184%40googlegroups.com
> <
https://groups.google.com/d/msgid/sage-support/cdd8d106-392f-4eb5-81c7-3134d4de4184%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit
https://groups.google.com/d/optout.