Hello,
We had a related discussion with Peter Bruin for algebraic closure of
finite fields
sage: GF(3).algebraic_closure('a')
versus
sage: GF(3).algebraic_closure()
(the default argument is 'z'). See #14990 and particularly comments
16, 33, 34 and 36.
+1 for a default argument for finite
I would also be nice to be able to pass GF(3,3).
If I ever find some time to implement it, I'll do it, but anyone can feel
free to do it before I do.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving
Hello,
My argument against making the 'name' argument for FiniteField optional was
that it hides the fact that the generator of a finite field is not
canonical. On the other hand, once an algebraic closure of GF(p) has been
fixed, there is a unique subfield of p^n elements for every n. Hence
On Tuesday, December 30, 2014 10:18:03 AM UTC+1, vdelecroix wrote:
+1 for a default argument for finite fields, but definitely not 'x'. I
IMHO x, y, and z are out. Maybe A.
If your computation does not depend on the choice of generator then it is
invariant under the Galois action, which
On 2014-12-30, Nathann Cohen nathann.co...@gmail.com 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
On 2014-12-30, Jean-Pierre Flori jpfl...@gmail.com 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,
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-29, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_7027_1620461608.1419885835815
Content-Type: multipart/alternative;
boundary==_Part_7028_710634402.1419885835815
--=_Part_7028_710634402.1419885835815
Content-Type: text/plain; charset=UTF-8
On Monday,
On 2014-12-30, Peter Bruin pjbr...@gmail.com 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
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?
Dima
Peter
Op dinsdag 30 december 2014 12:35:30 UTC+1 schreef Dima Pasechnik:
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
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
On 2014-12-30 11:12, Peter Bruin wrote:
GF(p, n) = GF(p^n) = GF(p).algebraic_closure().subfield(n)[0]
With this convention, an added benefit is that the distinguished
generator of GF(p, n) is called 'z' + str(n), which is less likely to be
confusing than just 'z'. For example:
sage:
Hi Dima,
On 2014-12-30, Dima Pasechnik dimp...@gmail.com wrote:
As long as you only insert at the end (append) I don't see why you wouldn't
use an array. You can append to std::vector in amortized constant time.
No, the whole point of geobuckets is to make addition fast, and
only
I just created two tickets for this:
http://trac.sagemath.org/ticket/17568 (Allow syntax FiniteField(p, n))
http://trac.sagemath.org/ticket/17569 (Allow creating finite fields without
a variable name)
Peter
Op dinsdag 30 december 2014 11:12:32 UTC+1 schreef Peter Bruin:
Hello,
My argument
I just created two tickets for this:
THanks !!! :-)
Nathann
--
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.
On 2014-12-30, Jean-Pierre Flori jpfl...@gmail.com 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
On Tuesday, December 30, 2014 3:23:11 PM UTC+1, Simon King wrote:
[...] But my impression is that addition (basically
merging of two sorted lists into one) is rather complicated when sorted
lists are implemented as arrays.
Its just merge sort, right?
[...] get std::vector work with
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.
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)
IMHO you need C/C++ if memory locality is important for you because
Python/Cython does not give you control over memory location; PyObject
memory is always managed by Python and will be randomly on the heap.
Whereas in C++ you can allocate objects in a contiguous array, or even by
placement
On 2014-12-30, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_8311_2092865628.1419974826414
Content-Type: multipart/alternative;
boundary==_Part_8312_1157955583.1419974826414
--=_Part_8312_1157955583.1419974826414
Content-Type: text/plain; charset=UTF-8
IMHO you need
Hi Dima,
On 2014-12-30, Dima Pasechnik dimp...@gmail.com wrote:
Isn't it true that numpy arrays integrate well with cython?
At least if all you need is builtin Python object types (e.g. int or
float), or arrays of pointers to Python objects, they may well be used.
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):
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
Hi Volker,
On 2014-12-30, Volker Braun vbraun.n...@gmail.com wrote:
Can you give me a pointer how I can use in C++ the ctypedef struct
biseq_s
that is defined in sage/data_structures/bounded_integer_sequences.pxd?
You just have to make it ctypedef public struct biseq_s:
On Wednesday, December 31, 2014 12:15:08 AM UTC+1, Simon King wrote:
So, why is the name not sage.data_structures.bounded_integer_sequences.h?
Don't know, might be a bug.
I wonder how to include the header. It did not end up in local/include/.
Yes, I don't think we have that yet. All
27 matches
Mail list logo
