[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() david --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
THere's a ticket somewhere asking for the implementation of sensible coercion between finite fields. Obviously only F_q - F_q' where q' ia a power of q. But I have no idea how to do this in a way which is canonical -- so at the very least is transitive so that q - q' - q is the same as q-q. If anyone out there has an idea here it would be good to hear it. Is the following a sensible strategy: For each prime p maintain a list of fields of p-power order which have been created so far, with maps between them, always normalised to that if n is the largest degree of a field in the list (i.e. p^n is the largest power of p) then all the others are divisors of n. Now, on the creation of a new field of size p^m, if n|m then (do something fairly simple), or if gcd(n,m)=1 then (do something else fairly simple, else (do something more complicated). Does anyone know how Magma handles this? John 2008/4/14 David Harvey [EMAIL PROTECTED]: On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() david --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Sun, Apr 13, 2008 at 09:50:44AM -0700, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. I've made this ticket #2916. The patch I attached there catches a missing case in FiniteField_givaro.__call__ and throws a TypeError, which appears to be the intent of the function according to the existing docstring. -Willem Jan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial, in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?id=268929).
If you implement this I will be forever in your debt.
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
2008/4/14 Nick Alexander [EMAIL PROTECTED]:
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?id=268929).
If you implement this I will be forever in your debt.
Very tempting!
Perhaps you should mention that the authors of that paper are the
Magma trio Bosma, Cannon and Steele. I have just printed it and will
take a look.
John
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
I implemented this while converting finite fields over to the new
coercion model, but it only works when we Conway polynomials are used
to define the extension (the default if the database goes that high).
Conway polynomials can be expensive to compute, so if one is not
available we don't want to do that on the fly, but if one keeps track
of all fields created one can dynamically create a set of compatible
embedding (which is described in the paper referenced below).
- Robert
On Apr 14, 2008, at 8:53 AM, Nick Alexander wrote:
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?
id=268929).
If you implement this I will be forever in your debt.
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF(3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) -cc --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 9:23 AM, Craig Citro wrote: Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF (3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) I looked at the paper a bit too, and had the same feeling. However, I think the key insight is (and I'm not sure if this is stated in their paper) that the choice of polynomial isn't important, it's the choice of morphism that one has to be clever with. Specifically, suppose one has F_p^n and one wants to create F_p^n. One can choose any (irreducible) polynomial of degree n, and then (by looking at how the defining polynomials factor over higher fields, which isn't too hard) chooses embeddings F_p^gcd(m,n) - F_p^n - F_p^lcm(m,n) compatible with F_p^gcd(m,n) - F_p^m - F_p^lcm(m,n). Though I haven't worked out all the details I am pretty sure this is the basic idea, and I'm sure there's lots of additional optimizations one can make. - Robert --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: On 14-Apr-08, at 9:21 AM, Robert Bradshaw wrote: I implemented this while converting finite fields over to the new coercion model, but it only works when we Conway polynomials are used to define the extension (the default if the database goes that high). Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) The 3.1 - 3.2 release will be a coercion release only. - Robert --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 6:57 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: SNIP Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) The plan is to get 3.0 out in the next two, three days and we are certainly getting close to that goal. On the list of things to be done most real blockers have been fixed from my point of view, now it is merging back a bunch of build fixes and getting components like the pexpect R interface and the benchmarking framework in. [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) I have update the roadmap to reflect how I would anticipate things going down: 3.0: soon [past experience has told us that things can be late, but now we are at the end of the normal two week release window] 3.0.1: three, four days after 3.0 - a bug fix only release. This should provide ample time for the coercion people to make their code work with 3.0 while minimizing any disturbing conflicts relative to the 3.0 code base while we fix the inevitable issues that happened in the 2.11-3.0 transition 3.1: three, four days after 3.0.1 - merge the updated coercion code right at the start, add the usual set of small fixes and get a release out as soon as possible. Details http://trac.sagemath.org/sage_trac/roadmap [dates can and probably will move around] The 3.1 - 3.2 release will be a coercion release only. - Robert Thought? Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 10:28 AM, mabshoff wrote: On Apr 14, 6:57 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: SNIP Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) The plan is to get 3.0 out in the next two, three days and we are certainly getting close to that goal. On the list of things to be done most real blockers have been fixed from my point of view, now it is merging back a bunch of build fixes and getting components like the pexpect R interface and the benchmarking framework in. [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) I have update the roadmap to reflect how I would anticipate things going down: 3.0: soon [past experience has told us that things can be late, but now we are at the end of the normal two week release window] 3.0.1: three, four days after 3.0 - a bug fix only release. This should provide ample time for the coercion people to make their code work with 3.0 while minimizing any disturbing conflicts relative to the 3.0 code base while we fix the inevitable issues that happened in the 2.11-3.0 transition 3.1: three, four days after 3.0.1 - merge the updated coercion code right at the start, add the usual set of small fixes and get a release out as soon as possible. Details http://trac.sagemath.org/sage_trac/roadmap [dates can and probably will move around] The 3.1 - 3.2 release will be a coercion release only. - Robert Thought? One week is almost certainly over-optimistic for having all the coercion stuff ready to go in, and so I am thinking that there would almost certainly be enough development between now and then to warrant a normal (non-bugfix-only) release first. I do really want to isolate the coercion model going in from all other changes (though if there is a critical bugfix I understand). - Robert --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 06:16 , David Harvey wrote: On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() Even more interesting is what I get (Sage 2.11, Mac OS X, 10.5.2): sage: F9.a=GF(9) sage: F81.b=GF(81) sage: F81(a) 0 sage: trace(F81(a)) string(1)module() (Pdb) s ...[more 's' ] [SNIP] /Volumes/Zeppo/SandBox/Justin/sb/sage-2.11/finite_field_givaro.pyx in sage.rings.finite_field_givaro.FiniteField_givaro.log_to_int() type 'exceptions.IndexError': n=110973296 must be self.order() sage: More interesting still is that, when I retry the 'trace', I get the exception right away, no (Pdb) prompt. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- I'm beginning to like the cut of his jibberish. --- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 8:16 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 10:28 AM, mabshoff wrote: SNIP Thought? One week is almost certainly over-optimistic for having all the coercion stuff ready to go in, and so I am thinking that there would almost certainly be enough development between now and then to warrant a normal (non-bugfix-only) release first. I do really want to isolate the coercion model going in from all other changes (though if there is a critical bugfix I understand). Ok, that certainly sounds reasonable and I don't see a problem to make either a slightly longer 3.0.1 bug fix release [i.e. a week] or even throw in a second 3.0.2 bug fix release [maybe even with small features]. Either way, let us know about the status changes about the coercion rewrite as you guys go along so we can adjust the release plans accordingly. - Robert Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Mon, Apr 14, 2008 at 12:23 PM, Craig Citro [EMAIL PROTECTED] wrote: Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF(3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) -cc --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
Grrr... I clicked reply, and then tried to click on the text field to begin typing, and it scrolled down at exactly the wrong moment and the right amount so that I clicked send insteady. Sorry about that. David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: I haven't worked on this much, aside from keeping it in mind when designing the coercion system. Once we have the coercion branch merged back in, we should have the appropriate framework for writing all this and making it happen in an appropriately automatic fashion. As for timeline, the conclusion that Robert and Michael came to sounds reasonable to me. I'll try to finish the work we want to do before the 3.0 release so that once 3.0 comes out we can just merge. When the coercion release comes (which sounds like 3.1), Robert and I will write about how YOU can help. :-) Basically, we're trying to make the global changes that need to happen all at once across all of Sage, but there will be a lot of places where we've left intermediate solutions in place: keeping the current functionality of Sage operational while transforming the structure to make improvement possible on a local scale. As a result, there will be lots of little things that you can do, in your favorite part of Sage, to take advantage of the new framework. We'll give you more details in a few weeks. David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 11:20 pm, David Roe [EMAIL PROTECTED] wrote: Grrr... I clicked reply, and then tried to click on the text field to begin typing, and it scrolled down at exactly the wrong moment and the right amount so that I clicked send insteady. Sorry about that. David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: I haven't worked on this much, aside from keeping it in mind when designing the coercion system. Once we have the coercion branch merged back in, we should have the appropriate framework for writing all this and making it happen in an appropriately automatic fashion. Hi David, As for timeline, the conclusion that Robert and Michael came to sounds reasonable to me. I'll try to finish the work we want to do before the 3.0 release so that once 3.0 comes out we can just merge. The interesting issue I see right now if the symbolics framework by Gary will go in before or after the coercion rewrite. I would prefer if coercion went in first, but that is something you guys should talk about. Other than that I do not see anything that would interact badly with coercion come up in the next couple weeks. When the coercion release comes (which sounds like 3.1), Robert and I will write about how YOU can help. :-) Basically, we're trying to make the global changes that need to happen all at once across all of Sage, but there will be a lot of places where we've left intermediate solutions in place: keeping the current functionality of Sage operational while transforming the structure to make improvement possible on a local scale. As a result, there will be lots of little things that you can do, in your favorite part of Sage, to take advantage of the new framework. We'll give you more details in a few weeks. Ok, if I understand this correctly after the merge we will have the following situation: * everything will keep working [modulo a buglet here or there] * but people need to modify some code to take advantage of the new shiny features Am I getting this wrong? Am I missing anything. David Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
