Hi Dima,
On Jan 11, 4:14 am, Dima Pasechnik <dimp...@gmail.com> wrote:
> I reckon this must be due to Sage representing the finite field of
> order p^n
> as quotient rings F_p[x]/(f(x)), with f an irreducible polynomial of
> degree n. Indeed, in this case to do the coercion to, say F_{p^m}=F_p
> [x]/(g(x)), (with n dividing m, of course) would require some
> nontrivial (and slow) polynomial arithmetic, unless f and g are
> somehow "related".
I am afraid I don't know the details on how finite fields are
implemented in sage
> GAPdoes it in a more clever way, at least for its "standard" finite
> fields; f and g are always related in such a way that such a
> computation is trivial. Namely, the primitive element Z(p^n) of the
> 1st field equals Z(p^m)^((p^m-1)/(p^n-1)), where Z(p^m) is the
> primitive element of the 2nd field.
The generators in GAP are the roots of Conway polynomials, right?
IIRC, the map taking z_r into (z_s)^((s-1)/(r-1)) defines a field
morphism no matter which generator of the multiplicative groups you
take. Of course the problem is that this morphism is not canonical
(and thus doesn't provide a functorial construction).
Anyhoo, back to the point in case, what you propose is similar to what
I had originally in mind. The problem is how to obtain the original
value of "p^m". In the example mentioned before one has
sage: b = gap("Z(2^4)^5")
sage: b
Z(2^2)
sage: b.Field()
GF(2^2)
so, b was initially defined as an element of GF(16), but GAP standard
form forgets about it and considers it an element of GF(4). I don't
see any way out of this, so it looks like the only reasonable sage()
method cannot return anything but an element of sage's GF(4), as there
is no way to know what the original field of definition was. I already
have some code that does this and works _almost_ fine, the only
(partially related) problem being converting Z(q) into the sage
generator of GF(q) only works if q is _not_ a prime, because by
default GF(p) returns "1" as its generator, rather than a primitive
element.
sage: K = GF(5)
sage: K.gen()
1
Is there any rationale for that or is it the result of a particular
implementation?
A possible way out of this situation I see making an optional
implementation of finite fields using Conway polynomials so that
coercion maps can be built in. I am not sure I have the skills to do
that myself. Any number theorist, out there?
I will try to give a look to cenverting elements of cyclotomic fields
this evening when I get home. Hopefully that should be easier since
coercion for cyclotomic fields is very well behaved. For what respects
elements of finite fields, I am afraid I am out of ideas here, so any
suggestions or anyone volunteering to jump in would be greatly
appreciated.
Cheers
J
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
