Re: [sage-devel] Re: GF(3) but GF(9,'x')
Le 30/12/2014 13:31, Jean-Pierre Flori a écrit : Anyhow, the above looks ugly. How about sage: F.z5 = GF(3, 5) and the following should also lead to the same thing: sage: F.z5 = GF(3^5) We already have that, or am I missing something? We have only the second one. I haven't checked exactly what happens with the first, but the result is as follows: sage: F.z5 = GF(3, 5) sage: F Finite Field of size 3 Note also that some kind of mechanism exists for finite fields defined by Conway polynomials. One needs to give a prefix, and then the variable name becomes 'z'+str(n) for GF(p^n,conway=True,prefix='z'). One could argue that we should make 'z' (or something else) the default prefix these finite fields, though we have the same problem as mentioned above of z5 denoting the variable for GF(2^5, ...) and GF(3^5, ...). Also, even if it may be a bit orthogonal to the present discussion, it may be a good idea to homogenize the interface, allowing the prefix=... construction even without conway, and allowing the name=... when conway=True. Bruno Dima Peter Op dinsdag 30 december 2014 12:35:30 UTC+1 schreef Dima Pasechnik: On 2014-12-30, Nathann Cohen nathan...@gmail.com javascript: wrote: I wondered about this syntax. You can build a finite field from a prime number with GF(p), but if what you have is a prime power you should write GF(q,'x') instead. I very often need to create a lot of finite fields, but I could not care less about this 'x' and so I type this even though I do not need it. Would it make sense to you if we made this argument optional ? It would be 'x' by default, or anything else that you would prefer. I don't see how this would play out nicely if you, say, define GF(27) and then define GF(9). Would the latter definition invalidate the former? In GAP this is solved by having a special indexed variable Z(p^k), for p a prime and k a natural number. Then after defining GF(27) and then defining GF(9) you can still refer to the elements of the former as a*Z(27)^i, for a and i integers. If something similar can be done in Sage, OK. Otherwise, -1. Dima -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com mailto:sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com mailto:sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GF(3) but GF(9,'x')
On Tuesday, December 30, 2014 1:40:29 PM UTC+1, Bruno Grenet wrote: Le 30/12/2014 13:31, Jean-Pierre Flori a écrit : Anyhow, the above looks ugly. How about sage: F.z5 = GF(3, 5) and the following should also lead to the same thing: sage: F.z5 = GF(3^5) We already have that, or am I missing something? We have only the second one. I haven't checked exactly what happens with the first, but the result is as follows: Yes, we only have the second one, but it was not clear Dima knew it. And I'm completely sure the first one has no chance to work at the moment. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GF(3) but GF(9,'x')
On 2014-12-30 16:56, Dima Pasechnik wrote: my main complaint is that one cannot program in a functional style with GF(p^k) for k1 - you cannot just pass GF(9) to a function! You need to do F.blah=GF(9) first and then pass F. You can still do GF(9,'x'), you don't *need* the F. = GF() syntax. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GF(3) but GF(9,'x')
On Tue, Dec 30, 2014 at 12:04 PM, Dima Pasechnik dimp...@gmail.com wrote: On 2014-12-30, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2014-12-30 16:56, Dima Pasechnik wrote: my main complaint is that one cannot program in a functional style with GF(p^k) for k1 - you cannot just pass GF(9) to a function! You need to do F.blah=GF(9) first and then pass F. You can still do GF(9,'x'), you don't *need* the F. = GF() syntax. sure, but why that 'x' there? It's just a syntactic sour (as opposed to sugar :)) A critical point missing in this discussion is that in Sage rings are (supposed to be) immutable and the name of the generator of a ring is an immutable property of that ring. The 'x' is there because if you do K = GF(9,'x') and want to later *change* the name to something else, you can't, since rings (like these) are immutable. It was the case -- back in 2005 and 2006 -- that all generators of rings/fields like this did default to 'x'. I would just use the default 'x' (or other random things), then change it later if necessary.When I made these parents immutable (for the first 2 years fields like this were mutable), I changed the code to require a default explicitly, except in special cases (e.g., CyclotomicField), where there is a canonical choice. In Magma, the default generator name is $.1. But in Magma the generator name can be changed whenever -- it's not part of the immutable definition of the ring.For example, in Sage there are infinitely many different univariate polynomial rings over QQ, one for each choice of generator name. In Magma there is just one. Thus this is less (or differently) confusing in Sage than in Magma: sage: R.x = QQ[] sage: S.y = QQ[] sage: x + y [BOOM] -- see [1] Side Note: You might think that the coercion model pushout machinery would automatically construct QQ['x,y'] and do the addition there. It doesn't, because the choice of ordering of the variables isn't canonical. But in Magma the situation with the analogous code is much worse, since the S.y=QQ[] line simply changes the first x into y and we get 2*y as the result [2]! Anyways, on a case-by-case basis, if we can come up with a good sufficiently canonical choice of generator and name for it, then the explicit name shouldn't be required, as with CyclotomicField, QuadraticField, and what's in this thread. [1] https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2014-12-30-variables.sagews [2] https://cloud.sagemath.com/projects/2bfce692-d0d8-4b89-968e-d9825f175a0f/files/support/2014-12-30-vars.sagews Dima -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GF(3) but GF(9,'x')
On Tuesday, December 30, 2014 1:05:43 PM UTC-8, William wrote: sage: R.x = QQ[] sage: S.y = QQ[] sage: x + y [BOOM] -- see [1] Magma does have the capability of having multiple univariate polynomial rings (and multivariate ones are non-global by default): Rx:=PolynomialRing(Rationals():Global:=false); Sy:=PolynomialRing(Rationals():Global:=false); R; Univariate Polynomial Ring in x over Rational Field S; Univariate Polynomial Ring in y over Rational Field It's perhaps unfortunate that there is a coercion between them, though: x+y; 2*x y+x; 2*y In any case, the name of the generator is *not* part of the identity of a parent, whereas in sage it is. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GF(3) but GF(9,'x')
On Tue, Dec 30, 2014 at 2:47 PM, Nils Bruin nbr...@sfu.ca wrote: On Tuesday, December 30, 2014 1:05:43 PM UTC-8, William wrote: sage: R.x = QQ[] sage: S.y = QQ[] sage: x + y [BOOM] -- see [1] Magma does have the capability of having multiple univariate polynomial rings (and multivariate ones are non-global by default): Rx:=PolynomialRing(Rationals():Global:=false); Sy:=PolynomialRing(Rationals():Global:=false); R; Univariate Polynomial Ring in x over Rational Field S; Univariate Polynomial Ring in y over Rational Field Thanks for the clarification. I was unaware of Global:=false for PolynomialRings in Magma. I don't know if that option was there when I learned about Magma's PolynomialRings in the first place (in 1998)... It's perhaps unfortunate that there is a coercion between them, though: x+y; 2*x y+x; 2*y Yes, that's unfortunate... In any case, the name of the generator is *not* part of the identity of a parent, whereas in sage it is. Yes, that's really the key distinction. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
