Re: [sage-devel] Re: Decimals of Pi
On Thu, Oct 22, 2009 at 9:54 AM, Robert Bradshaw wrote: > This is a known limitation (due to a workaround for a fixed MPFR bug.) > See http://trac.sagemath.org/sage_trac/ticket/2567 . Should be an easy > fix. I've posted a patch for this. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [sage-release] Re: Sage 4.3.4.alpha0 released
Hi Kiran, On Thu, Mar 4, 2010 at 3:12 PM, Minh Nguyen wrote: > See ticket #8432 for an implementation of this > approach. >From your install log, I see that your build also has gotten past installing iconv. This makes me doubt that the solution at #8432 would solve the build problem you reported. In any event, I would like to know if the solution at #8432 works for your particular system. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [sage-release] Re: Sage 4.3.4.alpha0 released
Hi Kiran, On Thu, Mar 4, 2010 at 2:36 PM, Kiran Kedlaya wrote: > As expected based on my experience with 4.3.3, I got a build error > building 4.3.4.alpha0, though this time it was a linking error with gd > rather than cddlib. Again, this is Fedora 10 on a 64-bit system, but > on a 32-bit network, so there exist 32-bit libraries findable via NFS > (under /usr/local). But this time I don't see any obvious evidence > that this is the source of the trouble. > - > /bin/sh ./libtool --tag=CC --mode=link gcc -fPIC -g -I"/scratch/ > sage-4.3.4.alph > a0/local/include" -I/scratch/sage-4.3.4.alpha0/local/include/ > freetype2/ -L/scra > tch/sage-4.3.4.alpha0/local/lib -Wl,--rpath -Wl,/scratch/ > sage-4.3.4.alpha0/local > /lib -L/scratch/sage-4.3.4.alpha0/local/lib -o annotate > annotate.o ./libgd.la > -lfontconfig -lfreetype -lpng12 -lz -lm > gcc -fPIC -g -I/scratch/sage-4.3.4.alpha0/local/include -I/scratch/ > sage-4.3.4.al > pha0/local/include/freetype2/ -Wl,--rpath -Wl,/scratch/ > sage-4.3.4.alpha0/local/l > ib -o .libs/annotate annotate.o -L/scratch/sage-4.3.4.alpha0/local/ > lib ./.libs/ > libgd.so -lfontconfig /scratch/sage-4.3.4.alpha0/local/lib/ > libfreetype.so /scrat > ch/sage-4.3.4.alpha0/local/lib/libpng12.so -lz -lm -Wl,--rpath -Wl,/ > scratch/sage > -4.3.4.alpha0/local/lib > ./.libs/libgd.so: undefined reference to `libiconv' > ./.libs/libgd.so: undefined reference to `libiconv_close' > ./.libs/libgd.so: undefined reference to `libiconv_open' > collect2: ld returned 1 exit status The failure here is likely because gd requires that iconv be built first. With Sage 4.3.4.alpha0, this is not the case in the dependency rule for building gd. A fix is to make iconv part of the dependency rule for building gd. See ticket #8432 for an implementation of this approach. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Complex Coercion Error or User Error?
The coercion question in the first post in this thread is still open. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Complex Coercion Error or User Error?
Problem solved. The list of zeros was mis-formatted (by myself).
Thanks Leif!
Here is the Pythonized version, for reference.
I made the table of zeros incorrectly. I used the code:
print "float zz[]={"
for i in range(1,6000):#len(zz)):
s=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
print str(s)
print "}"
Now I corrected the code by changing it to the following:
print "float zz[]={"
i=1
while i<6000:#len(zz)):
s=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
s+=str(zz[i])+","
i+=1
print s
print "}"
def fastlipythonized( x, t):
logx = log(x);
u_real = 0.5 * logx;
u_imag = t * logx;
u_norm = u_real * u_real + u_imag * u_imag;
so_real_num = 2 * sqrt(x) * cos(t * logx);
so_imag_num = 2 * sqrt(x) * sin(t * logx);
so_real = (so_real_num * u_real + so_imag_num * u_imag) / u_norm;
so_imag = (so_imag_num * u_real - so_real_num * u_imag) / u_norm;
tol=10^-9/(sqrt(so_real * so_real + so_imag * so_imag));
tol_squared=tol*tol;
s1_real = 1;
s1_imag = 0;
s2_real = 1;
s2_imag = 0;
k = 1;
while (true):
if (k>100):
print ("error%f\n",t);
return;
#//break;
s2_real_temp = k * (s2_real * u_real + s2_imag * u_imag) /
u_norm;
s2_imag_temp = k * (s2_imag * u_real - s2_real * u_imag) /
u_norm;
s2_real = s2_real_temp;
s2_imag = s2_imag_temp;
s1_real += s2_real;
s1_imag += s2_imag;
norm=s2_real * s2_real + s2_imag * s2_imag;
if (norm < tol_squared):
break;
#lastnorm=norm;
k+=1;
return so_real * s1_real - so_imag * s1_imag;
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Failure building MPIR on sage 4.3.2
I just tried building MPIR 1.3.1 on /tmp -- a local file system -- instead of the network file system I was using before. Suddenly, it works! I assume the next Sage release will include this MPIR revision. Sage 4.3.3 (MPIR 1.2.2) fails to build yasm as before. Thanks! - Ryan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sagemath.fr ?
Hi, I do not know whether this message is for here or sage-marketing or sage-edu... they are rather technical. I just opened a SAGE wiki and a discussion list in french after the education day we had during the SAGE days 20 in Marseille (http:// groups.google.com/group/sage-support/browse_thread/thread/ 2b88ff7bec260d0) The names reserved for this action are sage-edu.fr, sage-edu.org, sagemath-edu.fr sagemath-edu.org 1) I would like to know if it's possible to update the information available on sagemath.fr (I could be in charge of this) ? 2) I won't use any of sage-edu.org or sagemath-edu.org. If nobody aims to use them, they will be lost in one year. They are available to any project... Vincent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Complex Coercion Error or User Error?
> Oddly, this worked for me. But... the (rather cryptic) answer should > give you an idea of what's going on: Oh, that's my mistake -- I didn't include the line 'from math import log' -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: fractals in sage
> > That sounds exiting, are there also plans to implement "discrete" > > fractals? (combinat.WordMorphisms and word-paths and things like > > that?) > > >http://www.sagemath.org/doc/reference/sage/combinat/words/paths.html > >http://alexis.monnerot-dumaine.neuf.fr/articles/fibonacci%20fractal.pdf I just added on the animate page of the sage wiki an animation [1] that was dying in one of my folder. A fractal sequence of tiles related to the Fibonacci sequence. Maybe sage: fractals.fibonacci_tile could exist and return a .png file? or maybe a tikzpicture? One can obtain the tikz code in two lines : sage: w = words.fibonacci_tile(2) sage: w.tikz_trajectory() '(0, 0) -- (0, -1) -- (-1, -1) -- (-1, -2) -- (0, -2) -- (0, -3) -- (1, -3) -- (1, -2) -- (2, -2) -- (2, -3) -- (3, -3) -- (3, -4) -- (2, -4) -- (2, -5) -- (1, -5) -- (1, -4) -- (0, -4) -- (0, -5) -- (-1, -5) -- (-1, -6) -- (0, -6) -- (0, -7) -- (-1, -7) -- (-1, -8) -- (-2, -8) -- (-2, -7) -- (-3, -7) -- (-3, -6) -- (-2, -6) -- (-2, -5) -- (-3, -5) -- (-3, -4) -- (-4, -4) -- (-4, -5) -- (-5, -5) -- (-5, -4) -- (-6, -4) -- (-6, -3) -- (-5, -3) -- (-5, -2) -- (-4, -2) -- (-4, -3) -- (-3, -3) -- (-3, -2) -- (-2, -2) -- (-2, -1) -- (-3, -1) -- (-3, 0) -- (-2, 0) -- (-2, 1) -- (-1, 1) -- (-1, 0) -- (0, 0)' I think the idea of having fractals.[TAB] is great. Sébastien [1] http://wiki.sagemath.org/animate#FibonacciTiles -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: fractals in sage
> > That sounds exiting, are there also plans to implement "discrete" > > fractals? (combinat.WordMorphisms and word-paths and things like > > that?) > > >http://www.sagemath.org/doc/reference/sage/combinat/words/paths.html > >http://alexis.monnerot-dumaine.neuf.fr/articles/fibonacci%20fractal.pdf I just added on the animate page of the sage wiki an animation [1] that was dying in one of my folder. A fractal sequence of tiles related to the Fibonacci sequence. Maybe sage: fractals.fibonacci_tile could exist and return a .png file? or maybe a tikzpicture? One can obtain the tikz code in two lines : sage: w = words.fibonacci_tile(2) sage: w.tikz_trajectory() '(0, 0) -- (0, -1) -- (-1, -1) -- (-1, -2) -- (0, -2) -- (0, -3) -- (1, -3) -- (1, -2) -- (2, -2) -- (2, -3) -- (3, -3) -- (3, -4) -- (2, -4) -- (2, -5) -- (1, -5) -- (1, -4) -- (0, -4) -- (0, -5) -- (-1, -5) -- (-1, -6) -- (0, -6) -- (0, -7) -- (-1, -7) -- (-1, -8) -- (-2, -8) -- (-2, -7) -- (-3, -7) -- (-3, -6) -- (-2, -6) -- (-2, -5) -- (-3, -5) -- (-3, -4) -- (-4, -4) -- (-4, -5) -- (-5, -5) -- (-5, -4) -- (-6, -4) -- (-6, -3) -- (-5, -3) -- (-5, -2) -- (-4, -2) -- (-4, -3) -- (-3, -3) -- (-3, -2) -- (-2, -2) -- (-2, -1) -- (-3, -1) -- (-3, 0) -- (-2, 0) -- (-2, 1) -- (-1, 1) -- (-1, 0) -- (0, 0)' I think the idea of having fractals.[TAB] is great. Sébastien [1] http://wiki.sagemath.org/animate#FibonacciTiles -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Infinite recursion in coersion?
Oops, I forgot to include the polynomial: sage: x = polygen(QQ) sage: f = x^3 - 3024*x + 46224 Perhaps the problem is only when the roots are all real? On Wed, Mar 3, 2010 at 12:59 PM, John Cremona wrote: > What is your complete code: I had no trouble with > > sage: x=polygen(QQ) > sage: f=x^2+1 > sage: R. = NumberField(f,'a') > sage: a.n() > 1.00*I > > but f=x^2-2 gave the problem. > > John > > On 3 March 2010 18:32, Tom Boothby wrote: >> I found a distressing bug just now: >> >> sage: R. = NumberField(f,'a') >> sage: a.n() >> Traceback (most recent call last): a.n() >> File "", line 1, in >> >> File "/tmp/tmp8r5Xa6/___code___.py", line 3, in >> exec compile(ur'a.n()' + '\n', '', 'single') >> File "", line 1, in >> >> File "element.pyx", line 455, in sage.structure.element.Element.n >> (sage/structure/element.c:4028) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/misc/functional.py", >> line 1140, in numerical_approx >> return sage.rings.real_mpfr.RealField_constructor(prec)(x) >> File "parent.pyx", line 538, in >> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) >> File "coerce_maps.pyx", line 156, in >> sage.structure.coerce_maps.NamedConvertMap._call_ >> (sage/structure/coerce_maps.c:4098) >> File "number_field_element.pyx", line 845, in >> sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ >> (sage/rings/number_field/number_field_element.cpp:8067) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", >> line 267, in __call__ >> return Parent.__call__(self, x) >> File "parent.pyx", line 538, in >> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) >> File "coerce_maps.pyx", line 82, in >> sage.structure.coerce_maps.DefaultConvertMap_unique._call_ >> (sage/structure/coerce_maps.c:3142) >> File "coerce_maps.pyx", line 77, in >> sage.structure.coerce_maps.DefaultConvertMap_unique._call_ >> (sage/structure/coerce_maps.c:3040) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", >> line 294, in _element_constructor_ >> return complex_number.ComplexNumber(self, x) >> File "complex_number.pyx", line 153, in >> sage.rings.complex_number.ComplexNumber.__init__ >> (sage/rings/complex_number.c:3116) >> File "parent.pyx", line 538, in >> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) >> File "coerce_maps.pyx", line 156, in >> sage.structure.coerce_maps.NamedConvertMap._call_ >> (sage/structure/coerce_maps.c:4098) >> File "number_field_element.pyx", line 845, in >> sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ >> (sage/rings/number_field/number_field_element.cpp:8067) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", >> line 267, in __call__ >> return Parent.__call__(self, x) >> File "parent.pyx", line 538, in >> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) >> File "coerce_maps.pyx", line 82, in >> sage.structure.coerce_maps.DefaultConvertMap_unique._call_ >> (sage/structure/coerce_maps.c:3142) >> File "coerce_maps.pyx", line 77, in >> sage.structure.coerce_maps.DefaultConvertMap_unique._call_ >> (sage/structure/coerce_maps.c:3040) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", >> line 294, in _element_constructor_ >> return complex_number.ComplexNumber(self, x) >> File "complex_number.pyx", line 153, in >> sage.rings.complex_number.ComplexNumber.__init__ >> (sage/rings/complex_number.c:3116) >> File "parent.pyx", line 538, in >> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) >> File "coerce_maps.pyx", line 156, in >> sage.structure.coerce_maps.NamedConvertMap._call_ >> (sage/structure/coerce_maps.c:4098) >> File "number_field_element.pyx", line 845, in >> sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ >> (sage/rings/number_field/number_field_element.cpp:8067) >> File >> "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", >> line 267, in __call__ >> ... >> RuntimeError: maximum recursion depth exceeded >> >> >> Is there a cycle in the coercion structure? If yes, should we check >> for the existence of such cycles? >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org >> > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google
[sage-devel] Re: Let's collect data on Sage startup time.
On Mar 3, 10:17 pm, Jonathan Bober wrote: > The first depends mostly on > hard drive speed ... To be exact, it also depends on the filesystem :) i've ext4... And one small idea, to clear the disk cache in linux do sync ; sudo sh -c "echo 3 | tee /proc/sys/vm/drop_caches" http://boxen.math.washington.edu/home/schilly/sage.startuptime.hp.mini.2140.txt h -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
If you need some more examples, with buffer/cache cleared. tomahawk-~ $ time mupkern input **MuPAD Pro 4.5.0 -- The Open Computer Algebra System /| /| ** |Copyright (c) 1997 - 2007 by SciFace Software | *--|-* All rights reserved. |/ |/ ** Licensed to: Combinat devel 2 3 5 67 mupkern input 0,77s user 0,14s system 21% cpu 4,238 total Next consecutive launches: mupkern input 0,45s user 0,05s system 97% cpu 0,512 total mupkern input 0,45s user 0,04s system 95% cpu 0,515 total mupkern input 0,44s user 0,05s system 96% cpu 0,508 total mupkern input 0,45s user 0,04s system 92% cpu 0,534 total mupkern input 0,46s user 0,04s system 95% cpu 0,526 total Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Let's collect data on Sage startup time.
Running these tests gives some information, but it is probably a little hard to interpret. On a fresh boot, sage will take roughly 18 seconds to start up on my machine. Subsequent runs, however, take roughly 1.8 seconds, typically. This is all dependent on many things that the operating system does to cache data read from disk. If you have plenty of ram, and it isn't being used for anything else, then the operating system won't actually have to read anything from disk the second or third time you start sage, which explains why there are wildly varying startup times. (Maybe everyone is aware of this already.) So, it would be nice for both numbers (18 seconds and 1.8 seconds) to be smaller, but they can't really be compared. The first depends mostly on hard drive speed while the second is bound by the speed of CPU and by memory bandwidth/latency, and perhaps by CPU cache size/speed as well. On Wed, 2010-03-03 at 17:16 +, Dr. David Kirkby wrote: > Ticket http://trac.sagemath.org/sage_trac/ticket/8254 > > "sage takes way too long to startup" > > seems to irritate a lot of people. It does not me too much, but I feel one > way > to at least start to tackle this probably is to get some quantifiable data > and > see where the time is being spent. My hunch is that this is due to disk I/O. > > If we all append our results running > > time echo "2+2;" | /absolute/path/to/sage > > where /absolute/path/to/sage should be a *local* file system. If it is shared > via NFS, then it just adds another unknown. > > Then we might get somewhere and see if there is a common problem, though I > think > 'dtrace' on Solaris or OS X is likely to be the most useful tool for > debugging > this. > > Considering the age of my SPARC (it is circa 2000), I'm getting a startup > time > less than some are reporting with what I suspect is much more modern > hardware. > One thing my SPARC does however have is disks and a disk interface which is > probably superior to 90% of modern PCs. > > I'd suggest running it 5x, reporting the median value for "median" values of > "real" time, and as well as maximum and minimum. > > So here is one set of data/ > > 1) Sun Blade 2000, circa 2000 > 2 x 900 MHz UltraSPARC III+ CPUs > Load average 1 (Sorry, I'm doing something and can't stop that) > 1x 147 GB Seagate SEAGATE-ST3146807FC. 15,000 rpm SCSI with a 2 Gbit/s fibre > channel interface. > Sage version 4.3.3 with patches for Solaris as documented at > http://trac.sagemath.org/sage_trac/ticket/8409 > Median of the 5 runs is: > sage: sage: > > Exiting SAGE (CPU time 0m0.17s, Wall time 0m0.19s). > > real0m8.263s > user0m6.502s > sys 0m1.392s > > Maximum time of the 5 runs is > real0m8.356s > > Minimum tie of the 5 runs is > real0m8.066s > > I can't be bothered to determine whether that is statistically significant or > not, but it seems to me that data is pretty reproducible. > > What is clear here is that this seems to be CPU bound on my old machine, > which > is hardly surprising given the old CPUs, but 15,000 rpm disks. That might > give > us a clue. > > Anyone else care to put their data here too? > > Dave > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Infinite recursion in coersion?
What is your complete code: I had no trouble with sage: x=polygen(QQ) sage: f=x^2+1 sage: R. = NumberField(f,'a') sage: a.n() 1.00*I but f=x^2-2 gave the problem. John On 3 March 2010 18:32, Tom Boothby wrote: > I found a distressing bug just now: > > sage: R. = NumberField(f,'a') > sage: a.n() > Traceback (most recent call last): a.n() > File "", line 1, in > > File "/tmp/tmp8r5Xa6/___code___.py", line 3, in > exec compile(ur'a.n()' + '\n', '', 'single') > File "", line 1, in > > File "element.pyx", line 455, in sage.structure.element.Element.n > (sage/structure/element.c:4028) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/misc/functional.py", > line 1140, in numerical_approx > return sage.rings.real_mpfr.RealField_constructor(prec)(x) > File "parent.pyx", line 538, in > sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) > File "coerce_maps.pyx", line 156, in > sage.structure.coerce_maps.NamedConvertMap._call_ > (sage/structure/coerce_maps.c:4098) > File "number_field_element.pyx", line 845, in > sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ > (sage/rings/number_field/number_field_element.cpp:8067) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", > line 267, in __call__ > return Parent.__call__(self, x) > File "parent.pyx", line 538, in > sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) > File "coerce_maps.pyx", line 82, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3142) > File "coerce_maps.pyx", line 77, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3040) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", > line 294, in _element_constructor_ > return complex_number.ComplexNumber(self, x) > File "complex_number.pyx", line 153, in > sage.rings.complex_number.ComplexNumber.__init__ > (sage/rings/complex_number.c:3116) > File "parent.pyx", line 538, in > sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) > File "coerce_maps.pyx", line 156, in > sage.structure.coerce_maps.NamedConvertMap._call_ > (sage/structure/coerce_maps.c:4098) > File "number_field_element.pyx", line 845, in > sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ > (sage/rings/number_field/number_field_element.cpp:8067) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", > line 267, in __call__ > return Parent.__call__(self, x) > File "parent.pyx", line 538, in > sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) > File "coerce_maps.pyx", line 82, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3142) > File "coerce_maps.pyx", line 77, in > sage.structure.coerce_maps.DefaultConvertMap_unique._call_ > (sage/structure/coerce_maps.c:3040) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", > line 294, in _element_constructor_ > return complex_number.ComplexNumber(self, x) > File "complex_number.pyx", line 153, in > sage.rings.complex_number.ComplexNumber.__init__ > (sage/rings/complex_number.c:3116) > File "parent.pyx", line 538, in > sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) > File "coerce_maps.pyx", line 156, in > sage.structure.coerce_maps.NamedConvertMap._call_ > (sage/structure/coerce_maps.c:4098) > File "number_field_element.pyx", line 845, in > sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ > (sage/rings/number_field/number_field_element.cpp:8067) > File > "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", > line 267, in __call__ > ... > RuntimeError: maximum recursion depth exceeded > > > Is there a cycle in the coercion structure? If yes, should we check > for the existence of such cycles? > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Complex Coercion Error or User Error?
On 03/03/2010 10:50 AM, kstueve wrote: > #include > #include What happens if you insert #include here? Compiling with extra warning flags *may* help: $ gcc -o fastli fastli.c -lm -O2 -W -Wall fastli.c: In function ‘main’: fastli.c:29: warning: implicit declaration of function ‘atof’ fastli.c:30: warning: implicit declaration of function ‘atol’ fastli.c:27: warning: unused parameter ‘argc’ fastli.c: In function ‘li’: fastli.c:77: warning: ‘return’ with no value, in function returning non-void fastli.c:72: warning: unused variable ‘lastnorm’ $ man atof -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Let's collect data on Sage startup time.
On Wed, Mar 3, 2010 at 11:29 AM, Harald Schilly wrote: > On Mar 3, 6:16 pm, "Dr. David Kirkby" wrote: >> time echo "2+2;" | /absolute/path/to/sage >> > > For me: > real 0m24.730s > user 0m6.712s > sys 0m1.884s > > real 0m5.127s > user 0m4.348s > sys 0m0.784s > > real 0m5.245s > user 0m4.560s > sys 0m0.840s > > > It's a N270 atom netbook, my hdd is > $ sudo hdparm -i /dev/sda > Model=FUJITSU, FwRev=8909, SerialNo=K616T913TG79 > [ ... a lot of blahhh ... it's pio4 and caching enabled ... ] > > In comparison, chrome starts ~1 second on first startup, hence there > is a lot to improve. > > I think we should look at the list of all files that are read on > startup and try to minimize them. That's the easiest way and probably > also the most effective one. 4 seconds of processing time and 18 secs It's interesting that in all these threads nobody has mentioned "sage -startuptime". That's the command that reports on what modules are loaded when Sage starts up, and how long each takes to load... To optimize Sage startup time, one starts with that command. Second, there is a powerful new lazy import feature that Rober Bradshaw and Mitesh Patel recently added to Sage: http://trac.sagemath.org/sage_trac/ticket/7502 -- William > of harddisk seem to paint a clear picture who is to blaim. ;) > Also, patterns like lazy creation of objects might help, especially > when it reduces the number of file accesses. > > h > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Let's collect data on Sage startup time.
On Mar 3, 6:16 pm, "Dr. David Kirkby" wrote: > time echo "2+2;" | /absolute/path/to/sage > For me: real0m24.730s user0m6.712s sys 0m1.884s real0m5.127s user0m4.348s sys 0m0.784s real0m5.245s user0m4.560s sys 0m0.840s It's a N270 atom netbook, my hdd is $ sudo hdparm -i /dev/sda Model=FUJITSU, FwRev=8909, SerialNo=K616T913TG79 [ ... a lot of blahhh ... it's pio4 and caching enabled ... ] In comparison, chrome starts ~1 second on first startup, hence there is a lot to improve. I think we should look at the list of all files that are read on startup and try to minimize them. That's the easiest way and probably also the most effective one. 4 seconds of processing time and 18 secs of harddisk seem to paint a clear picture who is to blaim. ;) Also, patterns like lazy creation of objects might help, especially when it reduces the number of file accesses. h -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Complex Coercion Error or User Error?
> li(10**10,39.0) > -101.969133925197 > li(10**10,39) > li: unable to attain the desired precision Oddly, this worked for me. But... the (rather cryptic) answer should give you an idea of what's going on: 624/1217*sin(39*log(100))/log(100) + 8/1217*cos(39*log(100))/log(100) + 4992000/1481089*sin(39*log(100))/log(100)^2 - 194656000/1481089*cos(39*log(100))/log(100)^2 - 12142540800/1802485313*sin(39*log(100))/log(100)^3 - 467225600/1802485313*cos(39*log(100))/log(100)^3 - 58303365120/2193624625921*sin(39*log(100))/log(100)^4 + 1135981148160/2193624625921*cos(39*log(100))/log(100)^4 + 141677161906176/2669641169745857*sin(39*log(100))/log(100)^5 + 9093829804032/2669641169745857*cos(39*log(100))/log(100)^5 + 1701991773241344/3248953303580707969*sin(39*log(100))/log(100)^6 - 22083449597755392/3248953303580707969*cos(39*log(100))/log(100)^6 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Complex Coercion Error or User Error?
I've been working more on TOS's Li based pi(x) approximation code.
I've been trying to optimize it in c. It seems that I need someone
more knowledgeable than myself in c to point out some simple mistake I
am making that is preventing the code from giving the correct answer.
I tried copying and pasting the li function below into a Sage cell and
"Pythonizing" it, and I got the expected answer, but as is in a c
file, with commands being piped in the command line, I get unexpected
results in Sage. I believe that the c li function below is correct-I
think I am just making some sort of simple error in moving data
around. I have already asked one of my peers in my number theory
class, and we are both stuck.
Sage:
import subprocess
def fastli(x,y):
thesubprocess=subprocess.Popen(args=["/home/kstueve/Desktop/
riemannpi/li",str(x),str(y)],stdout=subprocess.PIPE)
return float(thesubprocess.communicate()[int(0)])
c:
#include
#include
//This is some rough code to calculate li(x^(0.5+it))+li(x^(0.5-it))
//Authors:
//Tomas Oliveira e Silva: Original Version
//Kevin Stueve: Rewrote and optimized in c
//Released under GPL
const double zeros[]={
14.134725142,21.022039639,25.01085758,30.424876126,32.935061588,
21.022039639,25.01085758,30.424876126,32.935061588,37.586178159,
25.01085758,30.424876126,32.935061588,37.586178159,40.918719012,
30.424876126,32.935061588,37.586178159,40.918719012,43.327073281,
32.935061588,37.586178159,40.918719012,43.327073281,48.005150881,
37.586178159,40.918719012,43.327073281,48.005150881,49.773832478,
40.918719012,43.327073281,48.005150881,49.773832478,52.970321478,
43.327073281,48.005150881,49.773832478,52.970321478,56.446247697,
48.005150881,49.773832478,52.970321478,56.446247697,59.347044003,
49.773832478,52.970321478,56.446247697,59.347044003,60.831778525,
52.970321478,56.446247697,59.347044003,60.831778525,65.112544048,
56.446247697,59.347044003,60.831778525,65.112544048,67.079810529,
59.347044003,60.831778525,65.112544048,67.079810529,69.546401711,
60.831778525,65.112544048,67.079810529,69.546401711,72.067157674,
65.112544048,67.079810529,69.546401711,72.067157674,75.704690699,
};
double li(double x, double t);
int main(int argc,char **argv){
//printf("zero%f",zeros[5]);
double x=atof(argv[1]);
long int num = atol(argv[2]);
//printf("%f\n",x);
//printf("%ld\n",num);
double result=0;
long int i=0;
for (i=0;i100) {
printf("error%f\n",t);
return;
//break;
}
s2_real_temp = k * (s2_real * u_real + s2_imag * u_imag) /
u_norm;
s2_imag_temp = k * (s2_imag * u_real - s2_real * u_imag) /
u_norm;
s2_real = s2_real_temp;
s2_imag = s2_imag_temp;
s1_real += s2_real;
s1_imag += s2_imag;
norm=s2_real * s2_real + s2_imag * s2_imag;
if (norm < tol_squared) {
break;
}
//lastnorm=norm;
k++;
}
return so_real * s1_real - so_imag * s1_imag;
}
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Sage 4.3.4.alpha0 released
Hi folks, On Thu, Mar 4, 2010 at 5:05 AM, Minh Nguyen wrote: > * The following tests failed on sage.math: They also fail on bsd.math and rosemary.math. This issue is now tracked at ticket #8430: http://trac.sagemath.org/sage_trac/ticket/8430 -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Infinite recursion in coersion?
I found a distressing bug just now: sage: R. = NumberField(f,'a') sage: a.n() Traceback (most recent call last):a.n() File "", line 1, in File "/tmp/tmp8r5Xa6/___code___.py", line 3, in exec compile(ur'a.n()' + '\n', '', 'single') File "", line 1, in File "element.pyx", line 455, in sage.structure.element.Element.n (sage/structure/element.c:4028) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/misc/functional.py", line 1140, in numerical_approx return sage.rings.real_mpfr.RealField_constructor(prec)(x) File "parent.pyx", line 538, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) File "coerce_maps.pyx", line 156, in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4098) File "number_field_element.pyx", line 845, in sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ (sage/rings/number_field/number_field_element.cpp:8067) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", line 267, in __call__ return Parent.__call__(self, x) File "parent.pyx", line 538, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) File "coerce_maps.pyx", line 82, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3142) File "coerce_maps.pyx", line 77, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3040) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", line 294, in _element_constructor_ return complex_number.ComplexNumber(self, x) File "complex_number.pyx", line 153, in sage.rings.complex_number.ComplexNumber.__init__ (sage/rings/complex_number.c:3116) File "parent.pyx", line 538, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) File "coerce_maps.pyx", line 156, in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4098) File "number_field_element.pyx", line 845, in sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ (sage/rings/number_field/number_field_element.cpp:8067) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", line 267, in __call__ return Parent.__call__(self, x) File "parent.pyx", line 538, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) File "coerce_maps.pyx", line 82, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3142) File "coerce_maps.pyx", line 77, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3040) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", line 294, in _element_constructor_ return complex_number.ComplexNumber(self, x) File "complex_number.pyx", line 153, in sage.rings.complex_number.ComplexNumber.__init__ (sage/rings/complex_number.c:3116) File "parent.pyx", line 538, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4956) File "coerce_maps.pyx", line 156, in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4098) File "number_field_element.pyx", line 845, in sage.rings.number_field.number_field_element.NumberFieldElement._mpfr_ (sage/rings/number_field/number_field_element.cpp:8067) File "/mnt/usb1/scratch/boothby/sage-4.3.1/local/lib/python2.6/site-packages/sage/rings/complex_field.py", line 267, in __call__ ... RuntimeError: maximum recursion depth exceeded Is there a cycle in the coercion structure? If yes, should we check for the existence of such cycles? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Let's collect data on Sage startup time.
> 1) Sun Blade 2000, circa 2000 > 2 x 900 MHz UltraSPARC III+ CPUs > Load average 1 (Sorry, I'm doing something and can't stop that) > 1x 147 GB Seagate SEAGATE-ST3146807FC. 15,000 rpm SCSI with a 2 Gbit/s fibre > channel interface. > Sage version 4.3.3 with patches for Solaris as documented at > http://trac.sagemath.org/sage_trac/ticket/8409 > Median of the 5 runs is: > sage: sage: > > Exiting SAGE (CPU time 0m0.17s, Wall time 0m0.19s). > > real 0m8.263s > user 0m6.502s > sys 0m1.392s > > Maximum time of the 5 runs is > real 0m8.356s > > Minimum tie of the 5 runs is > real 0m8.066s > 2) Macbook Pro, circa 2009 > 2.66GHz Intel Core 2 Duo > Fairly loaded (Activity Monitor reports about 70% idle CPU, 635MB/4GB free > memory) > > Median time of 5 runs: > real 0m2.390s > Maximum of the 5 runs: > real 0m22.064s 3) Mobile Intel(R) Pentium(R) III CPU - M 1000MHz, idle, 256 MB Median time of 5 runs: real0m7.632s Maximum of the 5 runs: real0m34.508s Time goes down to 0m5.211s, but for me only the time of the first start is important. I do not see any usecase where I'd start and quit sage 5 times in a row. For comparison, FriCAS takes only 0m0.797s on this machine. Martin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage 4.3.4.alpha0 released
Hi folks, This release incorporates many combinatorics tickets positively reviewed during and/or before Sage Days 20. Source tarball: http://sage.math.washington.edu/home/release/sage-4.3.4.alpha0/sage-4.3.4.alpha0.tar Binary for sage.math: http://sage.math.washington.edu/home/release/sage-4.3.4.alpha0/sage-4.3.4.alpha0-sage.math.washington.edu-x86_64-Linux.tar.gz Upgrade path: http://sage.math.washington.edu/home/release/sage-4.3.4.alpha0/sage-4.3.4.alpha0/ New features and updated/upgraded packages: * 11 tickets improving on the combinatorics module due to the hard work of the Sage-Combinat team. * 7 tickets that moves Sage closer to a Solaris/OpenSolaris port. * 5 tickets on enhancing the graph theory module. * 5 tickets improving on the linear algebra module. * atlas-3.8.3.p12 * cddlib-094f.p5 * ecl-10.2.1 * iconv-1.13.1 * mpmath-0.14 * python-2.6.4.p6 * r-2.10.1.p0 * sagetex-2.2.3.p0 * twisted-9.0.p2 * zn_poly-0.9.p3 * pyprocessing is now removed from the standard spkg repository. Known issues: * If you are upgrading from Sage 4.3.3 to Sage 4.3.4.alpha0, you would notice that the package "gfan-0.4plu" is also slated to be upgraded as well. However, note that the gfan spkg is named "gfan-0.4plus", not "gfan-0.4plu". This issue is tracked at ticket #8307. * Doing "make test", "make testlong", "make ptest", "make ptestlong" would leave behind the following file: sage/schemes/elliptic_curves/PRIMES This is due to ticket #7575. * The following tests failed on sage.math: sage -t -long local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/interact.py # 1 doctests failed sage -t -long local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/misc/sageinspect.py # 1 doctests failed sage -t -long devel/sage/sage/categories/finite_semigroups.py # 2 doctests failed sage -t -long devel/sage/sage/categories/examples/finite_semigroups.py # 1 doctests failed Please test and report all issues. With Sage 4.3.4.alpha0 released, I'm handing the baton over to Mike Hansen, who will chair the release of Sage 4.3.4.alpha1. The following tickets were merged in Sage 4.3.4.alpha0: #6503: John Palmieri, Mike Hansen: remove the pyprocessing spkg from sage, then sort out any fallout that results [Reviewed by Minh Van Nguyen] #7520: Sébastien Labbé: Improving word construction [Reviewed by Franco Saliola] #7552: Tim Dumol, Jaap Spies: Update the Twisted package to 9.0 [Reviewed by William Stein, Mitesh Patel, David Kirkby] #7619: Sébastien Labbé: Pickling support for finite word defined by callable and iterable [Reviewed by Franco Saliola] #7671: Nathann Cohen: strongly_connected_components in c_graphs [Reviewed by Robert Miller] #7761: Jaap Spies: Python 2.6.2.p4 faills to build on OpenSolaris [Reviewed by David Kirkby] #7854: Nathann Cohen: speed up edge_connectivity in easy cases [Reviewed by Paul Zimmermann] #7872: Bill Cauchois, Oscar Gerardo Lazo Arjona, Jason Grout: Adding coordinate transformations to plot3d [Reviewed by Karl-Dieter Crisman, Jason Grout] #7877: Jason Grout: matrix indexing should be explained in the manual [Reviewed by Robert Bradshaw, Minh Van Nguyen] #7927: Jennifer Balakrishnan, Robert Bradshaw: Extend coleman integration to handle Weierstrass points [Reviewed by Kiran Kedlaya] #7966: Nathann Cohen: Giving some punch to distance computations [Reviewed by Paul Zimmermann] #7984: Robert Bradshaw: QQbar doesn't use canonical coercion for comparison [Reviewed by John Cremona] #8008: Jason Grout: Implement an rref() function which works over the fraction field of the base ring of a matrix [Reviewed by Sebastian Pancratz, Minh Van Nguyen, Karl-Dieter Crisman, Rob Beezer] #8037: Marc Mezzarobba: add sagetex to the french tutorial [Reviewed by Dan Drake] #8039: Jaap Spies: ATLAS libs fail to build on Open Solaris 64 bit due to wrong LDFLAG -melf_x86_64 [Reviewed by David Kirkby] #8131: Francis Clarke: Catalan numbers are integers [Reviewed by Nicolas Borie] #8157: Francois Maltey, Paul Zimmermann: why the bit limit of 2^24 in RealField? [Reviewed by Alex Ghitza] #8159: Fredrik Johansson: Updated Cython backend for mpmath [Reviewed by Harald Schilly] #8178: Jaap Spies: zn_poly fails to build in Open Solaris x64 as 64 bit even if SAGE64=yes [Reviewed by David Kirkby] #8187: Sébastien Labbé: improve equality tests for words [Reviewed by Alexandre Blondin Massé] #8191: David Kirkby: Add iconv needed for Solaris, and possibly Cygwin too [Reviewed by Minh Van Nguyen] #8227: Alexandre Blondin Massé: Improving iterated palindromic closure computation [Reviewed by Sébastien Labbé] #8244: John Palmieri, Mitesh Patel: Annoying warnings when building the HTML reference manual [Reviewed by Mitesh Patel, John Palmieri] #8255: Dan Drake: update SageTeX spkg to 2.2.3.p0 to fix spkg-check script [Reviewed by John Palmieri] #8259: Anne Schilling: Conversion from symmetric polynomials to basis of monomial symmetric functions [Reviewed by Jason Bandlow] #8260: Robert Bradshaw:
Re: [sage-devel] Let's collect data on Sage startup time.
2) Macbook Pro, circa 2009 2.66GHz Intel Core 2 Duo Fairly loaded (Activity Monitor reports about 70% idle CPU, 635MB/4GB free memory) But the conclusion seems fairly clear. Median time of 5 runs: real0m2.390s Maximum of the 5 runs: real0m22.064s The maximum was first, and afterward all of the subsequent runs had tightly clustered startup times (ranging from 2.317s to 2.412s) David On Wed, Mar 3, 2010 at 12:16 PM, Dr. David Kirkby wrote: > Ticket http://trac.sagemath.org/sage_trac/ticket/8254 > > "sage takes way too long to startup" > > seems to irritate a lot of people. It does not me too much, but I feel one > way to at least start to tackle this probably is to get some quantifiable > data and see where the time is being spent. My hunch is that this is due to > disk I/O. > > If we all append our results running > > time echo "2+2;" | /absolute/path/to/sage > > where /absolute/path/to/sage should be a *local* file system. If it is > shared via NFS, then it just adds another unknown. > > Then we might get somewhere and see if there is a common problem, though I > think 'dtrace' on Solaris or OS X is likely to be the most useful tool for > debugging this. > > Considering the age of my SPARC (it is circa 2000), I'm getting a startup > time less than some are reporting with what I suspect is much more modern > hardware. One thing my SPARC does however have is disks and a disk interface > which is probably superior to 90% of modern PCs. > > I'd suggest running it 5x, reporting the median value for "median" values > of "real" time, and as well as maximum and minimum. > > So here is one set of data/ > > 1) Sun Blade 2000, circa 2000 > 2 x 900 MHz UltraSPARC III+ CPUs > Load average 1 (Sorry, I'm doing something and can't stop that) > 1x 147 GB Seagate SEAGATE-ST3146807FC. 15,000 rpm SCSI with a 2 Gbit/s > fibre channel interface. > Sage version 4.3.3 with patches for Solaris as documented at > http://trac.sagemath.org/sage_trac/ticket/8409 > Median of the 5 runs is: > sage: sage: > > Exiting SAGE (CPU time 0m0.17s, Wall time 0m0.19s). > > real0m8.263s > user0m6.502s > sys 0m1.392s > > Maximum time of the 5 runs is > real0m8.356s > > Minimum tie of the 5 runs is > real0m8.066s > > I can't be bothered to determine whether that is statistically significant > or not, but it seems to me that data is pretty reproducible. > > What is clear here is that this seems to be CPU bound on my old machine, > which is hardly surprising given the old CPUs, but 15,000 rpm disks. That > might give us a clue. > > Anyone else care to put their data here too? > > Dave > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On Wed, Mar 3, 2010 at 9:12 AM, Florent Hivert wrote: > Hi William, > > On Wed, Mar 03, 2010 at 05:48:28AM -0800, William Stein wrote: >> On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby >> wrote: >> >> Right now it takes over 1.5 seconds every time. >> >> wst...@sage:~$ time sage -c "print factor(2010)" >> >> 2 * 3 * 5 * 67 >> >> real 0m1.535s >> >> user 0m1.140s >> >> sys 0m0.460s >> > >> > Personaly I don't find that too excessive for a large tool. How long does >> > Gimp take to start? >> >> That's irrelevant. What matters is how long Maple, Mathematica, >> Matlab, Maxima, Pari, and Magma take to start. >> After repeatedly running the command on sage.math, this is how things >> stabilize: > > I'm not sure your benchmark correctly reflect what happens. My benchmark correctly reflects what I wanted to have it reflect. It would also be of interest to consider issues of disk speed and total reads, but I would like to very clearly separate that out by making a precisely stated benchmark, which I did. > Here are three > consecutive launches on a relatively fast idle machine: > > tomahawk-~ $ time sage -c "print factor(2010)" > 2 * 3 * 5 * 67 > sage -c "print factor(2010)" 2,32s user 1,00s system 14% cpu 22,943 total > tomahawk-~ $ time sage -c "print factor(2010)" > 2 * 3 * 5 * 67 > sage -c "print factor(2010)" 1,34s user 0,34s system 101% cpu 1,648 total > tomahawk-~ $ time sage -c "print factor(2010)" > 2 * 3 * 5 * 67 > sage -c "print factor(2010)" 1,33s user 0,32s system 97% cpu 1,686 total > > The difference is enormous: more than one order of magnitude. IMHO the main > problem is that at startup sage must access a *lot* of files and that access > disk is the bottleneck. Once all those file are in the buffer/cache, the speed > is completely different. And, once those files are in the buffer/cache... the speed is still LAME (compared to any other MA's under identical circumstanced). Which is my point. William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: wrapping fortran libraries in an spkg
there are interactions with lapack and atlas in CVXOPT, for instance. On Mar 3, 2:35 pm, Jason Grout wrote: > I couldn't find any good spline routines in Sage for constructing simple > splines with given boundary conditions (are there any? There are some > spline routines in scipy, but not what I was looking for). So I found > one of the standard routines on netlib and used that inside of a > %fortran cell in the notebook [1]. If I or one of my students wanted to > wrap this routine in a Sage Spline class, does anyone have any tips for > how to do it? Is there an example of a fortran library that a Sage > class (Cython or Python) interfaces directly with? For example, I know > we include lapack, but I didn't find any files in Sage that seemed to > directly import or use a lapack function. > > Thanks, > > Jason > > [1]http://sagenb.org/home/pub/1708/ > > -- > Jason Grout -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: unsolicited Sage emails
On 3 March 2010 17:03, Harald Schilly wrote: > On Mar 3, 5:05 pm, William Stein wrote: >> A couple of days ago, I put the following on my website, since I get a >> really *huge* amount of off-list email directed at me about Sage. > > I've also put that up here: http://sagemath.org/contact.html You could reduce some of William's inbox by deleting the trac account entry in that list! John > > H > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Let's collect data on Sage startup time.
Ticket http://trac.sagemath.org/sage_trac/ticket/8254 "sage takes way too long to startup" seems to irritate a lot of people. It does not me too much, but I feel one way to at least start to tackle this probably is to get some quantifiable data and see where the time is being spent. My hunch is that this is due to disk I/O. If we all append our results running time echo "2+2;" | /absolute/path/to/sage where /absolute/path/to/sage should be a *local* file system. If it is shared via NFS, then it just adds another unknown. Then we might get somewhere and see if there is a common problem, though I think 'dtrace' on Solaris or OS X is likely to be the most useful tool for debugging this. Considering the age of my SPARC (it is circa 2000), I'm getting a startup time less than some are reporting with what I suspect is much more modern hardware. One thing my SPARC does however have is disks and a disk interface which is probably superior to 90% of modern PCs. I'd suggest running it 5x, reporting the median value for "median" values of "real" time, and as well as maximum and minimum. So here is one set of data/ 1) Sun Blade 2000, circa 2000 2 x 900 MHz UltraSPARC III+ CPUs Load average 1 (Sorry, I'm doing something and can't stop that) 1x 147 GB Seagate SEAGATE-ST3146807FC. 15,000 rpm SCSI with a 2 Gbit/s fibre channel interface. Sage version 4.3.3 with patches for Solaris as documented at http://trac.sagemath.org/sage_trac/ticket/8409 Median of the 5 runs is: sage: sage: Exiting SAGE (CPU time 0m0.17s, Wall time 0m0.19s). real0m8.263s user0m6.502s sys 0m1.392s Maximum time of the 5 runs is real0m8.356s Minimum tie of the 5 runs is real0m8.066s I can't be bothered to determine whether that is statistically significant or not, but it seems to me that data is pretty reproducible. What is clear here is that this seems to be CPU bound on my old machine, which is hardly surprising given the old CPUs, but 15,000 rpm disks. That might give us a clue. Anyone else care to put their data here too? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
Hi William, On Wed, Mar 03, 2010 at 05:48:28AM -0800, William Stein wrote: > On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby > wrote: > >> Right now it takes over 1.5 seconds every time. > >> wst...@sage:~$ time sage -c "print factor(2010)" > >> 2 * 3 * 5 * 67 > >> real 0m1.535s > >> user 0m1.140s > >> sys 0m0.460s > > > > Personaly I don't find that too excessive for a large tool. How long does > > Gimp take to start? > > That's irrelevant. What matters is how long Maple, Mathematica, > Matlab, Maxima, Pari, and Magma take to start. > After repeatedly running the command on sage.math, this is how things > stabilize: I'm not sure your benchmark correctly reflect what happens. Here are three consecutive launches on a relatively fast idle machine: tomahawk-~ $ time sage -c "print factor(2010)" 2 * 3 * 5 * 67 sage -c "print factor(2010)" 2,32s user 1,00s system 14% cpu 22,943 total tomahawk-~ $ time sage -c "print factor(2010)" 2 * 3 * 5 * 67 sage -c "print factor(2010)" 1,34s user 0,34s system 101% cpu 1,648 total tomahawk-~ $ time sage -c "print factor(2010)" 2 * 3 * 5 * 67 sage -c "print factor(2010)" 1,33s user 0,32s system 97% cpu 1,686 total The difference is enormous: more than one order of magnitude. IMHO the main problem is that at startup sage must access a *lot* of files and that access disk is the bottleneck. Once all those file are in the buffer/cache, the speed is completely different. I'm always surprised that they are many thing that I won't ever use that are imported at the top level of sage. Shouldn't we clean up what is imported and what is not imported by default and make it easy to import bunch of thing. For example, Many people certainly don't care about many stuff in combinatorics. Shouldn't we import by default very basic thing (permutations and cartesian_product) and let the user who is interested in combinatorics write the from sage.combinat import * ? My 2 cents, which has probably already been discussed before... Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: unsolicited Sage emails
On Mar 3, 5:05 pm, William Stein wrote: > A couple of days ago, I put the following on my website, since I get a > really *huge* amount of off-list email directed at me about Sage. I've also put that up here: http://sagemath.org/contact.html H -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Possible to avoid "sage:" in example code?
I was able to realize the desired result by modifying some lines in
sphinx/highlighting.py:
try:
if self.dest == 'html':
# Add '>>> ' and '... ' as appropriate if really want
interactive mode.
source_copy = ''
line_count = 0
for line in source.splitlines():
if line.startswith('>>> '):
if line_count == 0:
# Cell begins in interactive mode, and may
contain
# output statements that we do not want to
classify
# as code. Therefore, copy the source and exit
loop
source_copy = source
break
else:
# Check to see if we are indented
line_len = len(line)
source_len = len(line.lstrip())
if line_len != source_len:
source_copy = source_copy + '... '
else:
source_copy = source_copy + '>>> '
source_copy = source_copy + line + '\n'
line_count += 1
source = source_copy
return highlight(source, lexer, self.fmter[bool(linenos)])
else:
hlsource = highlight(source, lexer,
self.fmter[bool(linenos)])
return hlsource.translate(tex_hl_escape_map)
except ErrorToken:
# this is most probably not the selected language,
# so let it pass unhighlighted
return self.unhighlighted(source)
It would be great to be able to safely override this, but I do not see
how. I noticed SAGE also modifies their highlighting.py file, too
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
Martin Rubey wrote: Personally I have a bit of a problem understanding why I need to worry about a program starting up in less than 2 s, when I might run something on it which will take at least one order of magnitude longer, and probably several order of magnitudes longer. I can only say why it matters for me: mar...@rubey-laptop:~/Documents/sage-4.1.1-linux-Ubuntu_9.04-i686-Linux$ time echo "2+2;" | ./sage -- | Sage Version 4.1.1, Release Date: 2009-08-14 | | Type notebook() for the GUI, and license() for information.| -- Loading Sage library. Current Mercurial branch is: combinat sage: sage: Exiting SAGE (CPU time 0m0.26s, Wall time 0m0.84s). real0m18.403s user0m5.144s sys 0m1.304s Martin OK, 18 s is a bit more significant. 1.5 s I have a bit more of a problem with worrying about. I'm going to start another thread on this specific issue of startup time. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
> Personally I have a bit of a problem understanding why I need to > worry about a program starting up in less than 2 s, when I might run > something on it which will take at least one order of magnitude > longer, and probably several order of magnitudes longer. I can only say why it matters for me: mar...@rubey-laptop:~/lib/fricas/target/i686-pc-linux/bin$ time echo "2+2" | ./AXIOMsys Checking for foreign routines AXIOM=NIL spad-lib="/lib/libspad.so" FriCAS (AXIOM fork) Computer Algebra System Version: FriCAS 2010-01-08 Timestamp: Monday February 22, 2010 at 13:22:25 - Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave FriCAS and return to shell. - (1) -> Warning: HyperTeX macro table not found (1) 4 Type: PositiveInteger (2) -> real0m0.797s user0m0.404s sys 0m0.076s mar...@rubey-laptop:~/Documents/sage-4.1.1-linux-Ubuntu_9.04-i686-Linux$ time echo "2+2;" | ./sage -- | Sage Version 4.1.1, Release Date: 2009-08-14 | | Type notebook() for the GUI, and license() for information.| -- Loading Sage library. Current Mercurial branch is: combinat sage: sage: Exiting SAGE (CPU time 0m0.26s, Wall time 0m0.84s). real0m18.403s user0m5.144s sys 0m1.304s Martin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] unsolicited Sage emails
Hi, A couple of days ago, I put the following on my website, since I get a really *huge* amount of off-list email directed at me about Sage. Since I'm going to stick to it, and it's relevant to many people on these lists I'm posting this here, so people will know. "WARNING: If you send me an unsolicited email related to Sage, I will by default cc my response to one of the public Sage mailing lists (such as sage-support). If you explicitly ask that I don't, then I will probably not respond to your email. I do this because I feel that I am often not the best person to respond to a Sage question, and I want to give all Sage developers a chance to respond as well. Very, very often, somebody other than me is better qualified to answer a question." -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Randomised testing against Mathematica
mhampton wrote: There has been some previous discussion about this on sage-devel, I can't find exactly the thread I remember but here's a somewhat related one: http://groups.google.com/group/sage-devel/browse_thread/thread/b91c51672ae0f475/ Thank you. Personally I think it makes sense to put the most effort into getting sage to 100% coverage. I agree with you there. The randomised testing happens to be one area where I could perhaps personally contribute something useful, whereas I don't feel I can with the doc tests - at least not many of them. I did wonder if the get_memory_usage() should perhaps take the output and compare it to what is reasonable. i.e. if Sage starts and uses more than 300 MB RAM, then something is probably wrong. Conversely if it uses less than 30 MB RAM, something is probably wrong. (Those numbers might change over time of course). Whenever possible when writing doctests the results should be checked. Perhaps in some test blocks it could be remarked that the result has been verified by another system. Yes agree. I mentioned this the other day when a doc test failed on Solaris, but the reason the expected value was given in the doc test was not justified. It seemed to be based on what someone got as a result. When I computed the result in Mathematica using high precision, the result I actually got was closer to the true value that the "expected" value in the doc test. I tried to address that somewhat patch to correct a numerical noise issue, where I stated * The high precision value of 'e' * The nearest rounded number * The nearest number corresponding to the IEEE standard. * The number I actually got on my SPARC. http://trac.sagemath.org/sage_trac/attachment/ticket/8374/8374-numerical-noise.2.patch (Both http://trac.sagemath.org/sage_trac/ticket/8374 and http://trac.sagemath.org/sage_trac/ticket/8375, which are very similar patches, are still awaiting review. There should be some justification deciding what is the expected result, not simply putting a number in the doc test, since that is what someone's computer happens to give. -Marshall Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
William Stein wrote: On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby wrote: Right now it takes over 1.5 seconds every time. wst...@sage:~$ time sage -c "print factor(2010)" 2 * 3 * 5 * 67 real0m1.535s user0m1.140s sys 0m0.460s Personaly I don't find that too excessive for a large tool. How long does Gimp take to start? That's irrelevant. What matters is how long Maple, Mathematica, Matlab, Maxima, Pari, and Magma take to start. After repeatedly running the command on sage.math, this is how things stabilize: Pari 0.030s Python 0.046s Maple 0.111s Maxima 0.456s Mathematica0.524s Matlab 0.844s Magma 0.971s Sage 1.658s Fair point. Personally I have a bit of a problem understanding why I need to worry about a program starting up in less than 2 s, when I might run something on it which will take at least one order of magnitude longer, and probably several order of magnitudes longer. wst...@sage:~$ time echo "2+2;" | math Mathematica 6.0 for Linux x86 (64-bit) Copyright 1988-2007 Wolfram Research, Inc. In[1]:= In[2]:= real0m0.524s Either my Sun Ultra 27 is significantly quicker than sage.math, or Wolfram Research have made significant improvements, since 6.0, as version 7.0 computes that in less than half the time. drkir...@hawk:~$ time echo "2+2;" | math Mathematica 7.0 for Sun Solaris x86 (64-bit) Copyright 1988-2009 Wolfram Research, Inc. In[1]:= In[2]:= real0m0.251s user0m0.166s sys 0m0.121s drkir...@hawk:~$ For something a bit more taxing: drkir...@hawk:~$ time echo "Factorial[1000];" | math Mathematica 7.0 for Sun Solaris x86 (64-bit) Copyright 1988-2009 Wolfram Research, Inc. In[1]:= In[2]:= real0m20.699s user0m20.491s sys 0m0.207s -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On 03/03/2010 05:48 AM, William Stein wrote: > Pari 0.030s > Python 0.046s > Maple 0.111s > Maxima 0.456s > Mathematica0.524s > Matlab 0.844s > Magma 0.971s > Sage 1.658s > > This is probably the only benchmark that involves a "function" that > *everybody* uses -- starting up the program. Sage is currently dead > last, and by a lot. Python and Pari are both by far the fastest to > startup, so at least it isn't Python's fault :-). On a somewhat(?) related note: How difficult is it to implement analogues of the suspend, resume, and snapshot features that VirtualBox, VMWare, etc., have? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
2010/3/3 William Stein : > On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby > wrote: >>> Right now it takes over 1.5 seconds every time. >>> wst...@sage:~$ time sage -c "print factor(2010)" >>> 2 * 3 * 5 * 67 >>> real 0m1.535s >>> user 0m1.140s >>> sys 0m0.460s >> >> Personaly I don't find that too excessive for a large tool. How long does >> Gimp take to start? > > That's irrelevant. What matters is how long Maple, Mathematica, > Matlab, Maxima, Pari, and Magma take to start. > After repeatedly running the command on sage.math, this is how things > stabilize: > > > Pari 0.030s > Python 0.046s > Maple 0.111s > Maxima 0.456s > Mathematica 0.524s > Matlab 0.844s > Magma 0.971s > Sage 1.658s > > This is probably the only benchmark that involves a "function" that > *everybody* uses -- starting up the program. Sage is currently dead > last, and by a lot. Python and Pari are both by far the fastest to > startup, so at least it isn't Python's fault :-). > > > LOG: > > wst...@sage:~$ time echo "2+2;" | sage -python > real 0m0.046s > > wst...@sage:~$ time echo "2+2;" | magma > Magma V2.14-9 Wed Mar 3 2010 05:40:30 on sage [Seed = 2126205915] > Type ? for help. Type -D to quit. > 4 > > Total time: 0.570 seconds, Total memory usage: 6.94MB > > real 0m0.971s > > -- > > wst...@sage:~$ time echo "2+2;" | maple > |\^/| Maple 12 (X86 64 LINUX) > ._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2008 > \ MAPLE / All rights reserved. Maple is a trademark of > < > Waterloo Maple Inc. > | Type ? for help. >> 2+2; > 4 > >> quit > memory used=0.8MB, alloc=0.7MB, time=0.01 > > real 0m0.111s > > --- > > wst...@sage:~$ time echo "2+2;" | math > Mathematica 6.0 for Linux x86 (64-bit) > Copyright 1988-2007 Wolfram Research, Inc. > > In[1]:= > In[2]:= > > real 0m0.524s > > > -- > > wst...@sage:~$ time echo "2+2;" | matlab > Warning: Unable to open display , MATLAB is starting without a display. > You will not be able to display graphics on the screen. > Warning: > MATLAB is starting without a display, using internal event queue. > You will not be able to display graphics on the screen. > > > < M A T L A B > > Copyright 1984-2006 The MathWorks, Inc. > Version 7.2.0.283 (R2006a) > January 27, 2006 > > > To get started, type one of these: helpwin, helpdesk, or demo. > For product information, visit www.mathworks.com. > >>> >> > real 0m0.844s > > --- > > wst...@sage:~$ time echo "2+2;" | sage -maxima > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/defsystem.fas" > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/cmp.fas" > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/sysfun.lsp" > Maxima 5.20.1 http://maxima.sourceforge.net > using Lisp ECL 9.10.2 > Distributed under the GNU Public License. See the file COPYING. > Dedicated to the memory of William Schelter. > The function bug_report() provides bug reporting information. > (%i1) > (%o1) 4 > (%i2) > real 0m0.456s > > --- > > > wst...@sage:~$ time echo "2+2;" | sage -gp > GP/PARI CALCULATOR Version 2.3.3 (released) > amd64 running linux (x86-64/GMP-4.2.1 kernel) 64-bit version > compiled: Feb 25 2010, gcc-4.2.4 (Ubuntu 4.2.4-1ubuntu4) > (readline v6.0 enabled, extended help available) > > Copyright (C) 2000-2006 The PARI Group > > PARI/GP is free software, covered by the GNU General Public License, and > comes WITHOUT ANY WARRANTY WHATSOEVER. > > Type ? for help, \q to quit. > Type ?12 for how to get moral (and possibly technical) support. > > parisize = 800, primelimit = 50 > Goodbye! > > real 0m0.030s > > --- > > wst...@sage:~$ time echo "2+2;" | sage > -- > | Sage Version 4.3.3, Release Date: 2010-02-21 | > | Type notebook() for the GUI, and license() for information. | > -- > sage: sage: > Exiting SAGE (CPU time 0m0.05s, Wall time 0m0.06s). > > real 0m1.658s A suggestion to debug these issues is to use oprofile. A cheat sheet from a procedure I used some times in the past to debug performance of multi programs/modules/libraries is: # rm -fr /var/lib/oprofile/samples/current/; opcontrol --init; opcontrol --start; ; opcontrol --dump; opcontrol --stop; opcontrol --deinit # opreport --symbols In my tests, I would run as root, have the computer as idle as possible, and also do the start/stop of oprofile logging to avoid as much as possible any noise. This of couse is Linux specific, but similar tools should exist in other OSes. An examp
Re: [sage-devel] Randomised testing against Mathematica
There are two test suites with validated results at http://axiom-developer.org/axiom-website/CATS/ The CATS (Computer Algebra Test Suite) effort targets the development of known-good answers that get run against several systems. These "end result" suites test large portions of the system. As they are tested against published results they can be used by all systems. The integration suite found several bugs in the published results which are noted in the suite. It also found a bug introduced by an improper patch to Axiom. It would be generally useful if Sage developed known-good test suites in other areas, say infinite sequences and series. Perhaps such a suite would make a good GSOC effort with several moderators from different systems. I have done some more work toward a trigonometric test suite. So far I have found that Mathematica and Maxima tend to agree on branch cuts and Axiom and Maple tend to agree on branch cuts. The choice is arbitrary but it affects answers. I am having an internal debate about whether to choose MMA/Maxima compatible answers just to "regularize" the expected results users will see. Standardized test suites give our users confidence that we are generating known-good results for some (small) range of expected inputs. An academic-based effort (which Axiom is not) could approach NIST for funding an effort to develop such suites. NIST has a website (http://dlmf.nist.gov/) Digital Library of Mathematical Functions. I proposed developing Computer Algebra test suites for their website but NIST does not fund independent open source projects. Sage, however, could probably get continuous funding to develop such suites which would benefit all of the existing CAS efforts. NSF might also be convinced since such test suites raise the level of expected quality of answers without directly competing against commercial efforts. I'd like to see a CAS testing research lab that published standardized answers to a lot of things we all end up debating, such as branch cuts, sqrt-of-squares, foo^0, etc. Tim Daly Dr. David Kirkby wrote: Joshua Herman wrote: Is there a mathematica test suite we could adapt or a standardized set of tests we could use? Maybe we could take the 100 most often used functions and make a test suite? I'm not aware of one. A Google found very little of any real use. I'm sure Wolfram Research have such test suites internally, but they are not public. There is discussion of how they have an internal version of Mathematica which runs very slowly, but tests things in greater detail. http://reference.wolfram.com/mathematica/tutorial/TestingAndVerification.html Of course, comparing 100 things is useful, but comparing millions of them in the way I propose would more likely show up problems. I think we are all aware that it is best to test on the hardware you are using to be as confident as possible that the results are right. Of course, Wolfram Research could supply a test suite to check Mathematica on an end user's computer, but they do not do that. They could even encrypt it, so users did not know what was wrong, but could at least alert Wolfram Research. I'm aware of one bug in Mathematica that only affected old/slower SPARC machines if Solaris was updated to Solaris 10. I suspect it would have affected newer machines too, had they been heavily loaded. (If I was sufficiently motivated, I would probably prove that, but I'm not, so my hypothesis is unproven). It did not produce incorrect results, but pegged the CPU at 100% forever if you computed something as simple as 1+1.) It was amazing how that was solved between myself, Casper Dik a kernel engineer at Sun and various other people on the Internet. It was Casper who finally nailed the problem, after I posted the output of lsof, he could see what Mathematica was doing. I've got a collection of a few Mathematica bugs, mainly affecting only Solaris, although one affected at least one Linux distribution too. http://www.g8wrb.org/mathematica/ One thing I know Mathematica does do, which Sage could do, is to automatically generate bug report if it finds a problem. At the most primitive level, that code might be if (x < 0) function_less() else if (x == 0) function_equal() else if (x > 0) function_greater() else function_error() If the error is generated, a URL is given, which you click and can send a bug report to them. It lists the name of the file and line number which generated the error. That's something that could be done in Sage and might catch some bugs. Dave LOOK ITS A SIGNATURE CLICK IF YOU DARE--- http://www.google.com/profiles/zitterbewegung On Wed, Mar 3, 2010 at 12:04 AM, David Kirkby wrote: Has anyone ever considered randomised testing of Sage against Mathematica? As long as the result is either a) True or False b) An integer then comparison should be very easy. As a dead simple example, 1) Generate a large random number n. 2) Use is_prime(
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby wrote: >> Right now it takes over 1.5 seconds every time. >> wst...@sage:~$ time sage -c "print factor(2010)" >> 2 * 3 * 5 * 67 >> real 0m1.535s >> user 0m1.140s >> sys 0m0.460s > > Personaly I don't find that too excessive for a large tool. How long does > Gimp take to start? That's irrelevant. What matters is how long Maple, Mathematica, Matlab, Maxima, Pari, and Magma take to start. After repeatedly running the command on sage.math, this is how things stabilize: Pari 0.030s Python 0.046s Maple 0.111s Maxima 0.456s Mathematica0.524s Matlab 0.844s Magma 0.971s Sage 1.658s This is probably the only benchmark that involves a "function" that *everybody* uses -- starting up the program. Sage is currently dead last, and by a lot. Python and Pari are both by far the fastest to startup, so at least it isn't Python's fault :-). LOG: wst...@sage:~$ time echo "2+2;" | sage -python real0m0.046s wst...@sage:~$ time echo "2+2;" | magma Magma V2.14-9 Wed Mar 3 2010 05:40:30 on sage [Seed = 2126205915] Type ? for help. Type -D to quit. 4 Total time: 0.570 seconds, Total memory usage: 6.94MB real0m0.971s -- wst...@sage:~$ time echo "2+2;" | maple |\^/| Maple 12 (X86 64 LINUX) ._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2008 \ MAPLE / All rights reserved. Maple is a trademark of < > Waterloo Maple Inc. | Type ? for help. > 2+2; 4 > quit memory used=0.8MB, alloc=0.7MB, time=0.01 real0m0.111s --- wst...@sage:~$ time echo "2+2;" | math Mathematica 6.0 for Linux x86 (64-bit) Copyright 1988-2007 Wolfram Research, Inc. In[1]:= In[2]:= real0m0.524s -- wst...@sage:~$ time echo "2+2;" | matlab Warning: Unable to open display , MATLAB is starting without a display. You will not be able to display graphics on the screen. Warning: MATLAB is starting without a display, using internal event queue. You will not be able to display graphics on the screen. < M A T L A B > Copyright 1984-2006 The MathWorks, Inc. Version 7.2.0.283 (R2006a) January 27, 2006 To get started, type one of these: helpwin, helpdesk, or demo. For product information, visit www.mathworks.com. >> >> real0m0.844s --- wst...@sage:~$ time echo "2+2;" | sage -maxima ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/defsystem.fas" ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/cmp.fas" ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/sysfun.lsp" Maxima 5.20.1 http://maxima.sourceforge.net using Lisp ECL 9.10.2 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) (%o1) 4 (%i2) real0m0.456s --- wst...@sage:~$ time echo "2+2;" | sage -gp GP/PARI CALCULATOR Version 2.3.3 (released) amd64 running linux (x86-64/GMP-4.2.1 kernel) 64-bit version compiled: Feb 25 2010, gcc-4.2.4 (Ubuntu 4.2.4-1ubuntu4) (readline v6.0 enabled, extended help available) Copyright (C) 2000-2006 The PARI Group PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER. Type ? for help, \q to quit. Type ?12 for how to get moral (and possibly technical) support. parisize = 800, primelimit = 50 Goodbye! real0m0.030s --- wst...@sage:~$ time echo "2+2;" | sage -- | Sage Version 4.3.3, Release Date: 2010-02-21 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: Exiting SAGE (CPU time 0m0.05s, Wall time 0m0.06s). real0m1.658s -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Randomised testing against Mathematica
Joshua Herman wrote: Is there a mathematica test suite we could adapt or a standardized set of tests we could use? Maybe we could take the 100 most often used functions and make a test suite? I'm not aware of one. A Google found very little of any real use. I'm sure Wolfram Research have such test suites internally, but they are not public. There is discussion of how they have an internal version of Mathematica which runs very slowly, but tests things in greater detail. http://reference.wolfram.com/mathematica/tutorial/TestingAndVerification.html Of course, comparing 100 things is useful, but comparing millions of them in the way I propose would more likely show up problems. I think we are all aware that it is best to test on the hardware you are using to be as confident as possible that the results are right. Of course, Wolfram Research could supply a test suite to check Mathematica on an end user's computer, but they do not do that. They could even encrypt it, so users did not know what was wrong, but could at least alert Wolfram Research. I'm aware of one bug in Mathematica that only affected old/slower SPARC machines if Solaris was updated to Solaris 10. I suspect it would have affected newer machines too, had they been heavily loaded. (If I was sufficiently motivated, I would probably prove that, but I'm not, so my hypothesis is unproven). It did not produce incorrect results, but pegged the CPU at 100% forever if you computed something as simple as 1+1.) It was amazing how that was solved between myself, Casper Dik a kernel engineer at Sun and various other people on the Internet. It was Casper who finally nailed the problem, after I posted the output of lsof, he could see what Mathematica was doing. I've got a collection of a few Mathematica bugs, mainly affecting only Solaris, although one affected at least one Linux distribution too. http://www.g8wrb.org/mathematica/ One thing I know Mathematica does do, which Sage could do, is to automatically generate bug report if it finds a problem. At the most primitive level, that code might be if (x < 0) function_less() else if (x == 0) function_equal() else if (x > 0) function_greater() else function_error() If the error is generated, a URL is given, which you click and can send a bug report to them. It lists the name of the file and line number which generated the error. That's something that could be done in Sage and might catch some bugs. Dave LOOK ITS A SIGNATURE CLICK IF YOU DARE--- http://www.google.com/profiles/zitterbewegung On Wed, Mar 3, 2010 at 12:04 AM, David Kirkby wrote: Has anyone ever considered randomised testing of Sage against Mathematica? As long as the result is either a) True or False b) An integer then comparison should be very easy. As a dead simple example, 1) Generate a large random number n. 2) Use is_prime(n) in Sage to determine if n is prime or composite. 3) Use PrimeQ[n] in Mathematica to see if n is prime or composite. 4) If Sage and Mathematica disagree, write it to a log file. Something a bit more complex. 1) Generating random equation f(x) - something that one could integrate. 2) Generate generate random upper and lower limits, 'a' and 'b' 3) Perform a numerical integration of f(x) between between 'a' and 'b' in Sage 4) Perform a numerical integration of f(x) between between 'a' and 'b' in Mathematica 5) Compare the outputs of the Sage and Mathematica A floating point number, would be more difficult to compare, as one would need to consider what is a reasonable level of difference. Comparing symbolic results directly would be a much more difficult task, and probably impossible without a huge effort, since you can often write an equation in several different ways which are equal, but a computer program could not easily be programmed to determine if they are equal. One could potentially let a computer crunch away all the time, looking for differences. Then when they are found, a human would had to investigate why the difference occurs. One could then add a trac item for "Mathematica bugs" There was once a push for a public list of Mathematica bugs. I got involved a bit with that, but it died a death and I became more interested in Sage. Some of you may know of Vladimir Bondarenko, who is a strange character who regularly used to publish Mathematica and Maple bugs he had found. In some discussions I've had with him, he was of the opinion that Wolfram Research took bug reports more seriously than Maplesoft. I've never worked out what technique he uses, but I believe is doing some randomised testing, though it is more sophisticated that what I'm suggesting above. There must be a big range of problem types where this is practical - and a much larger range where it is not. You could at the same also compare the time taken to execute the operation to find areas where Sage is much faster or slower than Mathematica. Dave -- To post to this group, send
[sage-devel] Re: Randomised testing against Mathematica
There has been some previous discussion about this on sage-devel, I can't find exactly the thread I remember but here's a somewhat related one: http://groups.google.com/group/sage-devel/browse_thread/thread/b91c51672ae0f475/ Personally I think it makes sense to put the most effort into getting sage to 100% coverage. Whenever possible when writing doctests the results should be checked. Perhaps in some test blocks it could be remarked that the result has been verified by another system. -Marshall On Mar 3, 1:54 am, Joshua Herman wrote: > Is there a mathematica test suite we could adapt or a standardized set > of tests we could use? Maybe we could take the 100 most often used > functions and make a test suite? > > LOOK ITS A SIGNATURE CLICK IF YOU > DARE---http://www.google.com/profiles/zitterbewegung > > On Wed, Mar 3, 2010 at 12:04 AM, David Kirkby wrote: > > Has anyone ever considered randomised testing of Sage against Mathematica? > > > As long as the result is either > > > a) True or False > > b) An integer > > > then comparison should be very easy. As a dead simple example, > > > 1) Generate a large random number n. > > 2) Use is_prime(n) in Sage to determine if n is prime or composite. > > 3) Use PrimeQ[n] in Mathematica to see if n is prime or composite. > > 4) If Sage and Mathematica disagree, write it to a log file. > > > Something a bit more complex. > > > 1) Generating random equation f(x) - something that one could integrate. > > 2) Generate generate random upper and lower limits, 'a' and 'b' > > 3) Perform a numerical integration of f(x) between between 'a' and 'b' in > > Sage > > 4) Perform a numerical integration of f(x) between between 'a' and 'b' > > in Mathematica > > 5) Compare the outputs of the Sage and Mathematica > > > A floating point number, would be more difficult to compare, as one > > would need to consider what is a reasonable level of difference. > > > Comparing symbolic results directly would be a much more difficult > > task, and probably impossible without a huge effort, since you can > > often write an equation in several different ways which are equal, but > > a computer program could not easily be programmed to determine if they > > are equal. > > > One could potentially let a computer crunch away all the time, looking > > for differences. Then when they are found, a human would had to > > investigate why the difference occurs. > > > One could then add a trac item for "Mathematica bugs" There was once a > > push for a public list of Mathematica bugs. I got involved a bit with > > that, but it died a death and I became more interested in Sage. > > > Some of you may know of Vladimir Bondarenko, who is a strange > > character who regularly used to publish Mathematica and Maple bugs he > > had found. In some discussions I've had with him, he was of the > > opinion that Wolfram Research took bug reports more seriously than > > Maplesoft. I've never worked out what technique he uses, but I believe > > is doing some randomised testing, though it is more sophisticated that > > what I'm suggesting above. > > > There must be a big range of problem types where this is practical - > > and a much larger range where it is not. > > > You could at the same also compare the time taken to execute the > > operation to find areas where Sage is much faster or slower than > > Mathematica. > > > Dave > > > -- > > To post to this group, send an email to sage-devel@googlegroups.com > > To unsubscribe from this group, send an email to > > sage-devel+unsubscr...@googlegroups.com > > For more options, visit this group > > athttp://groups.google.com/group/sage-devel > > URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] fractals in sage
Hi William, > I recall many years ago programming the 80387 maths coprocessor chip at the > assembly level to generate the fastest Mandlebrot set I could. If I recall > correctly, it ran at 25 MHz, which I think was the fastest any 80386/80376 > chip run at. Wow ! Advanced technology ! I recall doing it on an Apple II, 6502 1Mhz ;-) Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
