Martin,
I've been getting very annoyed with Pyrex because if you put a "cdef
extern" in one
file (say a pxi file), e.g., to define size_t, and put the same in another
pxi file,
then you can't import both pxi files. Sometimes you might want just one,
sometimes
just the other, and sometimes
Yes, that works for me. I just don't know how to use MAGMA.
Here is the script I used:
a:=[1 .. 255 by 1];
b:=[1 .. 255 by 1];
for i:=1 to 1000 do
for j:= 1 to 255 do
a[j]:=RandomBits(1000);
b[j]:=RandomBits(1000);
end for;
temp:=Polynomial(a)*Polynomial(b);
end for;
I still don't see why that
On Fri, 20 Oct 2006, Bill Hart wrote:
> I can't get MAGMA to go that fast.
>
> I timed it doing 1000 multiplies of degree 255 polynomials with
> coefficients of 1000 bits. It took 15 seconds or thereabouts.
I'm getting 3.7 seconds with version V2.12-20 and 6.9 seconds with
version V2.13-5. I'
David,
I was looking at DualAbelianGroup. I'm very surprised you made it map to
floating point complex numbers, at least for finite groups. It would make
way more sense to make to a cyclotomic field instead, since everything
would
be exact then. That's how I define Dirichlet characters, whic
Mark (Address may be forged. Please contact [EMAIL PROTECTED]) wrote:
> William,
>
> If sage is truly pushing Pyrex's limits, then it is likely that with
> some gentle proding the pyrex author (Ewing?) should responsive to
> needs ... since sage will be a great test case for pyrex.
>
I think t
On Friday 20 October 2006 22:37, William Stein wrote:
> A monolothic build to /opt that somewhat works in the context of each
> of several Linux distribitions *would* be very useful whilst still not
> conflicting with how SAGE works. I could host all those binaries on
> sage.math. We made one fo
