On Thursday, January 21, 2016 at 3:26:55 AM UTC+1, William wrote:
>
> On Wed, Jan 20, 2016 at 6:20 PM, William Stein > wrote:
> > Nils -- many thanks for your post explaining the longterm perspective
> > and underlying reasons why things are the way they are.
> >
> > I mentioned this thread
On Wed, Jan 20, 2016 at 6:20 PM, William Stein wrote:
> Nils -- many thanks for your post explaining the longterm perspective
> and underlying reasons why things are the way they are.
>
> I mentioned this thread in my class today, which happened to be on
> constructing finite fields in Sage:
>
>
On Wed, Jan 20, 2016 at 7:47 PM, Nils Bruin wrote:
> On Wednesday, January 20, 2016 at 3:22:54 PM UTC-8, Dima Pasechnik wrote:
>>
>>
>> to me, two fields that are specified by the same irreducible polynomial
>> over the same prime subfield ought to be identical.
>> it'd be much better design, no
On Wednesday, January 20, 2016 at 3:22:54 PM UTC-8, Dima Pasechnik wrote:
>
>
> to me, two fields that are specified by the same irreducible polynomial
> over the same prime subfield ought to be identical.
> it'd be much better design, not wedding them to named generators at all.
>
> That's not c
On Wednesday, 20 January 2016 22:18:04 UTC, Nils Bruin wrote:
>
> On Wednesday, January 20, 2016 at 1:49:12 PM UTC-8, Nathann Cohen wrote:
>>
>> If conflicts can come from the choice of a variable name, I'd say that
>> the problem is not the variable's name but the code that relies on it.
>>
>
On Wednesday, January 20, 2016 at 1:49:12 PM UTC-8, Nathann Cohen wrote:
>
> If conflicts can come from the choice of a variable name, I'd say that
> the problem is not the variable's name but the code that relies on it.
>
Conflicts do not arise from variable names (or at least not the conflicts
> how about making GF(16) default to GF(16,'conway')
> no symbols injected, no conflicts...
If conflicts can come from the choice of a variable name, I'd say that
the problem is not the variable's name but the code that relies on it.
As far as I am concerned the name can be absolutely anything yo
how about making GF(16) default to GF(16,'conway')
no symbols injected, no conflicts...
On Wednesday, 20 January 2016 21:28:21 UTC, Nils Bruin wrote:
>
> On Wednesday, January 20, 2016 at 1:04:49 PM UTC-8, John Cremona wrote:
>
>>
>> > Is there any reason to not make GF(16) behave as GF(16,'x') d
On Wednesday, January 20, 2016 at 1:04:49 PM UTC-8, John Cremona wrote:
>
> > Is there any reason to not make GF(16) behave as GF(16,'x') does,
> > unless specified otherwise? I do not see the point of requesting the
> > user to provide a character if (s)he does not care.
> >
>
> +1 for having a d
On 20 Jan 2016 19:40, "Nathann Cohen" wrote:
>
> Hello everybody,
>
> I write a lot of code that requires me to build finite fields, and the
> finite fields F_q, when q is not a prime number, cannot be
> instanciated without specifying a variable name:
>
> sage: GF(16)
> ValueError: parame
Hello everybody,
I write a lot of code that requires me to build finite fields, and the
finite fields F_q, when q is not a prime number, cannot be
instanciated without specifying a variable name:
sage: GF(16)
ValueError: parameter 'conway' is required if no name given
Thus, I always use
11 matches
Mail list logo