I think I'd describe it as a feature to reduce the number of GF(7)s floating around. There's no coercion from ZZ[x] to GF(p), regardless of the choice of modulus. The modulus function on FiniteField_prime_modn is there for consistency of interface with the other finite fields. Is there a reason you need different copies of GF(p) with different variable names or moduli? Or should we just update the documentation? David
On Mon, Nov 14, 2011 at 08:06, luisfe <lftab...@yahoo.es> wrote: > I find that this is not coherent with documentation of Finite Field. > > """ > sage: G=GF(7,'a',modulus=QQ[x](x+2)) > sage: G.modulus() > x + 6 > sage: G.variable_name() > 'x' > sage: G.polynomial_ring().hom([G.gen()]) > Ring morphism: > From: Univariate Polynomial Ring in x over Finite Field of size 7 > To: Finite Field of size 7 > Defn: x |--> 1 > """ > > Is this intended for cache reasons or is a bug? I mean cache eficiency > for the following doctest in finite_rings/constructor.py > > """ > sage: K = GF(7, 'a') > sage: L = GF(7, 'b') > sage: K is L > True > """ > > Which esentially says that the generator name is ignored in this case. > > -- > 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
