On Tue, Dec 30, 2014 at 2:47 PM, Nils Bruin wrote:
> On Tuesday, December 30, 2014 1:05:43 PM UTC-8, William wrote:
>>
>> sage: R. = QQ[]
>> sage: S. = QQ[]
>> sage: x + y
>> [BOOM] -- see [1]
>
>
> Magma does have the capability of having multiple univariate polynomial
> rings (and multivariate o
On Tuesday, December 30, 2014 1:05:43 PM UTC-8, William wrote:
>
> sage: R. = QQ[]
> sage: S. = 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):
> R:=PolynomialRing(Ration
On Tue, Dec 30, 2014 at 12:04 PM, Dima Pasechnik wrote:
> On 2014-12-30, Jeroen Demeyer 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 k>1 - you cannot just pass GF(9) to a function!
>>> You need to
On 2014-12-30, Jeroen Demeyer 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 k>1 - you cannot just pass GF(9) to a function!
>> You need to do F.=GF(9) first and then pass F.
>
> You can still do 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 k>1 - you cannot just pass GF(9) to a function!
You need to do F.=GF(9) first and then pass F.
You can still do GF(9,'x'), you don't *need* the F.<> = GF() syntax.
--
On 2014-12-30, Jean-Pierre Flori wrote:
> --=_Part_21_1444155964.1419945023642
> Content-Type: multipart/alternative;
> boundary="=_Part_22_1069108554.1419945023642"
>
> --=_Part_22_1069108554.1419945023642
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: q
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. = GF(3, 5)
>>
>> and the following should also lead to the same thing:
>>
>> sage: F. = GF(3^5)
>>
>> We
Le 30/12/2014 13:31, Jean-Pierre Flori a écrit :
Anyhow, the above looks ugly. How about
sage: F. = GF(3, 5)
and the following should also lead to the same thing:
sage: F. = GF(3^5)
We already have that, or am I missing something?
We have only the second one. I haven't checke
Anyhow, the above looks ugly. How about
> sage: F. = GF(3, 5)
>
> and the following should also lead to the same thing:
>
> sage: F. = GF(3^5)
>
> We already have that, or am I missing something?
> Dima
>
> >
> > Peter
> >
> >
> > Op dinsdag 30 december 2014 12:35:30 UTC+1 schreef Dim
On 2014-12-30, Peter Bruin wrote:
> --=_Part_23_512688967.1419940866648
> Content-Type: multipart/alternative;
> boundary="=_Part_24_1059076605.1419940866648"
>
> --=_Part_24_1059076605.1419940866648
> Content-Type: text/plain; charset=UTF-8
>
> Just to clarify, typing GF(p, n)
Just to clarify, typing GF(p, n) would not insert the name 'z' + str(n)
into the global namespace, it would just mean that elements are printed
using this variable name. One would still have to do something like
sage: F, z5 = GF(3, 5).objgen()
to be able to use z5 on the command line.
Peter
On 2014-12-30, Jean-Pierre Flori wrote:
> --=_Part_7226_1855919527.1419939792163
> Content-Type: multipart/alternative;
> boundary="=_Part_7227_239517614.1419939792164"
>
> --=_Part_7227_239517614.1419939792164
> Content-Type: text/plain; charset=UTF-8
>
>
>
> On Tuesday, Decemb
On Tuesday, December 30, 2014 12:35:30 PM UTC+1, Dima Pasechnik wrote:
>
> On 2014-12-30, Nathann Cohen > 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.
> >
On 2014-12-30, Nathann Cohen 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 t
14 matches
Mail list logo
