Hi,
The following piece of code seems to error out:
sage: C = BinaryGolayCode()
sage: c = C[1]; c.change_ring(ZZ) # This works
(1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 1)
sage: c = C[20]; c.change_ring(ZZ) # This gives error
...
TypeError: element (= [0, 0, 1, 0, 1, 0,
On 17 April 2012 08:15, P Purkayastha wrote:
> Hi,
> The following piece of code seems to error out:
> sage: C = BinaryGolayCode()
> sage: c = C[1]; c.change_ring(ZZ) # This works
> (1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 1)
> sage: c = C[20]; c.change_ring(ZZ) # Thi
Now that we're (hopefully) nearing the sage-5.0 release, I am doing some
timings again. We don't yet have proper automatic timing testing, but
with some simple scripting I discovered that plotting has severely
slowed down. I haven't figured out precisely why.
For example the following command (i
An easy way to test this using timeit() (best out of 20 runs):
sage:
timeit('''plot(sin(x),(x,0,2*pi),ticks=pi/3,tick_formatter=pi).save("/tmp/1.png")''',
number=1, repeat=20)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
Consider the file
http://boxen.math.washington.edu/home/jdemeyer/integral_points.sage
(based on a doctest in ell_rational_field.pyx):
E = EllipticCurve([-879984,319138704])
P1 = E.point((540,1188))
P2 = E.point((576,1836))
P3 = E.point((468,3132))
P4 = E.point((612,3132))
P5 = E.point((432,4428))
On 17 April 2012 11:28, Jeroen Demeyer wrote:
> Consider the file
> http://boxen.math.washington.edu/home/jdemeyer/integral_points.sage
> (based on a doctest in ell_rational_field.pyx):
>
> E = EllipticCurve([-879984,319138704])
> P1 = E.point((540,1188))
> P2 = E.point((576,1836))
> P3 = E.point(
On Tuesday, April 17, 2012 5:52:42 PM UTC+8, Jeroen Demeyer wrote:
>
> An easy way to test this using timeit() (best out of 20 runs):
>
> sage:
>
> timeit('''plot(sin(x),(x,0,2*pi),ticks=pi/3,tick_formatter=pi).save("/tmp/1.png")''',
> number=1, repeat=20)
>
Maybe the slowdown is not in matplotl
Hi there,
Is there a more or less stable url where anyone can access to the html doc of
the latest devel version of Sage ?
Cheers,
Florent
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googl
Aaaahhh -- Thanks for the tip!!
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sa
> #12313 still needs testing, but my 32-bit laptop is at home and I will
> not be able to do that until Tuesday evening. I have a 32-bit desktop
> right here but it only has 5.0beta6 on it. I have just started
> building beta13, and when that's done I'll test #12313.
>
Thanks a lot.
Once you re
Is it normal that after changing $SAGE_ROOT/devel/sage/module_list.py
it is not enough to do sage -b, but sage -ba is required?
I just made some changes as I am testing a new eclib spkg which
required editing module_list.py since the new version has only one
library file instead of 4, and was surp
On 2012-04-17 13:48, John Cremona wrote:
> Is it normal that after changing $SAGE_ROOT/devel/sage/module_list.py
> it is not enough to do sage -b, but sage -ba is required?
>
> I just made some changes as I am testing a new eclib spkg which
> required editing module_list.py since the new version h
It scrolled away a long time ago. But I just did sage -ba and the
problem is stil there, as in this example. Note that there is no
longer a library called libcurvesntl (it was editied out of
module_list.py).
John
jec@fermat%sage13 -t sage/parallel/decorate.py
sage -t "devel/sage-main/sage/para
Since you are editing the file containing the dependency information, it is
to be expected that you sometimes need to rebuild everything (depending on
what you changed).
Having said that, I think there are some rough spots involving sage -b. I
think the case that is not handled is if you delet
I think I found it, by doing search_src("jc") (!):
misc/cython.py:233:'curvesntl', 'g0nntl', 'jcntl', 'rankntl',
from
standard_libs = ['mpfr', 'gmp', 'gmpxx', 'stdc++', 'pari', 'm', 'curvesntl', \
'g0nntl', 'jcntl', 'rankntl', 'gsl', cblas(),
atlas(), 'ntl', 'csage']
N
Yes, that has done the trick. [I wonder if it is documented that
there are all these different places where spkgs installed libraries
need to be listed correctlyI must confess that I never looked as I
though I knew]
One more testall and if successful, there will soon be a new eclib
spkg u
I can confirm this with other examples, about a 25-50% slowdown. I'm
sorry I don't have any intermediate versions to bisect this with
currently, as you are right that this is not good.
On Apr 17, 5:52 am, Jeroen Demeyer wrote:
> An easy way to test this using timeit() (best out of 20 runs):
>
>
On 2012-04-17 12:41, Florent Hivert wrote:
> Hi there,
>
> Is there a more or less stable url where anyone can access to the html doc of
> the latest devel version of Sage ?
There isn't, but there probably *should* be.
--
To post to this group, send an email to sage-devel@googlegroups.com
I really hope it isn't my category stuff again - I thought I had fixed it
in #11900.
Cheers,
Simon
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group
If it helps, I am not experiencing this slowdown with 5.0.beta7
(meaning, the example takes about the same time to complete on 4.8 as
on 5.0.b7)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegr
Hi!
I'm analyzing the computation using prun, and get with some recent
unpatched beta version:
ncalls tottime percall cumtime percall filename:lineno(function)
1856817.0710.000 34.6580.000 ell_generic.py:491(__call__)
5729266.3900.000 23.0030.000 ell_point
In the very recently
merged http://trac.sagemath.org/sage_trac/ticket/11599, I updated the
scheme homset stuff to new-style parents etc. This is probably the reason
for the minor slow-down.
On Tuesday, April 17, 2012 2:20:13 PM UTC-4, Simon King wrote:
>
> Hi!
>
> I'm analyzing the computat
Hi Volker,
On 2012-04-17, Volker Braun wrote:
> --=_Part_58_7237663.1334687133477
> Content-Type: text/plain; charset=ISO-8859-1
>
> In the very recently
> merged http://trac.sagemath.org/sage_trac/ticket/11599, I updated the
> scheme homset stuff to new-style parents etc. This is probably
On 2012-04-17 20:20, Simon King wrote:
> Did you have created a ticket already?
This is now http://trac.sagemath.org/sage_trac/ticket/12853
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups
This is now http://trac.sagemath.org/sage_trac/ticket/12854
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-de
I started getting MemoryErrors while merging Sage releases and it was
also mentioned at #12313. Building the Sage documentation needs a lot
of memory. On 64-bit machines at least, you need *more than 2GB* of
virtual memory to build the documentation, this is probably more than
what you need to bu
I'm working on some p-adic modular symbols code, and am writing a file that
uses zn_poly. Unfortunately, when I try to compile, I get the following
error from gcc:
$SAGE_ROOT/local/include/zn_poly/zn_poly.h:72: error: redefinition of
typedef 'pari_ulong'
$SAGE_ROOT/local/include/pari/parigen.h:19
Hi,
sage 5.0 beta11, on Fedora 15, AMD Phenom II X4:
sage: f(x) = sin(x)^2/x^2
sage: f.integral(x, -infinity, infinity)
x |--> pi
sage: f.integral(x, -infinity, infinity).n()
3.14159265358979
sage: f.integral(x, -5, 0).n() + f.integral(x, 0, 5).n()
3.1415769097886317
everthing fine so fa
On Tue, 17 Apr 2012 16:56:52 David Roe wrote:
> I'm working on some p-adic modular symbols code, and am writing a file that
> uses zn_poly. Unfortunately, when I try to compile, I get the following
> error from gcc:
>
> $SAGE_ROOT/local/include/zn_poly/zn_poly.h:72: error: redefinition of
> typed
Patching zn_poly in Sage sounds good to me
Does anyone know if this change has been incorporated into FLINT 2? It's
not worth spending a lot of time on it if it will be fixed once we upgrade
to FLINT 2.
David
On Tue, Apr 17, 2012 at 17:25, François Bissey <
francois.bis...@canterbury.ac.nz>
At the present moment flint 2.3 does not use zn_poly.
We may be incorporating some code from zn_poly in flint 2.3 in the
future, but will not need to have a dependence on zn_poly proper.
Bill.
On Apr 17, 10:30 pm, David Roe wrote:
> Patching zn_poly in Sage sounds good to me
>
> Does anyone
I reproduced this in sage 4.8, but with different results:
sage: f(x) = sin(x)^2/x^2
sage: f.integral(x, -5, 5).n()
-0.20071537570
sage: f.integral(x, -500, 500).n()
-2.0008410959e-7
sage: f.integral(x, -5, 5).n()
-2.109169e-9
The answer seems t
I reproduced this in sage 4.8, but with different results:
sage: f(x) = sin(x)^2/x^2
sage: f.integral(x, -5, 5).n()
-0.20071537570
sage: f.integral(x, -500, 500).n()
-2.0008410959e-7
sage: f.integral(x, -5, 5).n()
-2.109169e-9
The answer seems t
On Tue, 17 Apr 2012 at 11:32AM +0200, Jeroen Demeyer wrote:
> Now that we're (hopefully) nearing the sage-5.0 release, I am doing
> some timings again. We don't yet have proper automatic timing testing,
> but with some simple scripting I discovered that plotting has severely
> slowed down. I haven'
patchbot.sagemath.org says "service temporarily unavailable". Can
someone make it available again? :)
Dan
--
--- Dan Drake
- http://mathsci.kaist.ac.kr/~drake
---
signature.asc
Description: Digital signature
> So we need to look at the prealphas (which I don't have built) and see
> what happened between 4.8 and 5.0.beta1.
>
That certainly makes the Python upgrade or the mpl upgrade the most
likely suspects. I can't believe that
figure.tight_layout()
caused that much slowdown, but testing shows tha
On 4/17/12 8:00 PM, Dan Drake wrote:
On Tue, 17 Apr 2012 at 11:32AM +0200, Jeroen Demeyer wrote:
Now that we're (hopefully) nearing the sage-5.0 release, I am doing
some timings again. We don't yet have proper automatic timing testing,
but with some simple scripting I discovered that plotting ha
On 4/17/12 8:16 PM, kcrisman wrote:
So we need to look at the prealphas (which I don't have built) and see
what happened between 4.8 and 5.0.beta1.
That certainly makes the Python upgrade or the mpl upgrade the most
likely suspects. I can't believe that
figure.tight_layout()
caused that m
The 4.8 stuff is probably due to a previous Maxima.
In the 5.0 betas, I suspect this particular one is related to things
like
http://trac.sagemath.org/sage_trac/ticket/8321
GSL is hiccuping, I guess.
See also
sage: f.nintegral(x,-5,5)
ValueError: Maxima (via quadpack) cannot compute t
On Tue, 17 Apr 2012 at 08:18PM -0500, Jason Grout wrote:
> Can you try commenting out these 2 lines in plot.py:
>
> # tight_layout adjusts the *subplot* parameters so ticks
> aren't cut off, etc.
> figure.tight_layout()
>
> in the current beta and seeing if that fixes the problem?
On 4/17/12 9:29 PM, Dan Drake wrote:
On Tue, 17 Apr 2012 at 08:18PM -0500, Jason Grout wrote:
Can you try commenting out these 2 lines in plot.py:
# tight_layout adjusts the *subplot* parameters so ticks
aren't cut off, etc.
figure.tight_layout()
in the current beta and seein
41 matches
Mail list logo
