On 2013-01-07 23:54, Robert Bradshaw wrote:
> I consider startup time to be one of our biggest bugs...
I suggest to start with the notebook. Merging the flask notebook added
about 0.5s to the startup time IIRC. Which is silly since the notebook
is something which really doesn't need to be importe
On 2013-01-07 23:54, Robert Bradshaw wrote:
> Hasn't this been discussed several times already?
Yes, but this is the first time William actually agrees with me :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email t
In sage/covariant_functorial_construction.py, line 359 we still have
an uncached
def is_subcategory(self, C):
"""
.. todo:: doctests + explain why this method is needed
"""
if C is self:
return True
return any(X.is_subcategory(C) for X in
sel
kcrisman writes:
> http://hg.sagemath.org/ works fine, except that the "sage-root"
> repository gives an error. Based on the rest of that page, it looks
> like it should be root-main or just root anyway? Anyway, if someone
> knows how to fix this, that would be great.
I posted about this a few
On Mon, Jan 7, 2013 at 2:54 PM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
> Hasn't this been discussed several times already? I consider startup time
> to be one of our biggest bugs... If we need to, lets bump it to 4 or even
> 10 seconds or something so at least we don't have egregio
Hasn't this been discussed several times already? I consider startup time
to be one of our biggest bugs... If we need to, lets bump it to 4 or even
10 seconds or something so at least we don't have egregious regressions. Or
replace it with something better (e.g. it only fails if the load is so
smal
On Mon, Jan 7, 2013 at 2:45 PM, Volker Braun wrote:
> I'm fine with removing the timing, but we should test somewhere that lazy
> imports are not accidentally imported during startup. Right now that file
> checks that numpy isn't imported. Though maybe it would be good to move it
> to a better-na
I'm fine with removing the timing, but we should test somewhere that lazy
imports are not accidentally imported during startup. Right now that file
checks that numpy isn't imported. Though maybe it would be good to move it
to a better-named file ;-)
On Monday, January 7, 2013 10:21:53 PM UTC,
But the command is mostly linear algebra over QQ. Its possible that the old
GCC does something very stupid, but I doubt that you can speed up integer
computations by a factor of 5x just by optimizing code paths. So it pretty
much must be the blas inside linbox.
On Monday, January 7, 2013 9:1
The test in devel/sage/sage/tests/startup.py has been bothering me for a
while already. It's way too unreliable to be useful, it depends too
much on the system load (both I/O and CPU). And system load on
sage.math is quite high lately... Because of this, I tend to ignore
this test anyway, so we
On 2013-01-07 21:59, Volker Braun wrote:
> Its pretty clear that the newer GCC correctly vectorizes ATLAS for the
> CPU whereas the old one did not.
I doubt it's ATLAS. I didn't find any particular difference in the ATLAS
install logs. It's curious to see that ATLAS somehow brute-forces CPU
flags,
On Mon, Jan 7, 2013 at 10:53 AM, Keshav Kini wrote:
> Benjamin Jones writes:
>
>> On Mon, Dec 17, 2012 at 9:32 PM, P Purkayastha
>> wrote:
>>
>> On 12/18/2012 10:10 AM, Benjamin Jones wrote:
>>
>> if y > 0 is true,
>> is x*(y > 0) true or false?
>>
>>
>> Why is this kind
Its pretty clear that the newer GCC correctly vectorizes ATLAS for the CPU
whereas the old one did not.
On Monday, January 7, 2013 8:50:14 PM UTC, Snark wrote:
>
> >>
> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
>
>
> I'm still impre
Le 07/01/2013 20:50, Jeroen Demeyer a écrit :
On 2013-01-07 12:24, Jeroen Demeyer wrote:
I am running the command
sage: time B =
ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
sage-5.4: 17.94 s
sage-5.5: 56.28 s
I can confirm that buil
On 12/18/12 12:55 AM, Benjamin Jones wrote:
In other words, it's useful to be able to map over them, e.g. map the
function that is multiplication by a constant element of SR over a
comparison
Is it really useful? How many people take advantage of this? I thought
it was interesting, but I've
On 2013-01-07 12:24, Jeroen Demeyer wrote:
> I am running the command
>
> sage: time B =
> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
>
> sage-5.4: 17.94 s
> sage-5.5: 56.28 s
I can confirm that building Sage with GCC-4.2.4 gives the s
Benjamin Jones writes:
> On Mon, Dec 17, 2012 at 9:32 PM, P Purkayastha
> wrote:
>
> On 12/18/2012 10:10 AM, Benjamin Jones wrote:
>
> if y > 0 is true,
> is x*(y > 0) true or false?
>
>
> Why is this kind of operation (+,-,*, etc) distributive over
> comp
Hi all,
here is a link to the self-replicating live USB we discussed about in the Bobo
2012 sage days thread.
http://sagedebianlive.metelu.net/
The idea started during the preparatory sage days in november 2011 in Bobo
Dioulasso (Burkina Faso) when the best existing solution to have sage running
Someone posted this on G+
http://statisfactions.com/2013/interactive-r-code-widget/
Great work, Jason et al.!
Note the comment at the end:
PS: Sage is awesome
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to
Hi,
sage: sage.structure.sage_object.unpickle_all()
works nicely, but running it TWICE makes sage crash and exit.
This problem was in fact mentioned there :
http://trac.sagemath.org/sage_trac/ticket/5838
Looking a bit further into it, the actual pickles that trigger the problem are
those in
On Friday, January 4, 2013 12:22:18 PM UTC+1, Jeroen Demeyer wrote:
>
> On 2013-01-04 11:31, Jean-Pierre Flori wrote:
> > By the way, GCC 4.7.2 can compile ECL 12.12.1 on Cygwin, what GCC 4.6.3
> > cannot, so it would be nice to have a minimal GCC 4.7.2 spkg.
> This is harder than you think. G
On 2013-01-07 15:27, John Cremona wrote:
> On 7 January 2013 14:27, Jeroen Demeyer wrote:
>> On 2013-01-07 12:24, Jeroen Demeyer wrote:
>>> I am running the command
>>>
>>> sage: time B =
>>> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
>>
On 7 January 2013 14:27, Jeroen Demeyer wrote:
> On 2013-01-07 12:24, Jeroen Demeyer wrote:
>> I am running the command
>>
>> sage: time B =
>> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
>>
>> sage-5.4: 17.94 s
>> sage-5.5: 56.28 s
>
> F
On 2013-01-07 12:24, Jeroen Demeyer wrote:
> I am running the command
>
> sage: time B =
> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
>
> sage-5.4: 17.94 s
> sage-5.5: 56.28 s
False alarm, the cause seems to be differing GCC versions o
On 2013-01-07 15:14, David Loeffler wrote:
> That's very strange! The time-critical part of that computation is
> almost entirely in doing linear algebra with the coefficients of power
> series -- it bypasses most of the modular symbols code, which would be
> very inefficient in this example since
That's very strange! The time-critical part of that computation is almost
entirely in doing linear algebra with the coefficients of power series --
it bypasses most of the modular symbols code, which would be very
inefficient in this example since the level is small and the weight large
-- and oddl
On 2013-01-07 13:34, Jeroen Demeyer wrote:
>> sage-5.1: 8.76 s
>> sage-5.2: 22.56 s
>> sage-5.3: 22.59 s
>> sage-5.4: 22.50 s
>> sage-5.5: 33.32 s
Reverting #13014 (and only that) brings down the time to around 10s,
only slightly more than sage-5.1
--
You received this message because you are su
Actually, the slowdown is in 5.4 -> 5.4.1, which narrows it down quite a
lot:
http://boxen.math.washington.edu/home/release/sage-5.4.1/tickets.html
On 2013-01-07 12:24, Jeroen Demeyer wrote:
> I am running the command
>
> sage: time B =
> ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).c
On 2013-01-07 12:10, Jeroen Demeyer wrote:
> I am running the command (based on a doctest in graphics.py)
>
> sage: time p = polar_plot(lambda t:
> (100/(100+(t-pi/2)^8))*(2-sin(7*t)-cos(30*t)/2), -pi/4, 3*pi/2,
> color="red",plot_points=1000)
>
>
> There is a serious slow-down going on:
>
> sa
On 01/07/2013 07:32 PM, Volker Braun wrote:
sage: %prun p = polar_plot(lambda t:
(100/(100+(t-pi/2)^8))*(2-sin(7*t)-cos(30*t)/2), -pi/4, 3*pi/2,
color="red",plot_points=1000)
2544974 function calls (2497467 primitive calls) in 17.118 seconds
Ordered by: internal time
ncalls tottime percall cum
[vbraun@volker-desktop hg]$ sage
--
| Sage Version 5.5.rc1, Release Date: 2012-12-18 |
| Type "notebook()" for the browser-based notebook interface.|
| Type "help()" for help.
I am running the command
sage: time B =
ModularFormsRing(Gamma0(3)).modular_forms_of_weight(80).cuspidal_submodule().q_expansion_basis(prec=30)
sage-5.4: 17.94 s
sage-5.5: 56.28 s
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this g
I am running the command (based on a doctest in graphics.py)
sage: time p = polar_plot(lambda t:
(100/(100+(t-pi/2)^8))*(2-sin(7*t)-cos(30*t)/2), -pi/4, 3*pi/2,
color="red",plot_points=1000)
There is a serious slow-down going on:
sage-5.1: 8.76 s
sage-5.2: 22.56 s
sage-5.3: 22.59 s
sage-5.4: 22
33 matches
Mail list logo
