On 2012-11-04 01:06, Volker Braun wrote:
> You make it sound like there is just not enough doctesting coverage. The
> Sage doctests generally do not generate a lot of parents in one go.
> Maybe its just that the coverage of this use case needs to be improved?
> E.g. create a list of thousands of pa
On 2012-11-04 01:23, Francois Bissey wrote:
> But nevertheless we have to just bit the bullet, do the best we can
> and fix things as they become apparent. We cannot stop moving forward
> because we are afraid to break stuff accidentally forever.
OK, let's go for it!
Do you want also other tickets
On 04/11/12 21:36, Jeroen Demeyer wrote:
> On 2012-11-04 01:23, Francois Bissey wrote:
>> But nevertheless we have to just bit the bullet, do the best we can
>> and fix things as they become apparent. We cannot stop moving forward
>> because we are afraid to break stuff accidentally forever.
> OK,
While compiling the latest source from the web, I got this message:
Error installing package scipy-0.9.p1
I'm using a MacBook Pro with OS 10.8.2, 2.9 GHz Intel Core i7. I have never
installed something from the source code before, so I am a little lost at this
point. I have been following the d
I don't know if this is the right place and time to ask this: what
about morphisms for Parent with generators? I mean, in some cases, you
can define a morphism just by passing a list with the images of the
generators to .hom() But apparentñy, it has to be done by hand for
each case. Would it be pos
On Saturday, November 3, 2012 4:23:57 PM UTC, jason wrote:
> That's how analogous is_* commands are defined
Yes, you are right. I got myself confused there.
I agree with your patch except that it might be nice to still check the
matrix dimensions if it is a matrix. Just to give a more human
On Saturday, November 3, 2012 7:06:24 PM UTC-7, Daniel wrote:
>
> While compiling the latest source from the web, I got this message:
>
> Error installing package scipy-0.9.p1
>
> I'm using a MacBook Pro with OS 10.8.2, 2.9 GHz Intel Core i7.
>
This is a known problem with OS X 10.8, and it
That worked. Thank you so much!!
On Sunday, November 4, 2012 9:31:57 AM UTC-6, John H Palmieri wrote:
>
>
> This is a known problem with OS X 10.8, and it will be fixed in an
> upcoming release (tentatively scheduled for Sage 5.4.1). Meanwhile, try
> this (from the command line): change director
I'm playing around with different ways to create collections of symbolic
variables. I though it would be nice to be able to chain subscripts, e.g.,
sage: x[1][2]
x12
sage: latex(x[1][2])
x_{1}_{2}
but while implementing __getitem__(), I ran into the following test:
Indexing directly wi
I realized that computing gcd and Bezout coefficients of polynomials
of high degree over finite field is quite slow:
sage: k. = GF(2^50)
sage: A. = k[]
sage: a = A.random_element(200)
sage: b = A.random_element(199)
sage: timeit("d,u,v = a.xgcd(b)")
5 loops, best of 3: 15.6 s per loop
And it's a
I have some polynomial P with coefficients in a finite field
(represented in Sage by a NTL object) and I want to write it
as follows:
P(X) = P_0(X^r) + X*P_1(X^r) + ... + X^(r-1)*P_(r-1)(X^r)
where r is a fixed small integer (say r=3 for instance).
Of course, I can build the list of coefficient
This is the kind of problem that you'll get huge speedups by using Cython
and NTL directly rather than Python lists. For example, here's a prototype
(not tested and probably buggy). In particular, I don't know if you can
destruct a ZZ_pEX_c that has been created with ZZ_pEX_new, and I'm not sure
On Sun, Nov 4, 2012 at 8:28 AM, Xavier Caruso
wrote:
> I realized that computing gcd and Bezout coefficients of polynomials
> of high degree over finite field is quite slow:
>
> sage: k. = GF(2^50)
> sage: A. = k[]
> sage: a = A.random_element(200)
> sage: b = A.random_element(199)
> sage: timeit(
13 matches
Mail list logo