Dear group,
First-time poster here :-) Is there a systematic way to deal with too long
lines
that doesn't involve manual corrections? Any help would be appreciated ;-)
There was a topic about it in 2008, but now it seems obsolete
On Thursday 21 January 2010, David Joyner wrote:
I have run some of these tests on an imac running 10.6.2
in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
got what seems to be much shorter times
(see below). I'm not sure but it seems that at least for the
coding theory modules, there does not
On Thu, Jan 21, 2010 at 7:20 AM, Martin Albrecht
m...@informatik.uni-bremen.de wrote:
On Thursday 21 January 2010, David Joyner wrote:
I have run some of these tests on an imac running 10.6.2
in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
got what seems to be much shorter times
(see below).
On Thu, Jan 21, 2010 at 4:20 AM, Martin Albrecht
m...@informatik.uni-bremen.de wrote:
On Thursday 21 January 2010, David Joyner wrote:
I have run some of these tests on an imac running 10.6.2
in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
got what seems to be much shorter times
(see below).
On Tue, Jan 19, 2010 at 01:54:57PM -0800, Robert Miller wrote:
It's time to point our fingers at long doctests again. (I won't name
names, but there are a few people who are mostly responsible for
several of these files) Here are the eight files whose doctests
(without -long) take the longest:
William wrote:
It's possible he didn't set the DOT_SAGE environment variable to
something in /scratch, which will impact timings hugely (at least
until somebody rewrites Sage temp file code in misc/misc.py to use the
standard tempfile module).
DOT_SAGE was set to /scratch/rlm/.sage when I ran
On Thu, Jan 21, 2010 at 9:10 AM, Robert Miller r...@rlmiller.org wrote:
William wrote:
It's possible he didn't set the DOT_SAGE environment variable to
something in /scratch, which will impact timings hugely (at least
until somebody rewrites Sage temp file code in misc/misc.py to use the
On Thu, Jan 21, 2010 at 9:20 AM, William Stein wst...@gmail.com wrote:
If the problem really is the filesystem, then maybe /scratch is way
too slow. Can you try setting DOT_SAGE to something in /tmp or
/space, since /tmp could be far better than /scratch for large numbers
of accesses.
I just
Hi Robert!
On Wed, Jan 20, 2010 at 02:21:55PM +1100, Alex Ghitza wrote:
On Tue, 19 Jan 2010 13:54:57 -0800, Robert Miller r...@rlmiller.org wrote:
And here are the eight longest -long doctests:
devel/sage-main/sage/rings/arith.py
506.284008026
Where was this run? I find
It's time to point our fingers at long doctests again. (I won't name
names, but there are a few people who are mostly responsible for
several of these files) Here are the eight files whose doctests
(without -long) take the longest:
devel/sage-main/sage/rings/polynomial/multi_polynomial_ideal.py
I am one of them, sorry!
I'll try to look at this went I get some time. I'm teaching a new
course this semester which is taking a lot of prep...
http://www.usna.edu/Users/math/wdj/teach/sm450.html
On Tue, Jan 19, 2010 at 4:54 PM, Robert Miller r...@rlmiller.org wrote:
It's time to point our
On Tue, 19 Jan 2010 13:54:57 -0800, Robert Miller r...@rlmiller.org wrote:
And here are the eight longest -long doctests:
devel/sage-main/sage/rings/arith.py
506.284008026
Where was this run? I find it very strange, because #7678 recently
arranged things so that arith.py runs quite a bit
12 matches
Mail list logo
