[sage-devel] Re: Problem sharing directory
On Sep 17, 2009, at 11:26 PM, Thierry Dumont wrote: > William Stein a écrit : >> 2009/9/17 Thierry Dumont : >>> Hi, >>> >>> I want to launch 2 instances of sage on the same machine, and >>> even more >>> launch sage on 2 (3) machines sharing one directory by nfs. >>> >>> My "notebook" command is: >>> notebook(open_viewer=False,directory='/ws/ >>> nbfiles',address='',secure=True,port=8001,timeout=3600,ulimit='-v >>> 5',accounts=True) >> >> You have to give *different* directory= options for the two servers. >> >> William > > Ok, but it should be possible to share the "worksheet" directory ? > I *need* to share it (we have 3 machines, on which the users -some > hundreds of students- will be connected at random). I don't think that would be possible. What you could do is use the "server pool" option to use ssh accounts on all three machines to share the actual computation load, while the notebook frontend would run on just one machine. This fall the notebook will be made much more scalable. - Robert --~--~-~--~~~---~--~~ 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: Problem sharing directory
William Stein a écrit : > 2009/9/17 Thierry Dumont : >> Hi, >> >> I want to launch 2 instances of sage on the same machine, and even more >> launch sage on 2 (3) machines sharing one directory by nfs. >> >> My "notebook" command is: >> >> notebook(open_viewer=False,directory='/ws/nbfiles',address='',secure=True,port=8001,timeout=3600,ulimit='-v >> 5',accounts=True) > > You have to give *different* directory= options for the two servers. > > William Ok, but it should be possible to share the "worksheet" directory ? I *need* to share it (we have 3 machines, on which the users -some hundreds of students- will be connected at random). Thanks! t.d. > > --~--~-~--~~~---~--~~ > 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 > -~--~~~~--~~--~--~--- > <> smime.p7s Description: S/MIME Cryptographic Signature
[sage-devel] Re: round(), floor() and ceil() on interval objects
On Sep 17, 2009, at 10:44 PM, Robert Bradshaw wrote: > On Sep 17, 2009, at 3:16 PM, David Harvey wrote: > >> I disagree with this change. One of the main purposes of interval >> arithmetic is to be able to take a function f(x) that operates on >> floats, and pass in intervals instead, to determine the possible >> range >> of outputs a given input interval could produce. This change violates >> that paradigm. The author of f(x) shouldn't need to care whether they >> are operating on floats or intervals. > > +1. The smallest possible value for floor is a different thing (and > contains less information) than all possible values of floor, and > "all possible values" characterizes the interval arithmetic > operations. Example: sage: floor(log(RIF(8)) / log(RIF(2))) 3.? Should this be 2? What if it returned an Integer if there was a unique floor (ceiling, etc.) and raised an exception otherwise? - Robert --~--~-~--~~~---~--~~ 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: New interact sliders
Wouldn't be better if there was some sort of triangular end which points to the exact thick (when they are plotted)? Without them, the slider look a bit "approximate" or "inexact" :) On Sep 18, 6:14 am, William Stein wrote: > On Thu, Sep 17, 2009 at 8:39 PM, Pat LeSmithe wrote: > > I've attached a snapshot of the default sliders provided by the new > > jQuery UI spkg, available at > > >http://trac.sagemath.org/sage_trac/ticket/5447 > > > (An active slider is orange.) Also attached: Shots of custom sliders > > with thin and thinner handles. Which, if any, do you prefer? > > I think I personally prefer the middle one. > > William > > > > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://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: round(), floor() and ceil() on interval objects
On Sep 17, 2009, at 3:16 PM, David Harvey wrote: > I disagree with this change. One of the main purposes of interval > arithmetic is to be able to take a function f(x) that operates on > floats, and pass in intervals instead, to determine the possible range > of outputs a given input interval could produce. This change violates > that paradigm. The author of f(x) shouldn't need to care whether they > are operating on floats or intervals. +1. The smallest possible value for floor is a different thing (and contains less information) than all possible values of floor, and "all possible values" characterizes the interval arithmetic operations. > On Sep 17, 3:53 am, Jason Grout wrote: >> Currently, round(), floor(), and ceil() on interval objects return >> intervals. >> >> There is a patch up at #2899 that changes these functions to return >> integers (round-> "round the midpoint", floor -> largest integer >> below >> the bottom of the interval, etc.). I think the reasoning is that >> round(), floor, ceil, etc. should always return integers. >> >> What do people think? Should we close the ticket, or should we merge >> the patch (after possible rebasing). >> >> To illustrate: >> >> Currently: >> >> sage: R = RealIntervalField(100) >> sage: a = R(9.5, 11.3); a.str(style='brackets') >> '[9.500 .. >> 11.300710542735760101]' >> sage: floor(a).str(style='brackets') >> '[9.000 .. >> 11.00]' >> >> Proposed: >> >> sage: floor(a) >> 9 >> >> Thanks, >> >> Jason >> >> -- >> 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 -~--~~~~--~~--~--~---
[sage-devel] Re: New interact sliders
On Thu, Sep 17, 2009 at 8:39 PM, Pat LeSmithe wrote: > I've attached a snapshot of the default sliders provided by the new > jQuery UI spkg, available at > > http://trac.sagemath.org/sage_trac/ticket/5447 > > (An active slider is orange.) Also attached: Shots of custom sliders > with thin and thinner handles. Which, if any, do you prefer? I think I personally prefer the middle one. 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 -~--~~~~--~~--~--~---
[sage-devel] New interact sliders
I've attached a snapshot of the default sliders provided by the new jQuery UI spkg, available at http://trac.sagemath.org/sage_trac/ticket/5447 (An active slider is orange.) Also attached: Shots of custom sliders with thin and thinner handles. Which, if any, do you prefer? --~--~-~--~~~---~--~~ 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] Problem in upgrading sage
Hello! I have just been trying to upgrade sage-combinat (on a macbook pro running 10.6.1 of macosx) with sage -combinat upgrade and run into a problem because as part of the SQLAlchemy upgrade sage wants to download http://cheeseshop.python.org/packages/2.6/s/setuptools/setuptools-0.6c3-py2.6.egg and this file does not to exist. A correct URL to use is http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg but I have not found a way to make sage use this URL or to use the egg that I have downloaded directly. Is there a way for me to fix this? Cheers, Andrew --~--~-~--~~~---~--~~ 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: Need a very simple review !
On Fri, Sep 18, 2009 at 7:35 AM, Minh Nguyen wrote: > It turns out that Sage has been shipping two versions of libgcrypt > within one spkg; see > > http://groups.google.com/group/sage-devel/browse_thread/thread/def1225d7946587e > > Your patches for the libgcrypt spkg is for version 1.4.0, not 1.4.3 as > you intended. An updated spkg is up at ticket #6758 http://trac.sagemath.org/sage_trac/ticket/6758 which actually uses the libgcrypt 1.4.3 source code. -- 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: Problem sharing directory
2009/9/17 Thierry Dumont : > Hi, > > I want to launch 2 instances of sage on the same machine, and even more > launch sage on 2 (3) machines sharing one directory by nfs. > > My "notebook" command is: > notebook(open_viewer=False,directory='/ws/nbfiles',address='',secure=True,port=8001,timeout=3600,ulimit='-v > 5',accounts=True) You have to give *different* directory= options for the two servers. 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: macaulay2-1.1-r7221.p0.spkg fails to build on mac os x
2009/9/17 at : > > I get the following error message while trying to install the > macaulay2 experimental package on Mac OS X > > sage: An error occurred while installing macaulay2-1.1-r7221.p0 > > This seems to be the problem: > > configure: error: automatic building of libraries disabled, but some > must be built > > and it appears to be coming from the M2 configure script. > > Host system (I am running Mac OS X Leopard) > uname -a: > Darwin ATs-MacBook-3.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul > 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 > > Any suggestions? Get Macaulay2 from the Macaulay2 website: http://www.math.uiuc.edu/Macaulay2/ It should work just as well with Sage. Just make sure that the M2 program is in your PATH. 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] testing cliquer on Linux and Solaris
Hi folks, An updated cliquer spkg is up at ticket #6681. So far it has been tested on Mac OS X 10.5 by John Palmieri, both in 32- and 64-bit mode. Can someone please test the updated cliquer package on various Linux platforms and on SPARC Solaris? (I have tested on sage.math, bsd.math, t2.math, the openSUSE virtualized guests on boxen.math, and various Linux machines on SkyNet... but I made the update so my tests don't count :-) -- 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: round(), floor() and ceil() on interval objects
I disagree with this change. One of the main purposes of interval arithmetic is to be able to take a function f(x) that operates on floats, and pass in intervals instead, to determine the possible range of outputs a given input interval could produce. This change violates that paradigm. The author of f(x) shouldn't need to care whether they are operating on floats or intervals. david On Sep 17, 3:53 am, Jason Grout wrote: > Currently, round(), floor(), and ceil() on interval objects return > intervals. > > There is a patch up at #2899 that changes these functions to return > integers (round-> "round the midpoint", floor -> largest integer below > the bottom of the interval, etc.). I think the reasoning is that > round(), floor, ceil, etc. should always return integers. > > What do people think? Should we close the ticket, or should we merge > the patch (after possible rebasing). > > To illustrate: > > Currently: > > sage: R = RealIntervalField(100) > sage: a = R(9.5, 11.3); a.str(style='brackets') > '[9.500 .. 11.300710542735760101]' > sage: floor(a).str(style='brackets') > '[9.000 .. 11.00]' > > Proposed: > > sage: floor(a) > 9 > > Thanks, > > Jason > > -- > 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Need a very simple review !
Hi David, On Thu, Aug 27, 2009 at 7:58 AM, Dr. David Kirkby wrote: > Once the fix is implemented, libgcrypt will build with either the Sun or > GNU compilers. It turns out that Sage has been shipping two versions of libgcrypt within one spkg; see http://groups.google.com/group/sage-devel/browse_thread/thread/def1225d7946587e Your patches for the libgcrypt spkg is for version 1.4.0, not 1.4.3 as you intended. -- 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: Starting R in Sage Chroot
Hi Kay, On Fri, Sep 18, 2009 at 2:49 AM, Kay Wanous wrote: > Any ideas? This might not be of any help at all but... If you want to limit the damage that could be done on your system, you might consider virtualization tools such as VirtualBox OSE, VMware, etc. instead of using chroot. I have used Sage running within virtualized Linux guests using VirtualBox OSE and VMware. So far I'm quite happy with both of these for testing Sage, and haven't run across the problem you reported above. -- 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: Behavior of solve
Sorry that I misunderstood the purpose of the question. But I would like to re-make one of my points. sage: solve(x^5+x^3+17*x+1,x) [x == -0.0588115172555, x == (-1.33109991788 + 1.52241655184*I), x == (-1.33109991788 - 1.52241655184*I), x == (1.36050567904 + 1.5188087221*I), x == (1.36050567904 - 1.5188087221*I)] sage: solve([x^5+x^3+17*x+1],x) [0 == x^5 + x^3 + 17*x + 1] Should the behaviour really be different for these two calls to solve ()? Don't misunderstand me: I don't mean "can it be explained as a Maxima quirk", I mean "is it this the behaviour intended by the SAGE design team?" Dirk --~--~-~--~~~---~--~~ 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: Standard Sage Components (was Re: Solaris - what do we expect?)
Michelle Callaghan - Sun Microsystems wrote: > Sorry for crashing your thread, but I was just searching around to see > if anyone was running Sage on Solaris and I came upon your dicussions, > I just wondered if there is a specific customer requirement that you > know of for Sage on Sun as we would love to work with Sage, if there > is a need for this. > > If there is anything I can do to help let me know and I will see what > I can do. It would be interesting and perhaps very useful to hear from the Project Fortress team about the prospects for high-performance computing (HPC) with Sage. Fortress is actually a new programming language, distinct from Python: http://projectfortress.sun.com/Projects/Community http://research.sun.com/projects/plrg/Publications/ It has at least one goal I think the Sage community would appreciate, namely, that programs should have a mathematical representation: http://projectfortress.sun.com/Projects/Community/wiki/MathSyntaxInFortress Implicit parallelism is also appealing. Does Fortress have a foreign function interface? Disclaimer: I'm not familiar with Fortress. I just discovered it recently, during a digression. --~--~-~--~~~---~--~~ 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] macaulay2-1.1-r7221.p0.spkg fails to build on mac os x
I get the following error message while trying to install the macaulay2 experimental package on Mac OS X sage: An error occurred while installing macaulay2-1.1-r7221.p0 This seems to be the problem: configure: error: automatic building of libraries disabled, but some must be built and it appears to be coming from the M2 configure script. Host system (I am running Mac OS X Leopard) uname -a: Darwin ATs-MacBook-3.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 Any suggestions? Alvise --~--~-~--~~~---~--~~ 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: is Sage using libgcrypt 1.4.3 or 1.4.0?
2009/9/17 Minh Nguyen : > > Hi folks, > > Since Sage version 3.3, Sage has been shipping two versions of > libgcrypt: 1.4.0 and 1.4.3 (both of which are under LGPL v2.1). These > two different versions are contained in one spkg, i.e. the > libgcrypt-1.4.3 spkg. After uncompressing the libgcrypt spkg, the > source of version 1.4.0 is found under the src/ directory, while > version 1.4.3 is under src/libgcrypt-1.4.3/. From the file > spkg-install, only version 1.4.0 is built. Is this a case of a messed > up package or I'm missing something? I don't mean to be rude here; I'm > just curious why the libgcrypt spkg contains two different versions of > libgcrypt. I'm sure that's a messed up package. Good job spotting this. William > > -- > Regards > Minh Van Nguyen > > > > -- 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: Errors in gnuplotpy-1.7.p3
Hi, On Fri, Sep 18, 2009 at 4:20 AM, RProgrammer wrote: > I tried emailing the install.log file and the terminal output, but > Google Groups wouldn't let my message pass: Any chance you could upload the (compressed) install.log file somewhere on the web and post a link? Or you could email the relevant section about failure to install gnuplotpy. -- 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] Errors in gnuplotpy-1.7.p3
I tried to install gnuplotpy-1.7.p3, but failed. In failing, sage told me to contact this group and include the relevant portion of install.log. I tried emailing the install.log file and the terminal output, but Google Groups wouldn't let my message pass: We're writing to let you know that the group that you tried to contact (sage-devel) either doesn't exist, or you don't have permission to post to it. Please be sure to include 'gnuplotpy' somewhere in the message so it will trigger my Google Alert (hopefully); thie group moves too fast for me to follow the whole thing. --~--~-~--~~~---~--~~ 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: Starting R in Sage Chroot
I think I've narrowed it down a little bit more. Inside the chroot,
root can run sage with R without errors. Looking at a diff of the
straces, when root runs sage, it opens /usr/lib/locale/locale-archive
but it doesn't if it's run as the sage user:
Root -
brk(0) = 0xcaad000
brk(0xcace000) = 0xcace000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=56406016, ...}) = 0
mmap(NULL, 56406016, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b40de7c6000
close(3)= 0
execve("/usr/kerberos/sbin/bash", ["bash", "/home/sage/sage", "-c",
"r.version()"], [/* 23 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/kerberos/bin/bash", ["bash", "/home/sage/sage", "-c",
"r.version()"], [/* 23 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/sbin/bash", ["bash", "/home/sage/sage", "-c",
"r.version()"], [/* 23 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/bash", ["bash", "/home/sage/sage", "-c",
"r.version()"], [/* 23 vars */]) = -1 ENOENT (No such file or directory)
execve("/sbin/bash", ["bash", "/home/sage/sage", "-c", "r.version()"],
[/* 23 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/bash", ["bash", "/home/sage/sage", "-c", "r.version()"],
[/* 23 vars */]) = 0
brk(0) = 0xbf4d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b47bb169000
Sage -
brk(0) = 0x5955000
brk(0x5976000) = 0x5976000
execve("/usr/local/bin/bash", ["bash", "./sage", "-t",
"devel/sage/sage/interfaces/expec"...], [/* 16 vars */]) = -1 ENOENT (No
such file or directory)
execve("/bin/bash", ["bash", "./sage", "-t",
"devel/sage/sage/interfaces/expec"...], [/* 16 vars */]) = 0
brk(0) = 0x110d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b38ae1e7000
Any ideas?
Thanks,
Kay
Kay wrote:
> Hi all,
>
> First, thanks for all your hard work in these wonderful project! The
> folks at my institution are just in love with it.
>
> I'm trying to set up a notebook server in a chroot for them. The
> chroot, notebook, etc. seem to be working fine except for R. These
> are the tests that fail:
>
> sage -t "devel/sage/sage/interfaces/expect.py"
> sage -t "devel/sage/sage/interfaces/r.py"
> sage -t "devel/sage/sage/quadratic_forms/
> quadratic_form__equivalence_testing.py"
> sage -t "devel/sage/sage/stats/test.py"
> sage -t "devel/sage/sage/stats/r.py
>
> I have a compilation on the same machine outside the chroot, and it
> works fine. Errors logs are below. Any suggestions would be
> appreciated!
>
> Thanks,
> Kay
>
>
>
> sage: r.version()
> ---
> RuntimeError Traceback (most recent call
> last)
>
> /home/sage/.sage/temp/bs0.bobsced.loc/27767/
> _home_sage__sage_init_sage_0.py in ()
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
> version(self)
> 525 version_string_re = re.compile('^version.string\s*
> (R.*?)$', re.M)
> 526
> --> 527 s = self.eval('version')
> 528
> 529 major = int( major_re.findall(s)[0].strip() )
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
> eval(self, code, globals, locals, synchronize, *args, **kwds)
> 974 # TODO split code at ";" outside of quotes and send
> them as individual
> 975 # lines without ";".
> --> 976 return Expect.eval(self, code,
> synchronize=synchronize, *args, **kwds)
> 977
> 978 def _r_to_sage_name(self, s):
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/
> expect.pyc in eval(self, code, strip, synchronize, locals, **kwds)
> 978 try:
> 979 with gc_disabled():
> --> 980 return '\n'.join([self._eval_line(L, **kwds)
> for L in code.split('\n') if L != ''])
> 981 except KeyboardInterrupt:
> 982 # DO NOT CATCH KeyboardInterrupt, as it is being
> caught
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/
> expect.pyc in _eval_line(self, line, allow_use_file, wait_for_prompt)
> 632 try:
> 633 if self._expect is None:
> --> 634 self._start()
> 635 E = self._expect
> 636 try:
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
> _start(self)
> 302 sage: r._start()
> 303 """
> --> 304 Expect._start(self)
> 305
> 306 # width is line width, what's a good value? maximum is
> 1!
>
> /home/sage/local/lib/python2.6/site-packages/sage/interfaces/
> expect.pyc in _start(self, alt_message,
[sage-devel] Re: Behavior of solve
> > Great idea. We can make an alias: > > solve_numerical=find_root > Yes, that would be a great idea. I can make that part of #6642. > Does find_root take general symbolic expressions (i.e., x==x^2)? > Yes, but it has different syntax than the other solves - namely, you must specify an interval ahead of time. That being said, you can specify the interval to be -infinity to infinity, but that will not always do so well! For instance, the example you give fails to converge on that interval, while it does on the interval -10 to 10 (on -100 to 100, it gets close to 1.0 but not quite there). - kcrisman --~--~-~--~~~---~--~~ 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: round(), floor() and ceil() on interval objects
On 17-Sep-09, at 12:53 AM, Jason Grout wrote: > > Currently, round(), floor(), and ceil() on interval objects return > intervals. > > There is a patch up at #2899 that changes these functions to return > integers (round-> "round the midpoint", floor -> largest integer below > the bottom of the interval, etc.). I think the reasoning is that > round(), floor, ceil, etc. should always return integers. I think I did all the work on that ticket, and yes, that was my reasoning. Nick --~--~-~--~~~---~--~~ 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: Statistics in Sage
Jason Grout wrote: > Carlo Hamalainen wrote: >> On Thu, Sep 17, 2009 at 6:48 AM, Robert Dodier >> wrote: >>> Some random comments on >>> http://trac.sagemath.org/sage_trac/attachment/ticket/6827/probability_distribution.patch >> Between that and the better performance of scipy (see my other email >> in this thread) I figure we should probably throw away >> probability_distribution.pyx and use the scipy stuff, at least for >> generating gaussians and so on. >> >> What do other people think? >> > > To paraphrase William when he was doing hidden markov models, I would > rather spend a week writing a good wrapper/interface for a library > someone else is maintaining, than spend a month reimplementing standard > functionality that I have to maintain myself. In this case, since you are deciding between wrapping GSL or wrapping scipy or R, I think it would make a lot more sense to wrap R, given that the speed of rpy2 and your implementation above are about the same. We can special-case things like William's code or the scipy code to make things faster. But for now, if we are trying to get a base of functionality, it seems like wrapping R is the best way to go. Everything else is a subset of the functionality in R. Thanks, Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: General question on the kind of things we want in Sage
Rob Beezer wrote: > On Sep 17, 8:00 am, Nathann Cohen wrote: >> Could it be good for sage to I do not know, perhaps become some kind of >> library of published algorithms ? Should we be thinking about ways to let >> used find "the algorithm described in paper XXX for journal XXX number XX >> pages XX-XX" ? > > More than just a library of implementations of algorithms, I like the > idea of Sage as a repository of mathematical knowledge. For example, > docstrings can contain citations to articles or monographs. Sometimes > doctests can be based on theorems - create some object randomly, then > test if two seemingly unrelated computations are equal, as guaranteed > according to a theorem. Having two algorithms implemented for > something, and then a discussion of cases when one is superior, or > even hard-coding the choice is another piece of knowledge embedded in > Sage. Having docstrings close to the code, being open source, and > making docstrings and source code so easy to access, makes it easy to > explain, accumulate and organize a wealth of mathematical knowledge as > a side-effect, and I think this is another big advantage to an open > source approach to this class of software. > > I know I've learned lots of mathematics that is new to me since > becoming involved, and in my contributions I've tried when possible to > reflect the above philosophy. I should add that Tim Daly takes this a step further and has all of the Axiom documentation actually be books about mathematics, a "true" repository of information, in volume form. Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: General question on the kind of things we want in Sage
Hi Nathann, On Sep 17, 4:00 pm, Nathann Cohen wrote: [...] > These may be questions to ask in several years... No, that's clearly wrong: Those are questions that should (actually "must"!) be addressed before implementing any details. By the way, as Rob and Minh pointed out, documentation helps a lot, and (if it helps to convince you...) new code in Sage *must* be fully covered by documentation *including* tests. I think nobody here would give a positive review on anything that is not properly documented. Cheers, Simon --~--~-~--~~~---~--~~ 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: Behavior of solve
Maurizio wrote: > My 2 cents here: > why do we keep the "numerical solve" function with a completely > different name? I know that "find_root" or "roots" make sense, but > wouldn't just be much better to name them "solve_numerical", or > anything like putting a postfix after the word "solve"? > I don't know whether this is generally a good thing to do, but I just > keep finding it so easy if I do "solve[Tab]" so that ALL the functions > related to solving equations are shown (both exact and numerical) Great idea. We can make an alias: solve_numerical=find_root Does find_root take general symbolic expressions (i.e., x==x^2)? Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Starting R in Sage Chroot
Hi all,
First, thanks for all your hard work in these wonderful project! The
folks at my institution are just in love with it.
I'm trying to set up a notebook server in a chroot for them. The
chroot, notebook, etc. seem to be working fine except for R. These
are the tests that fail:
sage -t "devel/sage/sage/interfaces/expect.py"
sage -t "devel/sage/sage/interfaces/r.py"
sage -t "devel/sage/sage/quadratic_forms/
quadratic_form__equivalence_testing.py"
sage -t "devel/sage/sage/stats/test.py"
sage -t "devel/sage/sage/stats/r.py
I have a compilation on the same machine outside the chroot, and it
works fine. Errors logs are below. Any suggestions would be
appreciated!
Thanks,
Kay
sage: r.version()
---
RuntimeError Traceback (most recent call
last)
/home/sage/.sage/temp/bs0.bobsced.loc/27767/
_home_sage__sage_init_sage_0.py in ()
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
version(self)
525 version_string_re = re.compile('^version.string\s*
(R.*?)$', re.M)
526
--> 527 s = self.eval('version')
528
529 major = int( major_re.findall(s)[0].strip() )
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
eval(self, code, globals, locals, synchronize, *args, **kwds)
974 # TODO split code at ";" outside of quotes and send
them as individual
975 # lines without ";".
--> 976 return Expect.eval(self, code,
synchronize=synchronize, *args, **kwds)
977
978 def _r_to_sage_name(self, s):
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/
expect.pyc in eval(self, code, strip, synchronize, locals, **kwds)
978 try:
979 with gc_disabled():
--> 980 return '\n'.join([self._eval_line(L, **kwds)
for L in code.split('\n') if L != ''])
981 except KeyboardInterrupt:
982 # DO NOT CATCH KeyboardInterrupt, as it is being
caught
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/
expect.pyc in _eval_line(self, line, allow_use_file, wait_for_prompt)
632 try:
633 if self._expect is None:
--> 634 self._start()
635 E = self._expect
636 try:
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/r.pyc in
_start(self)
302 sage: r._start()
303 """
--> 304 Expect._start(self)
305
306 # width is line width, what's a good value? maximum is
1!
/home/sage/local/lib/python2.6/site-packages/sage/interfaces/
expect.pyc in _start(self, alt_message, block_during_init)
467 self._session_number = BAD_SESSION
468 failed_to_start.append(self.__name)
--> 469 raise RuntimeError, "Unable to start
%s"%self.__name
470 self._expect.timeout = None
471 with gc_disabled():
RuntimeError: Unable to start r
sage -t "devel/sage/sage/interfaces/expect.py"
**
File "/home/sage/devel/sage/sage/interfaces/expect.py", line 766:
sage: r._sendstr('abc <- 10 +15;\n')
Exception raised:
Traceback (most recent call last):
File "/home/sage/local/bin/ncadoctest.py", line 1231, in
run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/sage/local/bin/sagedoctest.py", line 38, in
run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/home/sage/local/bin/ncadoctest.py", line 1172, in
run_one_example
compileflags, 1) in test.globs
File "", line 1, in
r._sendstr('abc <- 10 +15;\n')###line 766:
sage: r._sendstr('abc <- 10 +15;\n')
File "/home/sage/local/lib/python/site-packages/sage/interfaces/
expect.py", line 866, in _sendstr
self._start()
File "/home/sage/local/lib/python/site-packages/sage/interfaces/
r.py", line 304, in _start
Expect._start(self)
File "/home/sage/local/lib/python/site-packages/sage/interfaces/
expect.py", line 469, in _start
raise RuntimeError, "Unable to start %s"%self.__name
RuntimeError: Unable to start r
**
File "/home/sage/devel/sage/sage/interfaces/expect.py", line 781:
sage: w = walltime(t); w > 0.4 and w < 10
Expected:
True
Got:
False
**
File "/home/sage/devel/sage/sage/interfaces/expect.py", line 788:
sage: r._sendstr('abc;\n')
Exception raised:
Traceback (most recent call last):
File "/home/sage/local/bin/ncadoctest.py", line 1231, in
run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/sage/local/bin/sagedoctest
[sage-devel] Re: General question on the kind of things we want in Sage
Nathann Cohen wrote: > Hello !!! > > I was just wondering about the kind of algorithms we want in Sage. For > example, if someone in my lab finds out a brand new algorithm to compute > a brand-new invariant for a pretty restrictive ( but brand-new, too ) > class of graphs, do we want to have it included in Sage ? Yes! It would probably take, say, 300K of code to make Sage the expert in what you need it to do? That's a no-brainer---do it! In fact, we also encourage people to submit books they are writing to be included in Sage, so that we have an entire book's worth of code as doctests. In the next few months, I am going to submit a file of functions to calculate the minimum rank of a graph. Probably less than 100 people in the world work on this, but once Sage has it, Sage will be the defacto software for working with minimum rank. That will be very, very nice. > My answer, for the moment, is no... I was thinking we only wanted to see > in Sage things that may be useful to everybody, and let people write > their own functions, but... Suppose someone, "John", submits his special function to Sage. It takes up about 10K worth of space. Well, now John's code is guaranteed to work with future versions of Sage (his doctests *must* pass before a new release), at least as long as someone is willing to tweak it to port it to new versions. Also, now John knows how to submit things and knows how to review patches. So next time he needs something done, he's more likely to do it himself and submit a patch. We *need* developers and reviewers. You know that. I think 10K of code that maybe only he uses for the time being is well worth getting another person capable of developing and reviewing patches. Besides, you said it was a lab? It sounds like the code is valuable to more than just one person. That said, I would also pay attention to what Minh said, and organize things. That's the only reason the minimum rank code isn't submitted to Sage already---I haven't sat down and organized it as much as it should be. > The thing is that I am tempted ( for the Graph class ) to write many > functions I find useful, but these functions would very quickly crowd > the list of Graph methods... For example I am interested in computing > orientations of graphs, and there may be many functions needed... For > example, how could I include 10 or 20 functions dealing with one > particular problem of graphs without quickly transforming this already > quite crowded class in something impossible to browse ? That's a question of organization. Sage is largely developed by people "scratching their own itch", making the software the best possible for the work they are doing. Thanks again for all of the work you are doing. Your flurry of patches is part of the reason we are having a Review day next Tuesday! Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Standard Sage Components (was Re: Solaris - what do we expect?)
On Mon, Sep 14, 2009 at 10:29 AM, William Stein wrote: >> So what would your thoughts be, if someone one to propose package X is >> added, despite the fact it will not build on all of the following? >> >> 1) Build as 32-bit gcc on SPARC >> 2) Build as 64-bit gcc on SPARC >> 3) Build as 32-bit with Sun's compiler on SPARC >> 4) Build as 64-bit with Sun's compiler on SPARC >> >> 5) Build as 32-bit gcc on x64 >> 6) Build as 64-bit gcc on x64 >> 7) Build as 32-bit with Sun's compiler on x86 >> 8) Build as 64-bit with Sun's compiler on x64 Working on platforms with GCC installed means that I don't need to first compile GCC myself. I have had relatively little trouble with doing porting work and testing on sage.math, bsd.math, virtualized Linux guests on boxen.math, t2.math using GCC, and various Fedora, Red Hat and SUSE machines on SkyNet. The trouble comes in when I want to test or do porting work on a SPARC machine with Solaris and Sun's compiler. At the moment, t2.math is equipped with both GCC and Sun compiler. I can set GCC as the default compiler with these export lines by David Kirkby: export PATH=/usr/local/gcc-4.4.1-sun-linker/bin:/usr/local/bin2:/usr/bin:/usr/ccs/bin:/usr/local/bin:/usr/sfw/bin:/bin:/usr/sbin export LD_LIBRARY_PATH=/usr/local/gcc-4.4.1-sun-linker/lib:/usr/local/lib export SAGE_FORTRAN=/usr/local/gcc-4.4.1-sun-linker/bin/gfortran export SAGE_FORTRAN_LIB=/usr/local/gcc-4.4.1-sun-linker/lib/libgfortran.so If I also want to do testing or porting with the Sun compiler on t2.math, are there equivalent export commands I can use? Of course it would be nice to have a box with just the Sun compiler, linker and library paths all setup whenever one login, and another box with GNU equivalent. In the absense of that, switching between compilers, linkers and library paths on the same box can be confusing. > The last two packages that we added to Sage -- cliquer and ratpoints > -- both caused a lot of trouble. The building problem with cliquer is pretty much solved I think. As for ratpoint, the issue is that it should build OK with GCC 3.4.x. Is there a machine somewhere with GCC 3.4.x that I can use to have a shot at this problem? -- 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: Behavior of solve
My 2 cents here: why do we keep the "numerical solve" function with a completely different name? I know that "find_root" or "roots" make sense, but wouldn't just be much better to name them "solve_numerical", or anything like putting a postfix after the word "solve"? I don't know whether this is generally a good thing to do, but I just keep finding it so easy if I do "solve[Tab]" so that ALL the functions related to solving equations are shown (both exact and numerical) cheers maurizio On Sep 17, 4:52 pm, Burcin Erocal wrote: > Hi, > > I don't use the solve() function at all. I'm probably missing the > user's point of view completely, so please take what I say below with a > grain of salt. > > Going by the "What Would Maple Do" rule, I would like solve() to remain > exact. Looking through the examples here > > http://www.maplesoft.com/support/help/view.aspx?path=examples/solve > > I couldn't see any cases where Maple switches to numeric results. > > I think it's better to return no results if the exact methods don't > work, and point the user to the numeric solver. This is fsolve [1] in > the case of Maple. Is it find_root() in Sage? > > [1]http://www.maplesoft.com/support/help/view.aspx?path=fsolve > > On Thu, 17 Sep 2009 06:30:19 -0700 (PDT) > > kcrisman wrote: > > > For a frustrated user because of precisely this issue, see > >http://groups.google.com/group/sage-support/browse_thread/thread/6407... > > . I now think we should definitely change to having to_poly_solve as > > an option, but not default, even if we miss some solutions that way, > > because it's unlikely that Maxima will be able to change its behavior > > very soon, even if they wanted to. > > In this case, I agree that we should make to_poly_solve a non-default > option. > > Thanks. > > Burcin --~--~-~--~~~---~--~~ 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: General question on the kind of things we want in Sage
Hi Nathann, On Fri, Sep 18, 2009 at 1:00 AM, Nathann Cohen wrote: > The thing is that I am tempted ( for the Graph class ) to write many > functions I find useful, but these functions would very quickly crowd the > list of Graph methods... For example I am interested in computing > orientations of graphs, and there may be many functions needed... For > example, how could I include 10 or 20 functions dealing with one particular > problem of graphs without quickly transforming this already quite crowded > class in something impossible to browse ? Spending some time to think about design issues would help you in organizing your functions, methods, and classes. Before start coding, I would spend hours or a few days designing my function, method, or class. This process would include: * A meaningful name for the function, method, or class. * Document what that function, method or class does. This should include references to published work where appropriate. Remember that in a few weeks or months, you would likely forget what your code does. But people would still want to maintain your code. You code and write documentation in order to minimize the learning curve of people who would need to use your code, expand on it, or debug it. * Give a high level explanation of the algorithm you're using, not just the reference where one can read up on the algorithm. * Clearly explain both the input and output. * Write pseudo code to get a feel for the structure of the function, method or class. With proper designing, the name of your module (if you're going to write a separate module on some area of graph theory) would give an indication of its content. If you think that the graph theory functions you will implement would be within a narrow area of graph theory, you might want to consider making them into a separate module. Or better yet, figure out if you can organize those 10 to 20 functions into a number of modules, and put all of those specialized modules within a subdirectory. For example, when I first started on expanding the crypto stuff, I wanted to implemented a number of block functions. Man, there are dozens of them around these days. So I created a subdirectory under crypto called "block_cipher". I then implemented various block ciphers in different modules, organizing them under "sage/crypto/block_cipher". If people want to use those block ciphers, they can import them. > These may be questions to ask in several years... But Sage is growing pretty > quickly, though O_o A problem with open source software projects like Sage is a lack of reviewer time. There are about 100 tickets at the moment needing review, but people who are interested in getting them in don't have time to spare or don't have the necessary maths background to properly review. The upcoming review day next week should cut down on the number of tickets needing review. Small changes (a few new functions per ticket) are usually easier to review than big changes (a few new modules per ticket). In any case, feel free to ask more questions if you want clarification. Or am I missing the point you want to make? -- 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] Differential geometry
Hello developers, Is there a Differential geometry module in Sage? From what I can gather, Sage seems lacking in this area. Are there any plans or candidate packages for this area? Regards, Hazem --~--~-~--~~~---~--~~ 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: General question on the kind of things we want in Sage
On Sep 17, 8:00 am, Nathann Cohen wrote: > Could it be good for sage to I do not know, perhaps become some kind of > library of published algorithms ? Should we be thinking about ways to let > used find "the algorithm described in paper XXX for journal XXX number XX > pages XX-XX" ? More than just a library of implementations of algorithms, I like the idea of Sage as a repository of mathematical knowledge. For example, docstrings can contain citations to articles or monographs. Sometimes doctests can be based on theorems - create some object randomly, then test if two seemingly unrelated computations are equal, as guaranteed according to a theorem. Having two algorithms implemented for something, and then a discussion of cases when one is superior, or even hard-coding the choice is another piece of knowledge embedded in Sage. Having docstrings close to the code, being open source, and making docstrings and source code so easy to access, makes it easy to explain, accumulate and organize a wealth of mathematical knowledge as a side-effect, and I think this is another big advantage to an open source approach to this class of software. I know I've learned lots of mathematics that is new to me since becoming involved, and in my contributions I've tried when possible to reflect the above philosophy. Rob --~--~-~--~~~---~--~~ 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: Standard Sage Components (was Re: Solaris - what do we expect?)
Hi Guys, Sorry for crashing your thread, but I was just searching around to see if anyone was running Sage on Solaris and I came upon your dicussions, I just wondered if there is a specific customer requirement that you know of for Sage on Sun as we would love to work with Sage, if there is a need for this. If there is anything I can do to help let me know and I will see what I can do. Cheers Michelle On Sep 14, 1:29 am, William Stein wrote: > On Sun, Sep 13, 2009 at 5:16 PM, Dr. David Kirkby > > > > wrote: > >> If the spkg fixes this problem and doesn't make things *worse* on > >>Solaris, it absolutely should get a positive review. Note that the > >> assuming "CC=gcc" was already in the original cliquer spkg. It is not > >> something added by that ticket. > > > Fair enough. > > > In fact, cliquer presents problems onSolaristoo. See the ticket I > > created a couple of weeks ago. > > >http://sagetrac.org/sage_trac/ticket/6852 > > > "cliquer-1.2 fails to build as it cant find Sun compiler (SCons issue)" > > >> If we were discussing including cliquer in the first place, I might > >> have a different opinion. > > > So what would your thoughts be, if someone one to propose package X is > > added, despite the fact it will not build on all of the following? > > > 1) Build as 32-bit gcc on SPARC > > 2) Build as 64-bit gcc on SPARC > > 3) Build as 32-bit with Sun's compiler on SPARC > > 4) Build as 64-bit with Sun's compiler on SPARC > > > 5) Build as 32-bit gcc on x64 > > 6) Build as 64-bit gcc on x64 > > 7) Build as 32-bit with Sun's compiler on x86 > > 8) Build as 64-bit with Sun's compiler on x64 > > I'm pretty much by default against adding any new standard packages to > Sage anytime soon. I can't think of anything even on the horizon. > Maybe some sort of linear programming code is being proposed. Can > anybody else think of anything? > > The last two packages that we added to Sage -- cliquer and ratpoints > -- both caused a lot of trouble. I will be much more careful in the > future about adding spkg's. > > -- 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: Checking new code with an entire database (isogenies)
Hey Jenny, I thought I could chip in. On Sep 17, 8:28 pm, "J. Cooley" wrote: > Hi William, > > Thank you for all the information. I have spent time this morning > going through it all, the alarm thing is really useful ~ I also > discovered Ctl-C, which seems to be quite handy! (I am REALLY new to > this! John had shown me, but I forgot.) > > > * check out the @parallel decorator (note that you can't pickle and > > send elliptic curves with @parallel due to some unresolved issue > > involving forking an pari, so just send their Cremona label instead). > > I've had a look at this, I'm not very sure of what it's doing; is it > just allowing one to apply a function repetitively to all the elements > of a list? >From what I can tell, the @parallel makes an algorithm run on lists in parallel -- this will exploit multiple cores. > > The thing I thought I could try is: > > from sage.databases.cremona import LargeCremonaDatabase > database = CremonaDatabase().list(range(1, N)) > # This list function returns all the elliptic curves in the database > with conductors in the list given. I'd like to have N = 130001 in > order to do it all at once, but it might be better to do it in stages. You'll probably want to use an iterator instead. It should be much less memory-intensive. Additionally, ``xrange``s are especially optimized for iteration. database = CremonaDatabase().iter(xrange(1, 130001)) > > old = [E.isogeny_class()[0] for E in database] # takes 14 seconds > for N=50 > new = [E.isogeny_class_new()[0] for E in database] > # "old" and "new" are both lists of lists > > i = 0 > while i old = old[i] > old.sort() > new = new[i] > new.sort() You'll probably want an iterator here too. List access takes time ( O (n) ). from itertools import izip for old_item, new_item in izip(old, new): # ``izip`` creates an iterator that puts each corresponding item in a sequence of sequences in a tuple. http://docs.python.org/library/itertools.html#itertools.izip old_item.sort() new_item.sort() Also, are you sure they are not already sorted? > try: > new == old > except Exception, msg: > record_failure(msg) I am unsure of what this code is supposed to do. Does the code raise exceptions when comparison fails? You may be thinking of: # Somewhere before the loop... failures = [] ... if new != old: failures.append( (old, new) ) > i = i+1 > > Is this a horrendously convoluted way of doing it? > > My other remaining problem is how to run the test on another core(s) > while I get on with other things. I found a thing called dsage; would > that be the thing to use? > > Many thanks once again, > > Jenny --~--~-~--~~~---~--~~ 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: help.search("string") in Sage ?
Sage is great O_O
Thank youu :-)
Nathann
On Sep 17, 4:48 pm, Simon King wrote:
> Hi Nathann,
>
> On Sep 17, 3:41 pm, Nathann Cohen wrote:
>
> > I was just wondering if we had anything in Sage comparable to the
> > help.search("string") available in R.
>
> > This functions ( in Sage ) could be looking for the string ( or the words
> > contained in this string ) in all of Sage's docstrings, and return the
> > methods mentioning them.
>
> In a Sage session, type "sea" (without '"') and hit the tab key. This
> gives you all possible completions of "sea":
> sage: sea
> search_def search_doc search_src
>
> Then, for each of these commands, read the documentation. That's to
> say: do
> sage: search_src?
>
> > I remember I found it pretty useful in R ! ;-)
>
> search_src is even more useful, since it searches in the source code,
> not only in the documentation...
>
> Cheers,
> Simon
--~--~-~--~~~---~--~~
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] General question on the kind of things we want in Sage
Hello !!! I was just wondering about the kind of algorithms we want in Sage. For example, if someone in my lab finds out a brand new algorithm to compute a brand-new invariant for a pretty restrictive ( but brand-new, too ) class of graphs, do we want to have it included in Sage ? My answer, for the moment, is no... I was thinking we only wanted to see in Sage things that may be useful to everybody, and let people write their own functions, but... - There are many NP-complete problems that are known to be polynomial on restrictive class of instances. Does that mean we will only use the "general" ( and inefficien ) algorithms to solve these problems in Sage for instances that are known to be easy ? - When I try to promote Sage around me, I never forget to mention the fact that it would be a pretty good way to exchange implementation of algorithms in a "common" lamguage, as there are ( or there will be ) libraries dealing with every structure ( or Category ? ^^; I am quite ignorant on that field ) the mathematical world can create. Could it be good for sage to I do not know, perhaps become some kind of library of published algorithms ? Should we be thinking about ways to let used find "the algorithm described in paper XXX for journal XXX number XX pages XX-XX" ? The thing is that I am tempted ( for the Graph class ) to write many functions I find useful, but these functions would very quickly crowd the list of Graph methods... For example I am interested in computing orientations of graphs, and there may be many functions needed... For example, how could I include 10 or 20 functions dealing with one particular problem of graphs without quickly transforming this already quite crowded class in something impossible to browse ? These may be questions to ask in several years... But Sage is growing pretty quickly, though O_o Thanks !!! Nathann --~--~-~--~~~---~--~~ 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: Behavior of solve
Hi, I don't use the solve() function at all. I'm probably missing the user's point of view completely, so please take what I say below with a grain of salt. Going by the "What Would Maple Do" rule, I would like solve() to remain exact. Looking through the examples here http://www.maplesoft.com/support/help/view.aspx?path=examples/solve I couldn't see any cases where Maple switches to numeric results. I think it's better to return no results if the exact methods don't work, and point the user to the numeric solver. This is fsolve [1] in the case of Maple. Is it find_root() in Sage? [1] http://www.maplesoft.com/support/help/view.aspx?path=fsolve On Thu, 17 Sep 2009 06:30:19 -0700 (PDT) kcrisman wrote: > > For a frustrated user because of precisely this issue, see > http://groups.google.com/group/sage-support/browse_thread/thread/6407896aab6a52cc/bfb4e85815ef94a3?show_docid=bfb4e85815ef94a3 > . I now think we should definitely change to having to_poly_solve as > an option, but not default, even if we miss some solutions that way, > because it's unlikely that Maxima will be able to change its behavior > very soon, even if they wanted to. In this case, I agree that we should make to_poly_solve a non-default option. Thanks. Burcin --~--~-~--~~~---~--~~ 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: help.search("string") in Sage ?
Hi Nathann,
On Sep 17, 3:41 pm, Nathann Cohen wrote:
> I was just wondering if we had anything in Sage comparable to the
> help.search("string") available in R.
>
> This functions ( in Sage ) could be looking for the string ( or the words
> contained in this string ) in all of Sage's docstrings, and return the
> methods mentioning them.
In a Sage session, type "sea" (without '"') and hit the tab key. This
gives you all possible completions of "sea":
sage: sea
search_def search_doc search_src
Then, for each of these commands, read the documentation. That's to
say: do
sage: search_src?
> I remember I found it pretty useful in R ! ;-)
search_src is even more useful, since it searches in the source code,
not only in the documentation...
Cheers,
Simon
--~--~-~--~~~---~--~~
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] help.search("string") in Sage ?
Hello everybody !!!
I was just wondering if we had anything in Sage comparable to the
help.search("string") available in R.
This functions ( in Sage ) could be looking for the string ( or the words
contained in this string ) in all of Sage's docstrings, and return the
methods mentioning them.
I remember I found it pretty useful in R ! ;-)
Nathann
--~--~-~--~~~---~--~~
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: math software journal for R
2009/9/16 William Stein : > > On Wed, Sep 16, 2009 at 9:15 AM, Jason Grout > wrote: >> >> At various times, a journal for math software has been discussed. Here >> is the math software journal for R. R probably has a much bigger >> community than Sage, and is much more entrenched in the profession than >> Sage. It would probably be good to talk to these guys and see how they >> do things if we want a math software journal. >> >> http://journal.r-project.org/index.html >> >> Thanks, >> >> Jason >> > > As far as I can tell this seems to be a 100% standard journal, which > happens to be free, and also happens to be about R But maybe it > doesn't do anything creative regarding R code as far as I can tell. > One thing that has always challenged me when considering starting a > Sage journal is a desire to somehow do much more: something involving > code, say on the web, which is guaranteed to stay working. > > The first article listed at the R journal is called "The Future of R", > which is pretty enticing! > > http://journal.r-project.org/current.html > > William FWIW, there is a Mathematica Journal http://www.mathematica-journal.com/ the latest appears to be volume 11 issue 1, which is dated 2008, which makes me think the journal might well have folded. --~--~-~--~~~---~--~~ 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: Behavior of solve
For a frustrated user because of precisely this issue, see http://groups.google.com/group/sage-support/browse_thread/thread/6407896aab6a52cc/bfb4e85815ef94a3?show_docid=bfb4e85815ef94a3 . I now think we should definitely change to having to_poly_solve as an option, but not default, even if we miss some solutions that way, because it's unlikely that Maxima will be able to change its behavior very soon, even if they wanted to. - kcrisman On Sep 16, 9:42 am, kcrisman wrote: > Sorry, I think you both misunderstood my question :) If I was having > trouble in that sense, I would have posted on sage-support. > > My question is, what behavior should Sage ALLOW from solve? I am in > the midst of fixing some solve behavior caused by the Maxima upgrade, > and want someone else's opinion. One idea I had was a keyword to > allow to_poly_solve (which allows better answers, but also inexact > ones) and very careful documentation to point out that solve with more > than one equation may return numerical answers. > > > > What is the desired behavior of solve()? Since roots() uses it for > symbolic input, we already have some problems (also note that > to_poly_solve does not return multiplicities). However, getting rid > of to_poly_solve seems unpleasant too, since it does solve a lot of > equations which formerly were mysterious to Sage. > > If you have an opinion, please let me know. Unfortunately, it > doesn't > look easy to keep an exact-solution-only behavior here. The author > of > to_poly_solve expects to fix some bugs later this fall, but probably > not this aspect, since it's not a bug in Maxima, rather in our use of > Maxima. > > - kcrisman --~--~-~--~~~---~--~~ 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: Checking new code with an entire database (isogenies)
Hi William, Thank you for all the information. I have spent time this morning going through it all, the alarm thing is really useful ~ I also discovered Ctl-C, which seems to be quite handy! (I am REALLY new to this! John had shown me, but I forgot.) > * check out the @parallel decorator (note that you can't pickle and > send elliptic curves with @parallel due to some unresolved issue > involving forking an pari, so just send their Cremona label instead). I've had a look at this, I'm not very sure of what it's doing; is it just allowing one to apply a function repetitively to all the elements of a list? The thing I thought I could try is: from sage.databases.cremona import LargeCremonaDatabase database = CremonaDatabase().list(range(1, N)) # This list function returns all the elliptic curves in the database with conductors in the list given. I'd like to have N = 130001 in order to do it all at once, but it might be better to do it in stages. old = [E.isogeny_class()[0] for E in database]# takes 14 seconds for N=50 new = [E.isogeny_class_new()[0] for E in database] # "old" and "new" are both lists of lists i = 0 while ihttp://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: round(), floor() and ceil() on interval objects
William Stein wrote : > 2009/9/17 Jason Grout : > >> Currently, round(), floor(), and ceil() on interval objects return >> intervals. >> >> There is a patch up at #2899 that changes these functions to return >> integers (round-> "round the midpoint", floor -> largest integer below >> the bottom of the interval, etc.). I think the reasoning is that >> round(), floor, ceil, etc. should always return integers. >> >> What do people think? Should we close the ticket, or should we merge >> the patch (after possible rebasing). >> >> To illustrate: >> >> Currently: >> >> sage: R = RealIntervalField(100) >> sage: a = R(9.5, 11.3); a.str(style='brackets') >> '[9.500 .. 11.300710542735760101]' >> sage: floor(a).str(style='brackets') >> '[9.000 .. 11.00]' >> I use computation over intervals in order to see the error x in a <=> x=9.5 or x=9.56 or x=11.2 or ... I test the function sin, the result of sin a = [-1..1] The value is 0.1 or 0.2 or -0.6 or. The a^2 operation is similar. So I prefer floor a = 9 or 10 or ... or 11, or [9..11]. Result is include in [9..11] min and max functions may be usefull if we want to get 9.5 and 11.3. F. >> >> Proposed: >> >> sage: floor(a) >> 9 >> >> > > I would find this s useful! Whenever I compute with > intervals, I often really want the integer floor, ceiling, or round. > > 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] is Sage using libgcrypt 1.4.3 or 1.4.0?
Hi folks, Since Sage version 3.3, Sage has been shipping two versions of libgcrypt: 1.4.0 and 1.4.3 (both of which are under LGPL v2.1). These two different versions are contained in one spkg, i.e. the libgcrypt-1.4.3 spkg. After uncompressing the libgcrypt spkg, the source of version 1.4.0 is found under the src/ directory, while version 1.4.3 is under src/libgcrypt-1.4.3/. From the file spkg-install, only version 1.4.0 is built. Is this a case of a messed up package or I'm missing something? I don't mean to be rude here; I'm just curious why the libgcrypt spkg contains two different versions of libgcrypt. -- 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] Problem sharing directory
Hi, I want to launch 2 instances of sage on the same machine, and even more launch sage on 2 (3) machines sharing one directory by nfs. My "notebook" command is: notebook(open_viewer=False,directory='/ws/nbfiles',address='',secure=True,port=8001,timeout=3600,ulimit='-v 5',accounts=True) (the shared directory is: /ws/nbfiles) and I have an other command wich differs only by the port number (and same commands all the machines). When I launch the second notebook (on the same machine as the first), it crashes: Another twistd server is running, PID 22859 This seems normal, and sage says "--pidfile and --logfile parameters to avoid clashes.". Obviously, one needs to have different pidfiles. But how can I specify these parameters ? sage --pidfile="..." is not accepted. Yours t.d. <> smime.p7s Description: S/MIME Cryptographic Signature
[sage-devel] Re: Statistics in Sage
Carlo Hamalainen wrote: > On Thu, Sep 17, 2009 at 6:48 AM, Robert Dodier > wrote: >> Some random comments on >> http://trac.sagemath.org/sage_trac/attachment/ticket/6827/probability_distribution.patch > > Between that and the better performance of scipy (see my other email > in this thread) I figure we should probably throw away > probability_distribution.pyx and use the scipy stuff, at least for > generating gaussians and so on. > > What do other people think? > To paraphrase William when he was doing hidden markov models, I would rather spend a week writing a good wrapper/interface for a library someone else is maintaining, than spend a month reimplementing standard functionality that I have to maintain myself. That said, William has a good point about beating everything else we've seen with custom code in finance.TimeSeries. Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Statistics in Sage
On Thu, Sep 17, 2009 at 6:48 AM, Robert Dodier wrote: > Some random comments on > http://trac.sagemath.org/sage_trac/attachment/ticket/6827/probability_distribution.patch Between that and the better performance of scipy (see my other email in this thread) I figure we should probably throw away probability_distribution.pyx and use the scipy stuff, at least for generating gaussians and so on. What do other people think? -- Carlo Hamalainen http://carlo-hamalainen.net --~--~-~--~~~---~--~~ 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: Statistics in Sage
On Thu, Sep 17, 2009 at 6:28 AM, Jason Grout
wrote:
> I tried generating lots of normally distributed values after applying
> the patch. It seems that scipy was the winner by far for speed:
>
> sage: a=RealDistribution('gaussian', 2)
> sage: %timeit [a.get_random_element() for _ in range(1000)]
> 100 loops, best of 3: 2.87 ms per loop
> sage: import scipy.stats
> sage: %timeit scipy.stats.norm.rvs(0,2,size=1000)
> 1000 loops, best of 3: 252 µs per loop
> sage: %timeit r.rnorm(1000,0,2).sage()
> 10 loops, best of 3: 37 ms per loop
>
> Can we make get_random_element take an argument to get more than one
> element?
>
> a.get_random_element(1000) would return a list of 1000 random elements.
We can but I can't get it as fast as scipy:
sage: a=RealDistribution('gaussian', 2)
sage: %timeit [a.get_random_element() for _ in range(1000)]
100 loops, best of 3: 2.6 ms per loop
sage:
sage: %timeit a.get_random_element_testing(1000)
1000 loops, best of 3: 374 µs per loop
sage:
sage: import scipy.stats
sage: %timeit scipy.stats.norm.rvs(0,2,size=1000)
1000 loops, best of 3: 275 µs per loop
Close, but no sausage.
--
Carlo Hamalainen
http://carlo-hamalainen.net
--~--~-~--~~~---~--~~
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: round(), floor() and ceil() on interval objects
2009/9/17 Jason Grout : > > Currently, round(), floor(), and ceil() on interval objects return > intervals. > > There is a patch up at #2899 that changes these functions to return > integers (round-> "round the midpoint", floor -> largest integer below > the bottom of the interval, etc.). I think the reasoning is that > round(), floor, ceil, etc. should always return integers. > > What do people think? Should we close the ticket, or should we merge > the patch (after possible rebasing). > > To illustrate: > > Currently: > > sage: R = RealIntervalField(100) > sage: a = R(9.5, 11.3); a.str(style='brackets') > '[9.500 .. 11.300710542735760101]' > sage: floor(a).str(style='brackets') > '[9.000 .. 11.00]' > > > Proposed: > > sage: floor(a) > 9 > I would find this s useful! Whenever I compute with intervals, I often really want the integer floor, ceiling, or round. 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] round(), floor() and ceil() on interval objects
Currently, round(), floor(), and ceil() on interval objects return intervals. There is a patch up at #2899 that changes these functions to return integers (round-> "round the midpoint", floor -> largest integer below the bottom of the interval, etc.). I think the reasoning is that round(), floor, ceil, etc. should always return integers. What do people think? Should we close the ticket, or should we merge the patch (after possible rebasing). To illustrate: Currently: sage: R = RealIntervalField(100) sage: a = R(9.5, 11.3); a.str(style='brackets') '[9.500 .. 11.300710542735760101]' sage: floor(a).str(style='brackets') '[9.000 .. 11.00]' Proposed: sage: floor(a) 9 Thanks, Jason -- 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Statistics in Sage
2009/9/16 lgautier :
>
>
>
> On Sep 17, 6:44 am, Jason Grout wrote:
>> Jason Grout wrote:
>> > Carlo Hamalainen wrote:
>> >> On Wed, Sep 16, 2009 at 7:46 PM, Jason Grout
>> >> wrote:
>> >>> R has a C interface for lots of functions (like the distribution
>> >>> functions that I wanted today). I imagine that a stats module would use
>> >>> Cython to call the C functions for these sorts of things, but then use
>> >>> rpy2 for the rest of the interaction with R.
>> >> Which distribution functions did you want? Are these of any use?
>> >>http://trac.sagemath.org/sage_trac/ticket/6827
>>
>> > I tried generating lots of normally distributed values after applying
>> > the patch. It seems that scipy was the winner by far for speed:
>>
>> > sage: a=RealDistribution('gaussian', 2)
>> > sage: %timeit [a.get_random_element() for _ in range(1000)]
>> > 100 loops, best of 3: 2.87 ms per loop
>> > sage: import scipy.stats
>> > sage: %timeit scipy.stats.norm.rvs(0,2,size=1000)
>> > 1000 loops, best of 3: 252 µs per loop
>> > sage: %timeit r.rnorm(1000,0,2).sage()
>> > 10 loops, best of 3: 37 ms per loop
>>
>> Actually, using rpy2 (and R 2.9.2), the new R<->Python interface, we can
>> get much closer to the scipy timing:
>>
>> sage: import rpy2
>> sage: import rpy2.robjects as robjects
>> sage: %timeit numpy.array(robjects.r.rnorm(int(1000),int(0),int(2)))
>> 1000 loops, best of 3: 782 µs per loop
>
> In that example, the loops are in fact done at the C level.
> The call rnorm(1000, 0, 2) tells the R function rnorm() to generate
> 1000 random arrays
> (and this happen to be largely implemented in C).
>
>> lgautier, feel free to correct my example to make it faster!
>
> The only trick I could see would be to use numpy.asarray() in place of
> numpy.array()
> (and that would only make it slightly faster depending on the larger
> context the resulting vector is used)
>
Here's another benchmark: take 10^6 numbers (say random normal) and
compute the standard deviation. Sage is over 7 times faster than
scipy.
sage: t = finance.TimeSeries(10^6)
sage: t = t.randomize('normal')
sage: timeit("t.standard_deviation()")
125 loops, best of 3: 3.66 ms per loop
sage: import scipy.stats
sage: v = scipy.stats.norm.rvs(0,2,size=100)
sage: timeit("v.std()")
25 loops, best of 3: 26.7 ms per loop
sage: 26.7/3.66
7.29508196721311
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
