Opened 8 years ago
Closed 8 years ago
#13607 closed defect (duplicate)
bug dans 5.3 lorsque l'on veut injecter un élément d'ordre q-1, appartenant à une extension de F_q, dans F_q.
Reported by: | frovetta | Owned by: | robertwb |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | coercion | Keywords: | finite fields, coercion |
Cc: | kcrisman | Merged in: | |
Authors: | Reviewers: | Jean-Pierre Flori | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
sage : def element_primitif(K): q = K.cardinality() j = 0 while j == 0: x = K.random_element() if x <> 0 and multiplicative_order(x) == q-1: j=1 return x sage :def element_d_ordre_a(K,a): q = K.cardinality() x = element_primitif(K) return x^((q-1)/a) sage : q = 25 sage : K.<d> = GF(q) sage : F.<a> = GF(q^6) sage : z = element_d_ordre_a(F,q-1); # en fait z est un élément (primitif) de K puisque d'ordre q-1 sage : c = z sage : print "c= ", c sage : b = K(-c^2) sage : print "b = ", b sage : print "b = b:", b == -K(c)^2 # normalement sage doit renvoyer True c= 4*a^11 + 4*a^10 + 2*a^9 + 3*a^7 + 4*a^6 + 4*a^5 + 3*a^4 + 3*a^3 + 4*a^2 + 4*a + 3 b = 3*d + 4 b = b: False
Change History (8)
comment:1 Changed 8 years ago by
- Summary changed from bug lorsque l'on veut injecter un élément d'ordre q-1, appartenant à extension de F_q, dans F_q. to bug lorsque l'on veut injecter un élément d'ordre q-1, appartenant à une extension de F_q, dans F_q.
comment:2 Changed 8 years ago by
- Summary changed from bug lorsque l'on veut injecter un élément d'ordre q-1, appartenant à une extension de F_q, dans F_q. to bug dans 5.3 lorsque l'on veut injecter un élément d'ordre q-1, appartenant à une extension de F_q, dans F_q.
- Type changed from PLEASE CHANGE to defect
comment:3 Changed 8 years ago by
comment:4 Changed 8 years ago by
Just FYI, the "author" is for the author of a solution. Also, although we are by no means monolingual at Sage, it might be helpful to get more developers to look at this to put at least the summary in English... just a suggestion, not required, of course!
comment:5 Changed 8 years ago by
- Cc kcrisman added
- Reviewers set to Jean-Pierre Flori
- Status changed from new to needs_review
I think this should be closed as invalid, or duplicate of #11938 and #8751 let's say although that particular ticket only targets finite fields implemented through givaro.
Or it should be changed to "Going down in compatibly embedded lattices of finite fields" and made a follow-up ticket to #8335 for psuedo-Conway lattices or #8751 for general lattices.
comment:6 Changed 8 years ago by
- Status changed from needs_review to positive_review
comment:7 Changed 8 years ago by
- Milestone changed from sage-5.11 to sage-duplicate/invalid/wontfix
comment:8 Changed 8 years ago by
- Resolution set to duplicate
- Status changed from positive_review to closed
The problem can be illustrated more simply:
This is, of course, nonsense. The offending code is at lines 482--494 of
sage-5.3/devel/sage-main/sage/rings/finite_rings/element_givaro.pyx
.As it says at lines 291--292 of
sage-5.3/devel/sage-main/sage/rings/finite_rings/finite_field_givaro.py
:There is a more mathematical difficulty with what you wish to do, and how one could expect Sage to do it. There are, of course, two embeddings of GF(25) into GF(5^{12}), with the same image. Thus there is no canonical way of identifying an element of GF(5^{12}) belonging to the subfield of order 25 with an element of another field of order 25.
But it is possible, in a very simple-minded way, to find the two candidates:
Or, much more efficiently,
Another point: there's no need to define
element_primitif
; it's built in: