On Jan 23, 2008 4:08 PM, Jonathan Bober <[EMAIL PROTECTED]> wrote:
>
> I just realized a source of my confusion. The docstring that I quoted
> was not actually wrong in the way that I thought is was, but was
> apparently deceptive (to me). Perhaps some people are already aware of
> this, but GF(5), GF(25), and GF(5^100) are all different types, and so
> have different docstrings, some of which have errors.
>
> sage: F = GF(5)
> sage: K = GF(5^2,'x')
> sage: L = GF(5^100,'x')
>
> sage: type(F)
> <class 'sage.rings.finite_field.FiniteField_prime_modn'>
> sage: type(K)
> <type 'sage.rings.finite_field_givaro.FiniteField_givaro'>
> sage: type(L)
> <class 'sage.rings.finite_field_ext_pari.FiniteField_ext_pari'>
>
> I earlier quoted the docstring for
> sage.rings.finite_field_givaro.FiniteField_givaro. Assuming that 'small'
> means 'implemented using givaro', I guess (from Martin's email) that for
> fields F implemented using givaro F.gen() is always a multiplicative
> generator. But for prime fields constructed with GF(), F.gen() is always
> 1, and for large fields, F.gen() is 'just' a root of the defining
> polynomial, whatever that happens to be.
>
> In fact, if I force the construction of a givaro-implemented prime
> field, then the generator is not 1.
>
> sage: H = sage.rings.finite_field_givaro.FiniteField_givaro(5)
> sage: H.gen()
> 2
>
> So the state of the docstrings is
>
> sage: sage.rings.finite_field.FiniteField_prime_modn.gen?
> [...]
> Docstring:
>
> Return generator of this finite field.
> (Nothing wrong here I suppose, but I think that it is always going to
> return 1.)
>
>
> sage: sage.rings.finite_field_givaro.FiniteField_givaro.gen?
> [...]
> Docstring:
>
> Return a generator of self. All elements x of self are
> expressed as log_{self.gen()}(p) internally. If self is
> a prime field this method returns 1.
>
> (The sentence "If self is a prime field..." is wrong, but the first
> sentence is correct.)
This is now trac #1902:
http://trac.sagemath.org/sage_trac/ticket/1902
>
> sage: sage.rings.finite_field_ext_pari.FiniteField_ext_pari.gen?
> [...]
> Docstring:
>
> Return chosen generator of the finite field. This generator
> is a root of the defining polynomial of the finite field, and
> is guaranteed to be a generator for the multiplicative group.
>
> (This is wrong because in this case the generator is not guaranteed to
> be a generator for the multiplicative group.)
I've made this trac #1901:
http://trac.sagemath.org/sage_trac/ticket/1901
>
> I think that the ultimate source of my confusion is that GF is not a
> class, but is actually a function that returns a instance of any one of
> at least 3 different classes. I feel that if it's somehow possible I
> would much prefer if FiniteField was a type all its own, and if all
> finite fields were of type FiniteField, and the difference in
> implementations was completely invisible. (I'm pretty sure that there
> are other instances of this type of thing in sage.)
>
That's not going to happen. It used to be the case that there was
only 1 finite field class, but it was very slow. Now there are
three -- written by three different people (at least) -- but (some of them at
least) are vastly faster. The solution in this case should to clean up
and unify the documentation and the actual definitions of the functions
so they are consistent. This just takes actual thought and work.
> At the very least, there should probably be some sort of uniformity in
> the docstrings, but I'm not sure exactly how this should work.
>
> (Additionally, I was just thinking that it might be nice to have a
> standard "SEE ALSO:" section in the documentation. For example
>
> SEE ALSO: multiplicative_generator()
>
> The online documentation could even automatically generate links for
> this.)
>
> Anyway, that was quite a long email. Congratulations and apologies if
> you read it all.
>
> -bober
>
>
> On Tue, 2008-01-22 at 00:16 +0000, Martin Albrecht wrote:
> > > In this case, the docstring needs to be corrected, because the statement
> > > that "All elements x of self are expressed as log_{self.gen()}(p)
> > > internally" is not true, right? (Extrapolating from this sentence and my
> > > two examples led me to make my previous statements.) Probably it is true
> > > that all elements are expressible as polynomials in x, and perhaps this
> > > is also the internal representation.
> >
> > Hi,
> >
> > It is not. For small extension fields of order < 2^16 the elements are
> > represented using Zech logs internally, so for these finite fields the
> > docstring "all elements x of self are expressed as log_{self.gen()}(p)
> > internally" is true.
> >
> > Martin
> >
> >
>
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
