I haven't time right now to go through the different finite field
types in Sage, but not that Conway polynomials are not known (as far
as I know) for all combinations of characteristic and degree, so they
give a good solution for some (common) cases but not all.
Many of us would dearly like to be able to coerce from GF(p^n) to
GF(p^m) when n|m but n>1.
John
2010/1/11 javier <vengor...@gmail.com>:
> 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
>
>
--
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
