> One could modify local/bin/sage-doctest to allow the option of changing each
> doctest by wrapping it in a "timeit()" call. This would then generate a
> timing datum for each doctest line.
I did this, a long long time ago. Not clear whether it was ever
merged. See:
http://trac.sagemath.org/s
On Mon, Oct 25, 2010 at 8:39 PM, David Roe wrote:
> I think if you set both number and repeat to 1 in sage.misc.sage_timeit, it
> will only run once (though I could be wrong).
Yes, though it'd probably be both cheap and valuable to run fast
commands more than once (but less than the default timit
I think if you set both number and repeat to 1 in sage.misc.sage_timeit, it
will only run once (though I could be wrong).
We should think about a way to automate uploading of timing data if someone
doesn't have MongoDB installed. For example, we could have the test script
which ran doctests have
I have been testing Sage on Debian (64 bits) on an ad hoc basis, and I
have enough hardware power (a virtual host on a VMWare server)
to run a testbot, if a setup is available and not too hard to install.
(unfortunately it's behind a campus firewall, so it can't be ssh'd
into from outside without a
On Mon, Oct 25, 2010 at 11:54 AM, William Stein wrote:
>> Also, I was talking to Craig Citro about this and he had the
>> interesting idea of creating some kind of a "test object" which would
>> be saved and then could be run into future versions of Sage and re-run
>> in. The idea of saving the te
Note that fs in the example is a list of length 1.
David
On Mon, Oct 25, 2010 at 23:14, François Bissey wrote:
> Hi,
>
> I am looking at the code and tests for the class Riemann_Map in
> calculus/riemann.pyx and I have a hard time understanding how it can be
> working at all.
>
> The init method
Hi,
I am looking at the code and tests for the class Riemann_Map in
calculus/riemann.pyx and I have a hard time understanding how it can be
working at all.
The init method starts with:
def __init__(self, fs, fprimes, a, int N=500, int ncorners=4, opp=False):
"""
Initializes
On 10/25/2010 05:04 PM, Dr. David Kirkby wrote:
> On 10/25/10 06:21 PM, kcrisman wrote:
2. what is needed to run a buildbot?
>>>
>>> Mitesh will know more, since he has set them up.
>>>
>>> I know for me personally I just gave him an account (username
>>> buildbot), and an IP address into whic
On 10/25/2010 11:55 AM, David Kirkby wrote:
> On 25 October 2010 17:26, Gonzalo Tornaria wrote:
>> On Mon, Oct 25, 2010 at 12:09 PM, David Kirkby
>> wrote:
>>> Since Minh has been using an external server (I think run by GNU) for
>>> Debian, we can probably add Debian at some point if we can get
> Hi,
>
> Just for fun, I created this page:
>
>http://code.google.com/p/sagemath/
>
> It has the Sage source code repo, so you can browse the history of Sage:
>
>http://code.google.com/p/sagemath/source/list
>
I actually installed hgview to inspect changes on my machine and it looks
On Mon, Oct 25, 2010 at 4:23 PM, Mitesh Patel wrote:
> On 10/25/2010 01:54 PM, William Stein wrote:
>>> Also, I was talking to Craig Citro about this and he had the
>>> interesting idea of creating some kind of a "test object" which would
>>> be saved and then could be run into future versions of
On Oct 25, 4:23 pm, Mitesh Patel wrote:
>>[...]
> On 10/25/2010 01:54 PM, William Stein wrote:
> > * A document with a unique id, starting at 0, for each actual test
> > {'id':0, 'code':'factor(2^127+1)'}
>
> > * A document for each result of running the tests on an actual platform:
>
On 10/25/2010 01:54 PM, William Stein wrote:
>> Also, I was talking to Craig Citro about this and he had the
>> interesting idea of creating some kind of a "test object" which would
>> be saved and then could be run into future versions of Sage and re-run
>> in. The idea of saving the tests that ar
Hi,
Just for fun, I created this page:
http://code.google.com/p/sagemath/
It has the Sage source code repo, so you can browse the history of Sage:
http://code.google.com/p/sagemath/source/list
and files:
http://code.google.com/p/sagemath/source/browse/
It's interesting because it's
On Mon, Oct 25, 2010 at 1:33 PM, javier wrote:
> IIRC in the latest Cython release there was a bugfix that reduced the
> access time for all cython non-cdef classes [1]. Given the amount of
> time that is spent on function calls I wouldn't be surprised if that
> change propagated to a general spee
On Mon, Oct 25, 2010 at 3:04 PM, Dr. David Kirkby
wrote:
> On 10/25/10 06:21 PM, kcrisman wrote:
2. what is needed to run a buildbot?
>>>
>>> Mitesh will know more, since he has set them up.
>>>
>>> I know for me personally I just gave him an account (username
>>> buildbot), and an IP ad
On Oct 25, 2:47 pm, "Dr. David Kirkby"
wrote:
> On 10/25/10 04:50 PM, Donald Alan Morrison wrote:
> > On Oct 25, 8:19 am, David Kirkby wrote:
> >> Getting a checksum of each doctest would be easy. I suggest we use:
> >> $ cksum sometest.py | awk '{print $1}'
> >> because that will be totally p
On 10/25/10 06:21 PM, kcrisman wrote:
2. what is needed to run a buildbot?
Mitesh will know more, since he has set them up.
I know for me personally I just gave him an account (username
buildbot), and an IP address into which the buildbot can ssh.
Was there an announcement of this recently?
On 10/25/10 04:50 PM, Donald Alan Morrison wrote:
On Oct 25, 8:19 am, David Kirkby wrote:
Getting a checksum of each doctest would be easy. I suggest we use:
$ cksum sometest.py | awk '{print $1}'
because that will be totally portable across all platforms. 'cksum' is
32-bit checksum that's
I posted a patch there that should fix it; I have to work on other stuff,
but if someone else wants to take over and write some doctests, make sure it
works in lots of cases...
David
On Mon, Oct 25, 2010 at 17:14, Burcin Erocal wrote:
> On Mon, 25 Oct 2010 17:00:39 -0400
> David Roe wrote:
>
>
On Mon, 25 Oct 2010 17:00:39 -0400
David Roe wrote:
> This is a good workaround, but the original problem can be traced to
> the function sage.symbolic.expression.Expression.__int__
>
> def __int__(self):
> #FIXME: can we do better?
> return int(self.n(prec=100))
>
> Presumably you coul
This is a good workaround, but the original problem can be traced to the
function sage.symbolic.expression.Expression.__int__
def __int__(self):
#FIXME: can we do better?
return int(self.n(prec=100))
Presumably you could adaptively estimate to higher precision until your
error interval in
On 2010-10-25 20:06, Robert Bradshaw wrote:
> To be very useful, I think we need to be more granular than having
> per-file tests. Just think about the number of files that get touched,
> even a little bit, each release... Full doctest blocks should be
> independent (though of course when looking a
IIRC in the latest Cython release there was a bugfix that reduced the
access time for all cython non-cdef classes [1]. Given the amount of
time that is spent on function calls I wouldn't be surprised if that
change propagated to a general speedup in the doctests.
Cheers
J
[1]
http://groups.googl
> Also, I was talking to Craig Citro about this and he had the
> interesting idea of creating some kind of a "test object" which would
> be saved and then could be run into future versions of Sage and re-run
> in. The idea of saving the tests that are run, and then running the
> exact same tests (r
On Mon, Oct 25, 2010 at 8:19 AM, David Kirkby wrote:
> On 21 October 2010 01:33, David Roe wrote:
>> There are a number of tickets in trac about performance regressions in
>> Sage. I'm sure there are far more performance regressions which we don't
>> know about because nobody noticed.
>
>
> I ag
On Mon, Oct 25, 2010 at 7:09 AM, David Kirkby wrote:
> As has been remarked before, Sage has number lists of "supported
> platforms", no two of which agree with each other.
>
> I proposed some time ago we break the list into 3
>
> 1) Fully supported - every Sage release is tested on it.
> 2) Expec
> > 2. what is needed to run a buildbot?
>
> Mitesh will know more, since he has set them up.
>
> I know for me personally I just gave him an account (username
> buildbot), and an IP address into which the buildbot can ssh.
>
Was there an announcement of this recently? I might be able to make a
m
Hi Pablo
On Tue, Oct 26, 2010 at 1:56 AM, Pablo De Napoli wrote:
> Hi,
>
> I've a problem with generating the documentation (Spanish translation
> of the tutorial)
See if the following page helps:
http://wiki.sagemath.org/devel/nonASCII
--
Regards
Minh Van Nguyen
--
To post to this group, s
On 25 October 2010 17:26, Gonzalo Tornaria wrote:
> On Mon, Oct 25, 2010 at 12:09 PM, David Kirkby
> wrote:
>> Since Minh has been using an external server (I think run by GNU) for
>> Debian, we can probably add Debian at some point if we can get
>> permission to run a buildbot slave there.
>
>
On Mon, Oct 25, 2010 at 12:09 PM, David Kirkby wrote:
> Since Minh has been using an external server (I think run by GNU) for
> Debian, we can probably add Debian at some point if we can get
> permission to run a buildbot slave there.
1. Is there a reason for not running debian on a vm on boxen?
When you do sqrt(2^m) when m is odd, say m=2*k+1, the returned value
is symbolically 2*k * sqrt(2):
sage: sqrt(2^101)
1125899906842624*sqrt(2)
Now using Integer() to "round" that will evaluate sqrt(2)
approximately to standard precision, which is not enough. Instead,
use the isqrt() method for I
Your suggestions all look very sensible to me -- go for it (provided
several other people agree, of course).
John
On Mon, Oct 25, 2010 at 3:09 PM, David Kirkby wrote:
> As has been remarked before, Sage has number lists of "supported
> platforms", no two of which agree with each other.
>
> I pro
Georg wrote :
while calculating the integer part of square roots I realized that
sqrt() returns wrong results for large inputs (although the sqrt()
command itself accepts "bignum" values).
example: int(sqrt(2^94533))
int isn't a "mathematical" Sage type, but Integer is a Sage type.
And Integ
On Oct 25, 8:19 am, David Kirkby wrote:
> Getting a checksum of each doctest would be easy. I suggest we use:
>
> $ cksum sometest.py | awk '{print $1}'
>
> because that will be totally portable across all platforms. 'cksum' is
> 32-bit checksum that's part of the POSIX standard and the algorit
On 21 October 2010 01:33, David Roe wrote:
> There are a number of tickets in trac about performance regressions in
> Sage. I'm sure there are far more performance regressions which we don't
> know about because nobody noticed.
I agree, and I've seen some comments from William that writing code
Hi
while calculating the integer part of square roots I realized that
sqrt() returns wrong results for large inputs (although the sqrt()
command itself accepts "bignum" values).
example: int(sqrt(2^94533))
I guess that this is due to the fact that SAGE simplifies the
expression above as sqrt(2) *
Hi,
I've a problem with generating the documentation (Spanish translation
of the tutorial)
I've converted the attachment of ticket #7222 to utf using iconv
iconv -f latin1 -t utf8 < tour_help.rst > tour_help-utf8.rst
and after that
mv tour_help.rst tour_help-utf8.rst
(This seems to be needed,
Yes, it appears that only the first section of the tutorial has been translated
yet (put please check on trac to avoid duplicating effords).
I can coordinate the translation of the Spanish translation.
It would be great if you can help translating a section (like the
section in linear algebra).
P
As has been remarked before, Sage has number lists of "supported
platforms", no two of which agree with each other.
I proposed some time ago we break the list into 3
1) Fully supported - every Sage release is tested on it.
2) Expected to work
3) Probably will not work, but porting work in ongoing
Hi
After some ubuntu 10.04.1 upgrades:
Aptitude 0.4.11.11: log report
Sun, Oct 24 2010 16:00:35 +0200
IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.
Will install 14 packages, and remove 0 packages.
4096B of disk s
On 24 oct, 17:48, Pablo De Napoli wrote:
> Hi
>
> I've seen the video "contributing to Sage" where W. Stein mentioned
> the translation of the tutorial to Spanish as
> a possible contribution to sage.
> Indeed, some parts of the tutorial have been already translated into
> Spanish by Luis V. (12 m
On Sat, 23 Oct 2010 18:58:05 +0200
Jeroen Demeyer wrote:
> I have a page on the wiki with a proposal for standard Trac keywords.
> Feel free to edit: http://wiki.sagemath.org/TracKeywords
>
> I'm not sure that all these keywords are useful, but some of them
> certainly are.
I really like your s
On 10/25/10 08:35 AM, koffie wrote:
Are you testing all doctest (ie also the long ones) since it could be
that some long doctests have been tagged as such in an update.
Then there is ofcourse still the possibility that there was a merge
off a ticket which improves general sage performance.
The
Are you testing all doctest (ie also the long ones) since it could be
that some long doctests have been tagged as such in an update.
Then there is ofcourse still the possibility that there was a merge
off a ticket which improves general sage performance.
The recently proposed regresion testing pa
45 matches
Mail list logo
