I would not be surprised if some of the offending long tests are by me (
just because the author wants to show off the capabilities of their code)
so can you post a list of the longest ones?
The other factor is that some modules are themselves very long (thousands
of lines) withough --
I have the following :
sage: R.x = QQ[]
sage: f = prod([R.random_element() for i in
range(12)])+1/993*R.random_element(degree=24)+73/1298749837*prod([R.random_element(degree=1)
for i in range(24)])
sage: f.factor()
(189/2) * (x^24 +
7504997480865664356484601/1685489222385795317475600*x^23
Hello everybody !
In order to simplify some code in combinat/designs/ (which contains a lot
of functions) I created a meta-function which can generate some of them.
def make_a_function(x):
def new_function():
return x
my_function = make_a_function(3)
The functions returned (like
That's annoying. The entire point of the tests section (which I
introduced in the first place) was to not appear in the ref manual,
interactive docs, etc. I guess I never got around to implementing that or
somebody changed it.
Well, it does not hurt much after all.. Users see the
sage: stats = json.load(open('/home/vbraun/.sage/timings2.json'))
sage: sorted([(v['walltime'], k) for k,v in stats.items() if 'failed' not
in v])[-20:]
[(103.71118903160095,
u'sage.combinat.rigged_configurations.tensor_product_kr_tableaux'),
(105.40626382827759,
Doctesting works from the source code, not by inspecting the evaluated
module. The easiest way to deal with your function factory would be to put
the tests in make_a_function.
On Tuesday, July 29, 2014 6:18:42 AM UTC-4, Nathann Cohen wrote:
Hello everybody !
In order to simplify some code
Yoo !
Doctesting works from the source code, not by inspecting the evaluated
module. The easiest way to deal with your function factory would be to put
the tests in make_a_function.
Hmm I see :-/
Change of plans, then.. Too bad I wrote everything+the doc before noticing
that
OK, so I may have some responsibility for 2 of those:
(108.91321992874146, u'sage.schemes.elliptic_
curves.isogeny_small_degree'),
(203.31193494796753, u'sage.schemes.elliptic_
curves.ell_rational_field'),
and it should be easy to reduce the load for the first one.
I doubt that nagging will
On Tuesday, July 29, 2014 2:32:43 PM UTC+2, Volker Braun wrote:
(105.58554887771606, u'sage.functions.bessel'),
It's just four complex_plots that need all long time (70% of total) here.
Regards,
--
You received this message because you are subscribed to the Google Groups
sage-devel
Is this with the libgap speedup? I know a bunch of those end up importing
libgap (usually through a Weyl group).
The tests in rigged_configurations are there for coverage (and have been
useful for catching bugs). I can look into some of the other combinat ones.
Best,
Travis
On Tuesday, July
This is with the libgap saved workspace (and initializing libgap takes only
one second on my laptop anyways)
On Tuesday, July 29, 2014 1:25:41 PM UTC-4, Travis Scrimshaw wrote:
Is this with the libgap speedup? I know a bunch of those end up importing
libgap (usually through a Weyl group).
On Tuesday, July 29, 2014 4:20:09 AM UTC-4, John Cremona wrote:
The other factor is that some modules are themselves very long (thousands
of lines) withough -- necessarily -- having long individual tests. Though
probably they do.
Only the time needed for a single test is used to decide to
Hmm.. sage.plot.{graphics,plot} can not be avoided. We need to show a lot
of examples to the users, since the number of possible customizations is
huge.
On Tuesday, July 29, 2014 8:32:43 PM UTC+8, Volker Braun wrote:
sage: stats = json.load(open('/home/vbraun/.sage/timings2.json'))
sage:
On Tuesday, July 29, 2014 8:59:56 PM UTC-4, P Purkayastha wrote:
Hmm.. sage.plot.{graphics,plot} can not be avoided. We need to show a lot
of examples to the users, since the number of possible customizations is
huge.
And they don't trigger the warnings since each individual tests is
14 matches
Mail list logo
