[sage-devel] Re: CUDA and Sage
On Jul 21, 8:53 pm, Carl Witty [EMAIL PROTECTED] wrote: CUDA includes 2 programming languages (a C dialect and a low-level assembly language), and a library to load programs into the graphics card, send data back and forth, call the programs, etc. (There's also a mode where you write your program in a combination of regular C and CUDA's dialect; the CUDA tools compile the CUDA part themselves, pass the regular parts to your regular C compiler, and automatically construct glue code to tie the two together.) Actually, the above is a simplification: CUDA includes 2 separate libraries to load programs/exchange data/call the programs, and you apparently cannot mix and match. CUDA includes fast BLAS and FFT implementations that run on the GPU; to use these, you must use the high-level API, but pycuda is based on the low-level API. ... mabshoff doesn't like the idea of recreating pycuda using Cython, but I think it's reasonable. pycuda is actually pretty small (650 lines of Python, 1325 lines of C++; the 1325 lines of C++ would probably be replaced by a much smaller number of lines of Cython). Doing the rewrite would also give a chance to switch from the low-level to the high-level API, which would make it much easier (possible?) to use the CUDA BLAS and FFT. I've been doing some more reading, and using the high-level API is not as easy as I was guessing. The problem is that from the high-level API, there seems to be no documented way to load a .cubin CUDA object file from disk; instead, the object file must be linked into the program. Building a new Python extension for every new CUDA program probably works (like how %cython works in the notebook), but it's pretty annoying. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: printing of QQbar elements
On Jul 21, 2:08 pm, Jason Grout [EMAIL PROTECTED] wrote: Currently most elements of QQbar are printed in interval notation: [-2.0741620076681855 .. -2.0741620076681850] + [1.7722625415877633 .. 1.7722625415877638]*I When dealing with lots of these, or when dealing with matrices and vectors of QQbar elements, this quickly becomes overwhelming because of the massive amount of almost-the-same numbers, the extra brackets, etc. What do people think of printing QQbar elements in a different way (thanks to cwitty for suggesting the question mark syntax): 1. Appending a question mark after the last unquestionable digit an interval: -2.074162007668185? + 1.772262541587763?*I 2. Appending a question mark after the first questionable digit of an interval: -2.0741620076681853? + 1.7722625415877636?*I My actual suggestion was that a question mark could signal that the previous digit might be wrong by +/- 1. Using last unquestionable digit or first questionable digit is not good, because [0.9 .. 1.1] has no unquestionable digits. With my proposal, this would be 1.0?, and [-0.001 .. 0.001] would be 0.000?. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: The ISSAC Sage Plenary talk
On Tue, Jul 22, 2008 at 8:44 AM, Martin Albrecht [EMAIL PROTECTED] wrote: Hi William, just a few nitpicks: - Gruppenzugehörigkeit is probably a typical-typo leftover (?) - In the three points explaining what Sage is more precisely you write that we have new code ... that unifies leaving the impression that all/most of our code is just interface stuff, i.e. the new implementations of algorithms etc. are not mentioned. - In the who is Sage graphic, what do the sizes of the names mean? This is probably a question for Harald and not you. - Cryptography: Sage ... is that a joke or unfinished? If you want to extend the slide on crypto, you could add that we have equation system generators for AES in Sage, this is something I get questions about/requests for every other week. Also, David Kohel's code could be mentioned. As I mentioned when I sent out the email the talk is not finished yet. Can you make a crypto slide with 3-4 lines of examples too? I'll bug you about this today when I see you. - I'd add a slide: Commutative Algebra and mention PolyBoRi, Singular. People at ISAAC seem to care about comm. alg. :-) Also, PolyBoRi isn't only for crypto. Yep, it's also for SAT. Thanks. I would greatly appreciate slide(s) from you. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: The ISSAC Sage Plenary talk
Hi William, just a few nitpicks: - Gruppenzugehörigkeit is probably a typical-typo leftover (?) - In the three points explaining what Sage is more precisely you write that we have new code ... that unifies leaving the impression that all/most of our code is just interface stuff, i.e. the new implementations of algorithms etc. are not mentioned. - In the who is Sage graphic, what do the sizes of the names mean? This is probably a question for Harald and not you. - Cryptography: Sage ... is that a joke or unfinished? If you want to extend the slide on crypto, you could add that we have equation system generators for AES in Sage, this is something I get questions about/requests for every other week. Also, David Kohel's code could be mentioned. - I'd add a slide: Commutative Algebra and mention PolyBoRi, Singular. People at ISAAC seem to care about comm. alg. :-) Also, PolyBoRi isn't only for crypto. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: remove or hide a method?
Hi William, On Thu, Jul 17, 2008 at 1:32 PM, William Stein [EMAIL PROTECTED] wrote: sage: class Foo(object): : def trait_names(self): : return ['a','b','c','d'] : sage: a = Foo() sage: a. a.aa.ba.ca.da.trait_names As a user, I don't know whether or not I would prefer a customized tab completion. trait_names doesn't currently allow one to cover up existing names from appearing in the tab completion list. However, I'm certain Fernando Perez could make it so IPython could call some function like trait_names that would allow one to cover up certain attributes. Fernando -- what do you think? The trait_names thing noticed above is a coincidence: it's just an artifact of the fact that ipython happens to hide a bunch of extra attributes with which the Traits library pollutes all objects that inherit from it. Someone stumbled upon it and thought it was some kind of tab-completion API :) But IPython *does* have custom tab completers. This file contains examples and pointers for how to write your own: http://bazaar.launchpad.net/~ipython/ipython/trunk/annotate/1041?file_id=ipy_completers.py-20080216095032-xb0is4a97lmosv2z-148 so it should be possible for the end user to customize completion to his heart's content. If the existing API doesn't work for some specific case, let us know and we'll treat it as a bug. Regards, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: CUDA and Sage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, mabshoff wrote: | Various people have started looking into this, but so far no one has | produced code. One big issue (at least for me) with pycuda is the | requirement for boost, but I am not sure how that could be overcome. | [...] | The main issue with boost I see is that PolyBoRi ships with a subset | of boost and installs it into $SAGE_LOCAL/include/boost. I assume that | it will not be enough of boost, i.e. boost python is not part of it. | Since PolyBoRi also has an interface to Python using boost Python we | might be able to add the bits needed to the polybori.spkg, otherwise I | see potentially huge trouble by colliding boost versions in the tree. | And shipping boost itself is not really an option due to its rather | large size. If the Boost headers are all that is needed (in many cases they are, since most Boost libraries are header-only), it may be worth to ship them together with Sage. I just checked and the complete Boost headers amount to a compressed tarbz2ball of 2.9 MB, so packing them in Sage should not be a big deal. With the non-header-only Boost libraries (such as Boost.Python), a possible approach could be that of modifying the build system of a package that uses them to compile and link the needed Boost libraries together with the package's own library. I.e., add the Boost libraries' .cpp files directly in the project's Makefile. Another possibility (especially if the use of Boost is widespread among Sage packages) would be to compile shared library versions of the needed Boost libraries when building Sage and use them when building the packages that need them. Just a couple of thoughts :) Best regards, ~ Francesco. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiFltUACgkQFCtI0YdDCEs8DACdG93ZTG4wpyPxXMJMyl5bJqU7 zh0AnRfhIZ+wF+AOOpUVMp/6s8Qi2N6S =T7jJ -END PGP SIGNATURE- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: CUDA and Sage
Francesco Biscani a écrit : With the non-header-only Boost libraries (such as Boost.Python), a possible approach could be that of modifying the build system of a package that uses them to compile and link the needed Boost libraries together with the package's own library. I.e., add the Boost libraries' .cpp files directly in the project's Makefile. Another possibility (especially if the use of Boost is widespread among Sage packages) would be to compile shared library versions of the needed Boost libraries when building Sage and use them when building the packages that need them. As a Boost user, I just want to say that the Boost installation process is not standard (not using automake, but Jam) and taht this a very long task. Actually, most people use packaged versions (.deb in Debian...) to avoid compilation, but this seems precisely what Sage do not want to do. Yours, t.d. -- Thierry Dumont. Institut Camille Jordan -- Mathematiques-- Univ. Lyon I,43 Bd du 11 Novembre 1918, 69622 - Villeurbanne Cedex - France. [EMAIL PROTECTED] web: http://math.univ-lyon1.fr/~tdumont begin:vcard fn:Thierry Dumont n:Dumont;Thierry org;quoted-printable:CNRS - Universit=C3=A9 Lyon 1.;Institut Camille Jordan adr:;;43 Bd du 11 Novembre;Villeurbanne Cedex;F;69621;France email;internet:[EMAIL PROTECTED] title;quoted-printable:Ing=C3=A9nieur de Recherche/Research Ingeneer x-mozilla-html:FALSE url:http://math.univ-lyon1.fr/~tdumont version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
[sage-devel] Re: CUDA and Sage
On Jul 22, 1:29 am, Thierry Dumont [EMAIL PROTECTED] wrote: Francesco Biscani a écrit : With the non-header-only Boost libraries (such as Boost.Python), a possible approach could be that of modifying the build system of a package that uses them to compile and link the needed Boost libraries together with the package's own library. I.e., add the Boost libraries' .cpp files directly in the project's Makefile. The solution I imagine is the following: PolyBoRi has a boost::python interface, but we do not install it since we do not use it. It could easily be added back. That way we do not have two boost installations fighting for supremacy. Since PolyBoRi is in Sage and considered very important Cuda breaking PolyBoRi via its boost requirement is a big no no and will not happen. But the way suggested above will make both camps happy. This might happen in the next week, i.e. we would likely have an optional PyCuda.spkg by Dev1 at SFU. Another possibility (especially if the use of Boost is widespread among Sage packages) would be to compile shared library versions of the needed Boost libraries when building Sage and use them when building the packages that need them. As a Boost user, I just want to say that the Boost installation process is not standard (not using automake, but Jam) and taht this a very long task. Actually, most people use packaged versions (.deb in Debian...) to avoid compilation, but this seems precisely what Sage do not want to do. Yeah, and many times one needs to use boost CVS in order to work around bugs in less common OSes like some BSD flavors. So depending on the system provided boost install is something I would prefer to avoid. Re cwitty: I do not mind if you redid the boost::python code in Cython, I am just saying that I do not have the time to do it myself. But I would be more than happy if you did it :) Yours, t.d. Cheers, Michael -- Thierry Dumont. Institut Camille Jordan -- Mathematiques-- Univ. Lyon I,43 Bd du 11 Novembre 1918, 69622 - Villeurbanne Cedex - France. [EMAIL PROTECTED] web:http://math.univ-lyon1.fr/~tdumont tdumont.vcf 1KDownload smime.p7s 5KDownload --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: The ISSAC Sage Plenary talk
On Jul 22, 10:38 am, William Stein [EMAIL PROTECTED] wrote: Hi, I've posted a new version of my ISSAC talk to ... hi, here are some ideas that come to my mind... 1. you talk about cython and python. that's ok, but you are only talking about the solution to a problem without explaining the problem. I think you should explain, that there is a need to have two layers. A powerful high level approach (solution: python), to state algorithms and combine classes of objects and a low level approach to implement fast, easy to maintain code and library interfaces. The whole project wouldn't work, if one of them is missing. (i.e. only C++ or only python). I think that's important to explain. 2. combinatorics, point 4. you mention open source packages like networkX. maybe this is not widely known and you should either explain it or just say, that you use a very good open source package for blah - so, more focus on the functionality, not a name that probably doesn't transport anything to the audience 3. i wouldn't show how to interface with mma. if someone asks, ok, but not during the talk. at least you have a certain reason to. well, and you can also bring the PartitionsP speed example (as a proof of concept for point 1. above) 4. maybe you have, but also tell the audience, that the documentation of the code is very important. i.e. students can learn about the inner workings just as easily as they can write programs in sage (same language, ...). this strengthens the python language for general scientific usage and is not specific to sage. there is no dedicated technical barrier between users and developers. 5. future ... maybe also some general closing words about the scientific ecosystem of mathematics: by sharing code and implementations openly, the quality is higher and so on. this is trivial, but you could say that sage wants to push into that direction. (at least i think it wants to and this is point where sage doesn't want to copy the big M*s ;) h --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.6.rc0 released
Installed fine and passed sage -testall on amd64 hardy heron, phenom chip. On Mon, Jul 21, 2008 at 7:16 PM, mabshoff [EMAIL PROTECTED] wrote: Hello folks, this is 3.0.6.rc0 which should be the last release before the ISSAC 2008 special 3.0.6 release for Wednesday. We fixed a bunch of issues and were a little less conservative than I though, but what could go wrong ;) Sources are at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.rc0.tar Please report any problem and also success builds. Cheers, Michael Merged in Sage 3.0.6.rc0: #10: Gary Furnish, Dan Grayson: update M2 to the 1.1 release [Reviewed by Michael Abshoff, Mike Hansen] #3345: Mike Hansen, William Stein: trace no longer works in 3.0.2 [Reviewed by William Stein, Mike Hansen] #3669: William Stein: improve multiple_of_order command for torsion subgroups of modular abelian varieties [Reviewed by Craig Citro] #3671: Michael Abshoff, Clement Pernet: Fix ssmod.py doctest failures in Sage 3.0.4 or later [Reviewed by William Stein] #3694: Michael Abshoff, Bill Hart: Update FLINT to the 1.0.13 release [Reviewed by William Stein] #3681: William Stein: modulus() randomly broken for gf2e fields [Reviewed by John Cremona, Michael Abshoff] #3695: Ondrej Certik, John Cremona: Improve factor documentation [Reviewed by William Stein, Martin Albrecht] #3696: Michael Abshoff: Fix gmp.spkg build issue on Solaris [Reviewed by William Stein] #3700: Michael Abshoff: Solaris: Fix ntl build issue [Reviewed by William Stein] #3701: Michael Abshoff: Solaris: fix polybori build due to bashism [Reviewed by William Stein] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] periods.cc:593: error: call of overloaded `log(int)' is ambiguous
Hello, upon compiling of sage 3.0.5 I got this error: ## periods.cc: In member function `void ldash1::init(const level*, const std::vectorlong int, std::allocatorlong int , long int, const rational)': periods.cc:593: error: call of overloaded `log(int)' is ambiguous /usr/include/bits/mathcalls.h:110: error: candidates are: double log(double) /usr/include/c++/3.3.5/cmath:419: error: long double std::log(long double) /usr/include/c++/3.3.5/cmath:411: error: float std::log(float) periods.cc: In constructor `lfchi::lfchi(const level*, const newform*)': periods.cc:635: error: call of overloaded `log(int)' is ambiguous /usr/include/bits/mathcalls.h:110: error: candidates are: double log(double) /usr/include/c++/3.3.5/cmath:419: error: long double std::log(long double) /usr/include/c++/3.3.5/cmath:411: error: float std::log(float) periods.cc: In function `NTL::RR G(int, NTL::RR)': periods.cc:975: error: call of overloaded `log(int)' is ambiguous /usr/include/bits/mathcalls.h:110: error: candidates are: double log(double) /usr/include/c++/3.3.5/cmath:419: error: long double std::log(long double) /usr/include/c++/3.3.5/cmath:411: error: float std::log(float) make[3]: *** [periods_n.o] Error 1 make[3]: Leaving directory `/opt/sage-3.0.5/spkg/build/ eclib-20080310.p4/src/g0n' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/sage-3.0.5/spkg/build/ eclib-20080310.p4/src' Error building cremona real8m43.572s user6m51.700s sys 0m17.700s sage: An error occurred while installing eclib-20080310.p4 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of ... ## This is a Linux 2.4.31 SMP kernel with all bells and whistles. Any suggestions? Regards Chris Karakas http://www.karakas-online.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
Here is part of install.log (I have set over more or less
sensitive, or boring information):
make[1]: Entering directory `XX/sage-3.0.5/spkg'
base/dir-0.1-install
../data/
../local/
../local/etc
../local/lib
../local/bin
../local/include
../tmp/
XX/spkg/build
installed/
base/prereq-0.3-install
Starting prerequisite check.
Machine: Linux 2.4.31 #11 SMP Sun Jul 10 00:53:34 CEST 2005
i686 i686 i386 GNU/Linux
found make
found perl
found m4
found ranlib
found tar
found gcc
prereq-0.3/
prereq-0.3/.hg/
prereq-0.3/.hg/00changelog.i
prereq-0.3/.hg/dirstate
prereq-0.3/.hg/requires
prereq-0.3/.hg/store/
prereq-0.3/.hg/store/00changelog.i
prereq-0.3/.hg/store/00manifest.i
prereq-0.3/.hg/store/data/
prereq-0.3/.hg/store/data/_makefile.in.i
prereq-0.3/.hg/store/data/autom4te.cache/
prereq-0.3/.hg/store/data/autom4te.cache/output.0.i
prereq-0.3/.hg/store/data/autom4te.cache/requests.i
prereq-0.3/.hg/store/data/autom4te.cache/traces.0.i
prereq-0.3/.hg/store/data/configure.ac.i
prereq-0.3/.hg/store/data/configure.i
prereq-0.3/.hg/store/undo
prereq-0.3/.hg/undo.dirstate
prereq-0.3/configure
prereq-0.3/configure.ac
prereq-0.3/Makefile.in
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for bison... bison -y
checking for gcc... yes
checking for make... yes
checking for m4... yes
checking for perl... yes
checking for ranlib... yes
checking for bison... bison
checking for flex... flex
checking whether gcc is new enough... yes
configure: creating ./config.status
config.status: creating Makefile
All prerequisites appear to be present.
base/bzip2-1.0.4-install 21
Decompressing bzip2
bzip2-1.0.4/
bzip2-1.0.4/libbz2.def
X
bzip2-1.0.4/README.XML.STUFF
make[2]: Entering directory `XX/spkg/build/bzip2-1.0.4'
If compilation produces errors, or a large number of warnings,
please read README.COMPILATION.PROBLEMS -- you might be able to
adjust the flags in this Makefile to improve matters.
Also in README.COMPILATION.PROBLEMS are some hints that may help
if your build produces an executable which is unable to correctly
handle so-called 'large files' -- files of size 2GB or more.
gcc -fPIC -c blocksort.c
gcc -fPIC -c huffman.c
gcc -fPIC -c crctable.c
gcc -fPIC -c randtable.c
gcc -fPIC -c compress.c
gcc -fPIC -c decompress.c
gcc -fPIC -c bzlib.c
rm -f libbz2.a
ar cq libbz2.a blocksort.o huffman.o crctable.o randtable.o compress.o
decompress.o bzlib.o
ranlib libbz2.a
gcc -fPIC -c bzip2.c
gcc -fPIC -o bzip2 bzip2.o -L. -lbz2
gcc -fPIC -c bzip2recover.c
gcc -fPIC -o bzip2recover bzip2recover.o
Doing 6 tests (3 compress, 3 uncompress) ...
If there's a problem, things might stop at this point.
./bzip2 -1 sample1.ref sample1.rb2
./bzip2 -2 sample2.ref sample2.rb2
./bzip2 -3 sample3.ref sample3.rb2
./bzip2 -d sample1.bz2 sample1.tst
./bzip2 -d sample2.bz2 sample2.tst
./bzip2 -ds sample3.bz2 sample3.tst
cmp sample1.bz2 sample1.rb2
cmp sample2.bz2 sample2.rb2
cmp sample3.bz2 sample3.rb2
cmp sample1.tst sample1.ref
cmp sample2.tst sample2.ref
cmp sample3.tst sample3.ref
If you got this far and the 'cmp's didn't complain, it looks
like you're in business.
To install in /usr/local/bin, /usr/local/lib, /usr/local/man and
/usr/local/include, type
make install
To install somewhere else, eg, /xxx/yyy/{bin,lib,man,include}, type
make install PREFIX=/xxx/yyy
If you are (justifiably) paranoid and want to see what 'make install'
is going to do, you can first do
make -n install or
make -n install PREFIX=/xxx/yyy respectively.
The -n instructs make to show the commands it would execute, but
not actually execute them.
Instructions for use are in the preformatted manual page, in the file
bzip2.txt. For more detailed documentation, read the full manual.
It is available in Postscript form (manual.ps), PDF form (manual.pdf),
and HTML form (manual.html).
You can also do bzip2 --help to see some helpful information.
bzip2 -L displays the software license.
XX long install output here
sage_scripts-3.0.5
Machine:
Linux 2.4.31 #11 SMP Sun Jul 10 00:53:34 CEST 2005 i686 i686
i386 GNU/Linux
Deleting directories from past builds of previous/current versions of
sage_scripts-3.0.5
Extracting package /spkg/standard/sage_scripts-3.0.5.spkg ...
-rw-r--r--1 1003 1003 640433
[sage-devel] Re: The ISSAC Sage Plenary talk
Harald Schilly wrote: On Jul 22, 10:38 am, William Stein [EMAIL PROTECTED] wrote: Hi, I've posted a new version of my ISSAC talk to ... hi, here are some ideas that come to my mind... 1. you talk about cython and python. that's ok, but you are only talking about the solution to a problem without explaining the problem. I think you should explain, that there is a need to have two layers. A powerful high level approach (solution: python), to state algorithms and combine classes of objects and a low level approach to implement fast, easy to maintain code and library interfaces. The whole project wouldn't work, if one of them is missing. (i.e. only C++ or only python). I think that's important to explain. 2. combinatorics, point 4. you mention open source packages like networkX. maybe this is not widely known and you should either explain it or just say, that you use a very good open source package for blah - so, more focus on the functionality, not a name that probably doesn't transport anything to the audience 3. i wouldn't show how to interface with mma. if someone asks, ok, but not during the talk. at least you have a certain reason to. well, and you can also bring the PartitionsP speed example (as a proof of concept for point 1. above) You could point out that their licensing agreement seems to make accessing mma over http illegal (even if it is secure and you have your own personal license), and when we asked for clarification, we got vague responses and when asking for more clarification, no response. I think pointing out some of the silly, artificial restrictions in software licenses might help the case for open-source software. 4. maybe you have, but also tell the audience, that the documentation of the code is very important. i.e. students can learn about the inner workings just as easily as they can write programs in sage (same language, ...). this strengthens the python language for general scientific usage and is not specific to sage. there is no dedicated technical barrier between users and developers. 5. future ... maybe also some general closing words about the scientific ecosystem of mathematics: by sharing code and implementations openly, the quality is higher and so on. this is trivial, but you could say that sage wants to push into that direction. (at least i think it wants to and this is point where sage doesn't want to copy the big M*s ;) h --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Comments on forum 'Free Mathematica-like program'
You might like to see the question on this forum, my reply and now the reply from the original poster. http://www.karakas-online.de/forum/viewtopic.php?p=33950#33950 At this moment, and I know these things change, typing free mathematiica into Google gives this as the #1 page. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Some new comments on Free Mathematica-like program on forum
You might like to see the question on this forum from 'mud' http://www.karakas-online.de/forum/viewtopic.php?p=3395 my reply (on second page) and now a comment from 'Chris Karakas (chris) At this moment, (and I know these things change), typing free mathematica into Google gives this as the #1 page. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: why sage is useful for me
On Jul 22, 11:17 am, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, I just wanted to share why Sage is (or will be soon) useful for me. 1) I have a program that I do for my master thesis, it's some finite elements method + electronic structure calculations and my boss gave me access to some solaris very fast boxes, Is that UltraSPARC or x86/x64 (i.e. AMD/Intel) based? I'd be interested what you have access to. So, mabshoff -- Solaris port +1. Me too wanting that. 2) There is a nonzero chance I'll be teaching some undergrad calculus stuff in a year or two and so I was thinking which programs (if any) I'd use and the constrain will probably be windows. Why should it be windows? I feel Windows has some advantages over Solaris or Linux for general office/home use. In particular, you don't need to be as computer savvy to do certain basic tasks, like install printers. But I feel Unix/Linux systems are a much better platform for scientific computing. If you use the principle of best tool for the job then I doubt Windows can be considered the best tool. Why encourage people to a system which seems to have dramatically increased in price in recent years and gets more and more bloated? When I bought my first PC, the hardware cost just over £2000 ($4000) and the operating system license was about £50 ($100). Now, the cost of the OS is a much higher percentage of the total cost. So, mabshoff -- Sage windows port +1. I know he is on to that. It's obvious that given the large number of windows systems, that it will increase Sage's popularity more than ports to Solaris, HP-UX or any other platform ever will. (Personally I'm more keen on Solaris port, but objectively one would have to say a Windows one would do more for Sage's popularity. And that is important.) So the above are rather side effects of the main Sage's aim, but those are things that would make my life much more easier. I just wish I'd had a decent open-source alternative to Mathematica when I started my MSc. Unfortunately I've used Mathematica on/off for the last 17-18 years, so have a lot of time spent using it. I'd rather not have to inflict that anyone else, so they get locked into a system. (I think Mathematica is a good system, just too expensive and proprietary). --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Package management and versioning
On Jul 21, 6:18 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Vincent, Quick and very dirty : 'find . -cmin -5' (files modified less than 5 minutes ago). Not even close :). There are packages that install in less than 10 seconds. That one was a joke, of course. I have used it occasionally for a punctual problem, but it's not for packaging. Ok, you can never be sure around here what people propose :) I am not so sure this is worth it. You are basically writing apt/rpm for user space. And we like to reuse components if they exist and fit the bill :) apt/rpm are way too big for my purposes, I am not even sure I want to consider dependencies between packages just yet. Well, my argument is that once you have the system in place sooner or later someone will suggest and/or implement dependencies and so on. That does not have to happen obviously, but people are packaging Sage for distributions where such mechanisms are already in place. But once you are there, you might as well keep the snapshot, add the package name as one of the file attributes, and bam you have a package management system ! But this is IMHO not KISS - a guiding principle of Sage :). Right now a fresh 3.0.6.alpha0 contains about 107235 files in $SAGE_LOCAL when following symbolic links. That is a lot of IO and disk seeks to do to upgrade for each package. Yes ! I totally agree with you, it is completely unacceptable to traverse the whole Sage directory at each package installation. Which is precisely why we need DESTDIR in every scenario I can think of. Once you have that and you keep track of package manifests for removal, you do in fact have the bare bones of a package manager. Ok, I kind of thought that I made the wrong assumption there and that my argument was slightly idiotic, but it was late and I was tired :) One thing that endlessly annoys me about rpm for example is its sluggish performance, which is largely rooted in its db backend, i.e. berkeley db IIRC. On top of that sqlite's performance sucks even worst. And you also introduce another point of failure where up to now KISS had provided a nearly perfect solution, i.e. any sort of db corruption will break Sage's upgrade system. About sluggish performance, I was in the train without a Sage installation but I started to play around with pysqlite. Given that mathematicians tend to keep on themselves (the extrovert ones are the ones that look at _your_ shoes ;-) :) I thought it was a good idea to package GNU hello for inclusion in Sage. I built a fake sage directory our of random parts, it has around 15k files. Built a sqlite database for it, and timed the hello-related commands : Extraction of the tarball : approx. 1.3 sec (oldish G4 powerbook, unplugged, bare with me ...) ./configure : 41 sec (yes, my laptop is old I told you) make : 6.4 sec (see above) make install : 7.5 sec (same time going to $SAGE_ROOT or to a staging directory) SPKG.insert : 0.4 sec (moves the files from staging to $STAGE_ROOT and updates the database) SPKG.remove : 0.4 sec (removes the installed files for hello, updates the database) So the overhead of the database appears to be minimal. Admittedly my directory is too small by an order of magnitude, but still I don't expect the overhead to grow out of bounds. I would call a 5% overhead at install time within the bounds of reason. Sure, overhead is one concern, but over-engineering another. One example (and I know this is not fair to compare your proposal) is the Windows registry. Sounds like a great idea until you realize that having config information in text files is much smarter in the long term. Another example is to stuff everything into XML files since it is so great and cool, but in the end the vast majority of situations is much better served by plain flat text files. So where is the benefit from using a database or even keep a list of the files? I just don't see it. * Updating one spkg often forces the update of another spkg. For example updating clisp forces a recompile of Maxima. So you cannot just switch between two clisp installs and expect things to work. And there are even more complicated dependencies in the default tree. As I said, I am not intending to manage package dependencies just yet, just removal. Ok. * The Sage library is special and there are loads of subtle dependencies. For example 3.0.3 to 3.0.4 upgraded LinBox from 1.1.5 to 1.1.6.rc0. A seemingly innocent update until you learn that this also means that the name of the wrapper library has changed. So running a 3.0.4 or later Sage library with a linbox-1.1.5 or earlier will cause Sage not to even start any more. In some cases it is imaginable that Sage does start but will exhibit subtle bugs since we fixed something in FOO-1.3.3.p12, but for some reason one user ends up running FOO-1.3.3.p11. Happy bug hunting in that case. (Then it appears that a
[sage-devel] Re: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
On Jul 22, 6:07 am, karakas [EMAIL PROTECTED] wrote: Hi, Here is part of install.log (I have set over more or less sensitive, or boring information): GCC Version gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs Configured with: ../configure --enable-threads=posix --prefix=/usr -- with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/ share/man --enable-languages=c,c++,f77,objc,java,ada --disable- checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib --with- system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) You need at least gcc 3.4 or higher to build Sage since we require c99. eclib itself does not need c99, but it is not supported to build the current release with gcc 3.4 or earlier. We do have a gcc check, but unfortunately that happens right before building FLINT which is past eclib. The issue is known and in the bug tracker already and I meant to take care of it, but had not had the time to do so. Sorry, hopefully in Sage 3.1 this will be fixed so that Sage tells you immediately that the compiler is not modern enough. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Status of Sage for Debian
On Jul 21, 7:44 pm, Timothy G Abbott [EMAIL PROTECTED] wrote: Hi Tim, I figured I'd give everyone an update on how things are going with the Sage packages. I believe (but am not certain) that all of the Sage dependencies that I want to get into Lenny will make it, though I'm still waiting on final review for 5 of them that had copyright problems in the past. On the other hand, Debian is freezing everything starting in around 5 or 6 days. So, I need to have a presentable Sage package in the very near future. There are currently a few showstopper problems: 1) Sage 3.0.4 or 3.0.5 built with polybori 0.5rc fails to find m4ri_build_all_codes and m4ri_destroy_all_codes. This is discussed in http://trac.sagemath.org/sage_trac/ticket/3264. Because this results in Sage not starting, I can't run tests against this version to find other problems. So I built Sage against the polybori spkg included in Sage (which has license problems that prevent me from using it in Debian). Martin, Michael B. and I talked about this issue and we are confident we can resolve the problem. The polybori.spkg you linked from the ticket seems to have some problems, but I will look into them hopefully tomorrow. 2) My current version of Sage 3.0.4 built with the 0.3.1 polybori spkg included in Sage passes most doctests, though it fails a large number of tests ending with a Runtime Error in sage/matrix/matrix_integer_dense.pyx (error output below). I'm guessing that linbox is totally not working. If you've seen a problem like this before (I'm running the new linbox 1.1.6rc), let me know. I would greatly appreciate any help debugging these issues. I can give out ssh access to a test VM with either version of my Debian Sage package installed on it if that would make debugging one of these problems easier. However, the VM's host is very loaded and thus things are quite slow; thus I suspect that (1) will be easier to debug using the patch attached to #3264. Hm, any chance you can get me logged into a box with that problem once the PolyBoRi issue has been taken care off. It does not ring a bell. I also wanted to let you know that we had to patch LinBox 1.1.6.rc0 slightly since it produced wrong results form charpoly mod p. You need to apply a one line patch to fix the issue - see #3671. I do not know if Clement plans to do an 1.1.6rc1 release of Linbox or not. -Tim Abbott Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: The ISSAC Sage Plenary talk
Hi, On Tue, 22 Jul 2008 08:44:22 +0200 Martin Albrecht [EMAIL PROTECTED] wrote: - In the three points explaining what Sage is more precisely you write that we have new code ... that unifies leaving the impression that all/most of our code is just interface stuff, i.e. the new implementations of algorithms etc. are not mentioned. I also think this should be emphasized. There are many people who think Sage is either wrapping functionality that is already there, or rewriting it to make it faster. It would be good to mention new algorithms/implementations that are just in Sage. I suppose becoming a viable alternative to the M's includes becoming a platform for development of new algorithms. It might be a good idea to show how Sage cites the papers where nontrivial algorithms are described in the doc strings as well. I like this example: sage: R = GF(2)['x'] sage: p = R.random_element() sage: p.small_roots?? I think Martin should have added his name to that with an AUTHOR tag. Maybe a non-cryptography related example would be better, since there also seems to be a feeling that Sage is mainly about cryptography. Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: why sage is useful for me
On Jul 22, 7:33 am, Dr. David Kirkby [EMAIL PROTECTED] wrote: On Jul 22, 11:17 am, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, Hi Ondrej, I just wanted to share why Sage is (or will be soon) useful for me. 1) I have a program that I do for my master thesis, it's some finite elements method + electronic structure calculations and my boss gave me access to some solaris very fast boxes, Is that UltraSPARC or x86/x64 (i.e. AMD/Intel) based? I'd be interested what you have access to. I could relatively painlessly build you a 64 bit self contained gcc, binutils, shellutils, python, ATLAS, numpy 1.1.1, scipy SVN and hg if you left me know the CPU target you want. I have to offer Sparc US IIIi, Core2 Quad SSE or Opteron. So, mabshoff -- Solaris port +1. Me too wanting that. 3.0.6 contains about five Solaris build fixes, so the list is getting shorter. We mainly did a stabilization release, so some of the more risky stuff was left out. 2) There is a nonzero chance I'll be teaching some undergrad calculus stuff in a year or two and so I was thinking which programs (if any) I'd use and the constrain will probably be windows. Why should it be windows? I feel Windows has some advantages over Solaris or Linux for general office/home use. In particular, you don't need to be as computer savvy to do certain basic tasks, like install printers. But I feel Unix/Linux systems are a much better platform for scientific computing. If you use the principle of best tool for the job then I doubt Windows can be considered the best tool. Why encourage people to a system which seems to have dramatically increased in price in recent years and gets more and more bloated? When I bought my first PC, the hardware cost just over £2000 ($4000) and the operating system license was about £50 ($100). Now, the cost of the OS is a much higher percentage of the total cost. Well, there is a vast people using Windows out there either by choice or because they don't know about alternatives. And Sage can only benefit from being portable. In the end it is all about bringing mathematical OS to the people and not convincing them to switch OSes. They will hopefully learn that Open Source is something good and high quality, but if other people use Windows I am perfectly fine with it. So, mabshoff -- Sage windows port +1. I know he is on to that. It's obvious that given the large number of windows systems, that it will increase Sage's popularity more than ports to Solaris, HP-UX or any other platform ever will. (Personally I'm more keen on Solaris port, but objectively one would have to say a Windows one would do more for Sage's popularity. And that is important.) So the above are rather side effects of the main Sage's aim, but those are things that would make my life much more easier. I just wish I'd had a decent open-source alternative to Mathematica when I started my MSc. Unfortunately I've used Mathematica on/off for the last 17-18 years, so have a lot of time spent using it. I'd rather not have to inflict that anyone else, so they get locked into a system. (I think Mathematica is a good system, just too expensive and proprietary). :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
On Jul 22, 8:12 am, mabshoff [EMAIL PROTECTED] wrote: On Jul 22, 6:07 am, karakas [EMAIL PROTECTED] wrote: Hi, Here is part of install.log (I have set over more or less sensitive, or boring information): GCC Version gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs Configured with: ../configure --enable-threads=posix --prefix=/usr -- with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/ share/man --enable-languages=c,c++,f77,objc,java,ada --disable- checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib --with- system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) You need at least gcc 3.4 or higher to build Sage since we require c99. eclib itself does not need c99, but it is not supported to build the current release with gcc 3.4 or earlier. Oops, the above should obviously state *gcc 3.3 or earlier*. Sorry for the mistake and the extra email. We do have a gcc check, but unfortunately that happens right before building FLINT which is past eclib. The issue is known and in the bug tracker already and I meant to take care of it, but had not had the time to do so. Sorry, hopefully in Sage 3.1 this will be fixed so that Sage tells you immediately that the compiler is not modern enough. Cheers, Michael Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jun 9, 2008, at 10:36 PM, mabshoff wrote: Okay, I can confirm that with sage 3.0.1, sage -gp has the same speed as my standalone GP build. So mostly likely the change to GMP 4.2.2 introduced a speed regression (probably the core 2 patches not being applied properly). Ok, I will investigate and made this a blocker for 3.0.3: #3388 As is the gmp.spkg with the Core2 patches and all that fun stuff is a giant mess including the OSX fixes made by William :) Let's hope MPIR is here sooner than later I just noticed that the slowness happens on amd64 as well, so probably Gaudry's patches are not being applied properly either. This is on alhambra (2.6GHz opteron): -- | SAGE Version 3.0.1, Release Date: 2008-05-05 | | Type notebook() for the GUI, and license() for information.| -- sage: x = ZZ.random_element(2^1000) sage: y = ZZ.random_element(2^1000) sage: time z = x * y CPU times: user 0.19 s, sys: 0.02 s, total: 0.21 s Wall time: 0.21 sage: time z = x * y CPU times: user 0.19 s, sys: 0.01 s, total: 0.20 s Wall time: 0.20 sage: time z = x * y CPU times: user 0.20 s, sys: 0.00 s, total: 0.20 s Wall time: 0.20 -- | SAGE Version 3.0.2, Release Date: 2008-05-24 | | Type notebook() for the GUI, and license() for information.| -- sage: x = ZZ.random_element(2^1000) sage: y = ZZ.random_element(2^1000) sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.42 s sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.41 s sage: time z = x * y CPU times: user 0.41 s, sys: 0.00 s, total: 0.41 s Wall time: 0.41 s david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage-3.0.5 Solaris-x86-sse3 binary
Speaking of Matlab, I was able to get version r2008a (most recent
version) working in a linux-2.6 zone using the CentOS 5 distribution.
I then installed RPyC 3.00 RC1 ( http://rpyc.wikispaces.com/ ) in both
the lx zone's copy of sage and in the native solaris sage
installation. I started up the RPyC server (which could be turned
into a daemon) in the lx zone:
sage: load rpyc_classic_server.sage # this is one of the server
scripts that came with RPyC, renamed to a .sage file
In the solaris client:
sage: import rpyc
c = rpyc.classic.connect(192.168.5.10) # 192.168.5.10 is the ip of
the linux zone
sage: c.modules.__main__.matlab('3+3')
6
Though I suppose this has some minimal use on its own as being a way
to call proprietary software not available natively on solaris while
still using native applications from sage (OpenGL visualization comes
to mind), I think a more common benefit would be in having a solaris
zone that is used to house a sage notebook server while not having to
sacrifice the ability to call proprietary software (from a lx zone).
Once I move in to my new apartment and have access to my sever again I
will try it out ... it doesn't look like it will be long before the
solaris port is adequate ;)
On Jul 16, 11:17 am, mabshoff [EMAIL PROTECTED] wrote:
On Jul 16, 1:33 am, Dr. David Kirkby [EMAIL PROTECTED]
wrote:
On 15 Jul, 23:48, mabshoff [EMAIL PROTECTED] wrote:
On Jul 15, 3:18 pm, Dr. David Kirkby [EMAIL PROTECTED]
According to ls -l, the file is 139557984 bytes long. Here's the
checksum:
Hi David,
$ digest -v -a md5 sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz
md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
5f206b211d29e5c49518de8982ac92bc
Whatever you downloaded is truncated:
Yes, I see that. I've got it going now, so it can be downloaded from
Europe OK, despite the mention of it now (In case you don't know, I'm
in the UK).
$ ./sage
--
| SAGE Version 3.0.5, Release Date: 2008-07-11 |
| Type notebook() for the GUI, and license() for information. |
--
The SAGE install tree may have moved.
Regenerating Python.pyo and .pyc files that hardcode the install PATH
(please wait at most a few minutes)...
Please do not interrupt this.
Setting permissions of DOT_SAGE directory so only you can read and
write it.
Ok, so far so good.
sage: notebook()
The notebook files are stored in: /export/home/drkirkby/.sage//
sage_notebook
There does not appear to be anything acting as a server on port 8000,
but I know you said there were bugs onSolaris, so I guess the GUI is
one of them.
Yes, it is a known issue to me. The notebook just sits there waiting
for entropy. I suspect this has to do with RAND_MAX onSolarisbeing
2^15-1 instead of 2^31-1. We had a similar bug in the randgen
framework which caused ZZ.random_element() to take between 3 and 8
seconds of CPU time to return 0 with probablity 1. On sage.math things
are a little quicker:
sage: %timeit ZZ.random_element()
100 loops, best of 3: 519 ns per loop
sage:
So those order of magnitudes are screwing us at the moment.
Since I have had half a dozen beers tonight, that might possibly be
the issues, but I doubt it. I'll try to download again.
Mothers against drunk downloading anyone? ;)
Yeah, it needs it.
:)
I would be interested in a SPARC version. The machine I have is a
Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That hasSolaris10, update 4
(August 2007).
That should be doable, the problem right now is that clisp on Sparc is
OK, well let us know when the SPARC looks more hopeful.
The ecls switch is very high up on my priority list since it is always
very needed for Sage on native Windows.
Like Vincent, I believe there would be interest fromSolarisusers who
do not subscribe here, but I think it would be premature to advertise
a binary inSolarisnewsgroups. Obvious places would be
comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
forums. I know there have been several Mathematica discussions on the
Solarisforums.
Sure, this is way too early. I would want to do that once Sage builds
actually pass doctest at least on theSolarisboxen I have access to,
not any time before that.
Though you should weigh that against the fact that there are some real
Sun experts on these places, that are good at debuggingSolaris
problems. It seems to me that might be what is needed now. Clearly you
don't want mathmaticians whose universities give them Sun boxes to
debug it, but Sun employees, or other Sun experts who have some
interest in maths software might be persuaded to look at the
problems.
I have no such problem letting anyone debug Sage onSolaris, but the
time has not come yet since right now I need to
[sage-devel] Re: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
Thank you very much for the clear and fast answer. Since upgrading gcc will probably mean an upgrading of glibc too, which will mean a recompilation/upgrade of the whole system, I guess it is better to postpone compilation until I finish my migration from SuSE to Gentoo (which is going to take a *long* time anyway the way things move (read: technology: fast, me: slow :-))). --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: why sage is useful for me
On Jul 22, 4:44 pm, mabshoff [EMAIL PROTECTED] wrote: Well, there is a vast people using Windows out there either by choice or because they don't know about alternatives. True, but I suspect the first year students under discussion should be aware of other systems such as Linux. They would have the choice to use Linux if they wanted. I can't believe it would be hard to find a Linux box in a university now if you wanted to use one. Even easier to install it on their own PC. And Sage can only benefit from being portable. Agreed - a Windows port is essential. More so than Solaris. In the end it is all about bringing mathematical OS to the people and not convincing them to switch OSes. I do not agree with you there! If Linux is a more suitable platform for scientific computing than Windows, it would be wise to encourage first year students to use Linux for scientific computing. Unlike staff working for most large corporations, students will not be tied to rigid corporate policies. They can install software on their own personal machines. I've spent the last couple of weeks doing scientific computing and I believe it would have been considerably more difficult under Windows than it was under Solaris. I've also spent a few days writing a scientific report under Solaris. I'm the first to admit, that would have been no more difficult, and perhaps even sligthly easier under Windows, especially as I had to use files Visio format files sent to me. I had to get a colleague to put them in a usable format. He could not use postscript (why I will never no), so I had to make do with PDF. Not ideal. But it would have been easier for me to just use Windows for that part of it. So I'm not proposing a blanket convince everyone to use Linux and scrap Windows, but I do believe if Linux/Unix is a better platform for scientific computing, then it is wise to encourage first year student to use Linux/Unix. They will hopefully learn that Open Source is something good and high quality, but if other people use Windows I am perfectly fine with it. I'm happy with it, but feel its unwise to enough it use for scientific computing to a group of individuals who have no compelling reasons (ie. corporate policy) to use Windows for scientific computing. Michael Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jul 22, 2008, at 12:35 PM, David Harvey wrote: Okay, I can confirm that with sage 3.0.1, sage -gp has the same speed as my standalone GP build. So mostly likely the change to GMP 4.2.2 introduced a speed regression (probably the core 2 patches not being applied properly). Ok, I will investigate and made this a blocker for 3.0.3: #3388 As is the gmp.spkg with the Core2 patches and all that fun stuff is a giant mess including the OSX fixes made by William :) Let's hope MPIR is here sooner than later I just noticed that the slowness happens on amd64 as well, so probably Gaudry's patches are not being applied properly either. This seems to have been fixed already in 3.0.5. Sorry for the noise. david --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel?hl=en -~--~~~~--~~--~--~---
[sage-devel] Re: why sage is useful for me
Well, there is a vast people using Windows out there either by choice or because they don't know about alternatives. True, but I suspect the first year students under discussion should be aware of other systems such as Linux. They would have the choice to use Linux if they wanted. I can't believe it would be hard to find a Linux box in a university now if you wanted to use one. Even easier to install it on their own PC. Just as a data point: While I was at City College in New York I started a project called Doyen to make a Live CD as a computer algebra platform. I advertised in the computer science department for 2 students with a knowledge of Linux for a paid position. Ten students showed up for interviews, all of them were computer science majors and most of them were seniors. Eight of the ten had not heard of Linux. This was 4 years ago. Things might have changed. Your school may vary. Tim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Status of Sage for Debian
On Tue, 22 Jul 2008, mabshoff wrote: On Jul 21, 7:44 pm, Timothy G Abbott [EMAIL PROTECTED] wrote: 1) Sage 3.0.4 or 3.0.5 built with polybori 0.5rc fails to find m4ri_build_all_codes and m4ri_destroy_all_codes. This is discussed in http://trac.sagemath.org/sage_trac/ticket/3264. Because this results in Sage not starting, I can't run tests against this version to find other problems. So I built Sage against the polybori spkg included in Sage (which has license problems that prevent me from using it in Debian). Martin, Michael B. and I talked about this issue and we are confident we can resolve the problem. The polybori.spkg you linked from the ticket seems to have some problems, but I will look into them hopefully tomorrow. Thanks to that effort, the polybori 0.5 problem seems to be solved. 2) My current version of Sage 3.0.4 built with the 0.3.1 polybori spkg included in Sage passes most doctests, though it fails a large number of tests ending with a Runtime Error in sage/matrix/matrix_integer_dense.pyx (error output below). I'm guessing that linbox is totally not working. If you've seen a problem like this before (I'm running the new linbox 1.1.6rc), let me know. I would greatly appreciate any help debugging these issues. I can give out ssh access to a test VM with either version of my Debian Sage package installed on it if that would make debugging one of these problems easier. However, the VM's host is very loaded and thus things are quite slow; thus I suspect that (1) will be easier to debug using the patch attached to #3264. Hm, any chance you can get me logged into a box with that problem once the PolyBoRi issue has been taken care off. It does not ring a bell. Sure. I'll send you a separate email with relevant instructions. I also wanted to let you know that we had to patch LinBox 1.1.6.rc0 slightly since it produced wrong results form charpoly mod p. You need to apply a one line patch to fix the issue - see #3671. I do not know if Clement plans to do an 1.1.6rc1 release of Linbox or not. There seems to be one additional nasty problem: When one runs sage on the command line, it just displays the banner and immediately quits. (I was seeing this on the version with the old polybori as well, but was hoping it would disappear). Oddly, doctests work normally and, I can run sage -sh and then run python and import Sage libraries and run tests and it all works. So, something is weird here. I dug into the various sage scripts to see where control was ending, and found that it seemed to be making it into the sage.mainloop line of sage-ipython. $ sage -- | SAGE Version 3.0.5, Release Date: 2008-07-11 | | Type notebook() for the GUI, and license() for information.| -- $ -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pari slowness
On Jul 22, 11:48 am, David Harvey [EMAIL PROTECTED] wrote: On Jul 22, 2008, at 12:35 PM, David Harvey wrote: SNIP This seems to have been fixed already in 3.0.5. Sorry for the noise. david Hi David, we reverted to the old gmp 4.2.1 spkg in 3.0.5 since the only reason to upgrade was to better support Cygwin and OSX 64 bit. Since both of those platforms are not ready for prime time we decided it would be the more prudent way to go. Obviously we want eMPIRe in Sage ASAP and I need to do my share to make this happen, so please remind me often :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: CUDA and Sage
On Jul 22, 2:55 pm, Simon Beaumont [EMAIL PROTECTED] wrote: Hi Simon, I decided to have a play with the pycuda-0.90.2 kit for which I needed boost_1_35_0 Mhh, is 1.35.0 mandatory? We might have to upgrade boost in PolyBoRi then. - the main caveat is to make sure boost is using the sage python include, lib and executable rather than any system installed python. Similarly configure pycuda. My sage server runs as user sage - so I had to run the x server under sage. (I am looking into how to get the nvidia drivers loaded without x). Ok, please let us know what you find out. Upshot is low level api works like a charm from sage notebook (sage 3.0.4 built under gentoo on amd64 h/w). Since I don't need the full BLAS library and I have some optimal kernels that do sgemm better than the library version then I might have a play with this for a while and see what I run into. Yeah, even sgemm could be useful and it would be nice if you could get some numbers of sgemm on the CPU vs. the GPU. Once the IEEE conform hardware is out things will become a lot more interesting. Cheers, Simon Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage-3.0.5 Solaris-x86-sse3 binary
On Jul 22, 10:17 am, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi Brandon
Speaking of Matlab, I was able to get version r2008a (most recent
version) working in a linux-2.6 zone using the CentOS 5 distribution.
I then installed RPyC 3.00 RC1 (http://rpyc.wikispaces.com/)
Interesting, I had never heard of RPyC, but it will likely be of some
interest to some of the people around here.
in both
the lx zone's copy of sage and in the native solaris sage
installation. I started up the RPyC server (which could be turned
into a daemon) in the lx zone:
sage: load rpyc_classic_server.sage # this is one of the server
scripts that came with RPyC, renamed to a .sage file
In the solaris client:
sage: import rpyc
c = rpyc.classic.connect(192.168.5.10) # 192.168.5.10 is the ip of
the linux zone
sage: c.modules.__main__.matlab('3+3')
6
Cool. There is also some code IIRC that let's you use ssh to open a
tunnel to another box to execute commands in some supported
application there. It has been a while, but I believe they also used
Matlab.
Though I suppose this has some minimal use on its own as being a way
to call proprietary software not available natively on solaris while
still using native applications from sage (OpenGL visualization comes
to mind), I think a more common benefit would be in having a solaris
zone that is used to house a sage notebook server while not having to
sacrifice the ability to call proprietary software (from a lx zone).
I am very interested in providing a Solaris Zone with Sage since
isolating the notebook into its own little corner of the system is an
excellent idea. If you have some expertise in that area I would be
glad if you could help out there.
Once I move in to my new apartment and have access to my sever again I
will try it out ... it doesn't look like it will be long before the
solaris port is adequate ;)
Yeah, I am really hoping that William and I will sit down this
Thursday and/or Friday and spend some time nailing down some of those
pesky Solaris bugs. It looks like we now have a solution to a sympow
problem, so hopefully another bug just bit the dust.
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: CUDA and Sage
I decided to have a play with the pycuda-0.90.2 kit for which I needed boost_1_35_0 - the main caveat is to make sure boost is using the sage python include, lib and executable rather than any system installed python. Similarly configure pycuda. My sage server runs as user sage - so I had to run the x server under sage. (I am looking into how to get the nvidia drivers loaded without x). Upshot is low level api works like a charm from sage notebook (sage 3.0.4 built under gentoo on amd64 h/w). Since I don't need the full BLAS library and I have some optimal kernels that do sgemm better than the library version then I might have a play with this for a while and see what I run into. Cheers, Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: CUDA and Sage
On Jul 22, 11:18 pm, mabshoff [EMAIL PROTECTED] wrote: On Jul 22, 2:55 pm, Simon Beaumont [EMAIL PROTECTED] wrote: Hi Simon, I decided to have a play with the pycuda-0.90.2 kit for which I needed boost_1_35_0 Mhh, is 1.35.0 mandatory? We might have to upgrade boost in PolyBoRi then. From the pycuda docs this would appear to be the case: ...You may already have a working copy of the Boost C++ libraries. If so, make sure that it’s version 1.35.0 or newer... Ok, please let us know what you find out. I'll keep this topic posted. Yeah, even sgemm could be useful and it would be nice if you could get some numbers of sgemm on the CPU vs. the GPU. Once the IEEE conform hardware is out things will become a lot more interesting. I'm digging out the custom kernel now - so I should get something very soon. (I did integrate the CUDA BLAS library sgemm into mathematica ealier this year - so I have some numbers on that also of course mathematica suffers badly from the mlink serialisation) Cheers, Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
