1. Test that code produces the expected output
2. Document what sage can do
The 1000 point resolution is not so useful for 1, but is useful for 2 --
it illustrates that sage can produce very high quality graphics
IMHO the doctest should test that the plot_points optional keyword
What's wrong with
Set plot_points to a higher value to get more detail.
On 1 Aug 2014 20:09, kcrisman kcris...@gmail.com wrote:
1. Test that code produces the expected output
2. Document what sage can do
The 1000 point resolution is not so useful for 1, but is useful for 2
-- it illustrates
On Wednesday, July 30, 2014 5:20:21 PM UTC-4, Volker Braun wrote:
On Wednesday, July 30, 2014 11:04:02 AM UTC-4, Niles Johnson wrote:
1. Test that code produces the expected output
2. Document what sage can do
The 1000 point resolution is not so useful for 1, but is useful for 2 --
it
On Tuesday, July 29, 2014 5:27:50 PM UTC+2, Ralf Stephan wrote:
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.
I thought setting plot_points=10 would
On Tuesday, July 29, 2014 2:24:10 PM UTC-4, Volker Braun wrote:
What do we test with 1000 point resolution that can't be tested with 10?
Maybe more examples should be flagged with # not tested or something like
# optional -- demo or # optional -- tutorial?
This and another recent thread
On Wednesday, July 30, 2014 11:04:02 AM UTC-4, Niles Johnson wrote:
1. Test that code produces the expected output
2. Document what sage can do
The 1000 point resolution is not so useful for 1, but is useful for 2 --
it illustrates that sage can produce very high quality graphics
IMHO the
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 --
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,
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
A small handful of modules takes the majority of the doctest walltime, see
e.g. this lopsided distribution:
http://boxen.math.washington.edu/home/vbraun/t/doctest.png
I'm proposing to
* turn the existing sage -t --warn-long parameter into a warning (instead
of an error)
* enable it by
16 matches
Mail list logo
