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
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?
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 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
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
> 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
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
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'
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
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
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>
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
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
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
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
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
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
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
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!
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
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
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
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 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):
>
>
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 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
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
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
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
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
> #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
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
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
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
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(
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))
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
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
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
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,
41 matches
Mail list logo
