[sage-devel] Axiom Wiki and Axiom Portal
Dear Axiom Fans, The move of the Axiom Wiki and the Axiom Portal that was announced last month is now nearly complete. Monday, November 26 is the official date for the release of the new Axiom Wiki: http://axiom-wiki.newsynthesis.org and the new Axiom Portal http://axiom-portal.newsynthesis.org which is now hosted on the Sage server operated by William Stein at the University of Washington. On Monday the old urls: http://wiki.axiom-developer.org ** obsolete ** and http://portal.axiom-developer.org **obsolete ** will be automatically re-directed to the new sites. Later that week, all wiki and portal files will be removed from the axiom-developer.org server. Tim Daly has plans that he will announce separately for re-allocating resources on this server to focus on the goals of the original Axiom project. The new site is intended to support all three Axiom-related projects (the original project plus OpenAxiom and the FriCAS forks), as well as Aldor as a library compiler for Axiom. In addition to Axiom the wiki and portal include interfaces for Reduce, Maxima and Sage. It also supports pages containing noweb literate programs (pamphlets) and graphics generated by graphviz. All bug reports and issues from the old wiki site have been transferred to the new site and an updated version of the customized Topic navigation has been implemented at the new site (left sidebar). The only feature that has not (yet) been implemented at the new site is the point-and-click assistant extension of the edit and comment forms. I am not certain whether this feature is really desirable since in increases the size and there for the rendering time of every page on the site. I would be glad to receive opinions about this. If find any of your favorite pages from the old site are missing at the new site, there is still time to transfer the page source from old to the new. If you need help with doing this just let me know. Some of the pages on the new axiom-wiki site do not yet reflect the current state of the Axiom-related projects. Your help in updating the pages at the new axiom-wiki site would be greatly appreciated. If your were registered as a user of the old Axiom Portal site, your account has *not* been automatically transferred to the new site. If you have some files or other content that you wish to preserve and transfer to the new site, please register at the new site: http://axiom-portal.newsynthesis.org and if necessary ask me for help in transferring the content. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [Axiom-developer] Re: AMS Notices: Open Source Mathematical Software
On 11/26/07, M. Edward (Ed) Borasky wrote: > ... > Well ... if you mean "*Red Hat* Linux has won a significant market > share in servers", I agree. However, I don't think as a user that either > Firefox or OpenOffice are of sufficient quality or maturity to be used > on a Windows desktop, and I don't consider what they have > accomplished to be a "win". They just aren't viable alternatives for > anything but casual home use. I use them on Linux because they > are there, but they aren't on my Windows desktop at work and > probably never will be. > ... I cannot imagine how you could reach that conclusion. As a user of both Microsoft products and FireFox and OpenOffice on Windows in a production work environment I consider OpenOffice and FireFox very clearly superior to what Microsoft produces. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.14 on Solaris
On 11/27/07, mabshoff wrote: > ... > Since there seem to be at least 3 or 4 people interested in Sage > on Solaris I am willing to roll up some binaries, at least for Sparc > and maybe later for Intel. Let me know if you are interested - and > complain if you find things that are broken. Patches welcome ;) > I am interested in Sage binaries on Solaris 10 for both Sparc and Intel. Please let us know when and where you have a chance to do this. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: build failure using clisp
On 12/5/07, mabshoff wrote: > > The build fails on OSX without that option. Interestingly enough we do > not run makemake with the recommended options. I "fixed" that once a > couple months ago, but we reverted the changes because of the above > mentioned breakage on OSX. > > clisp 2.43 is out and updating clisp has been on my lisp of things to > do for a while. (see #1002) > > On Dec 5, 6:06 pm, William Stein wrote: > > If you can remove that option *and* get the clisp spkg to build on the > > sage-supported platforms (as defined in the readme), then the dynamic > > ffi could be added back into the Sage lisp. > > > I tried that but the modified 'clisp-2.41.p11.spkg' does not build apparently because the src directory does not contain everything necessary to build ffi. > We should do that during the update to 2.43. Any volunteers? > Well, so far I can confirm only that the following modified spkg: http://sage.math.washington.edu/home/page/clisp-2.43-alpha.spkg which is based on clisp-2.43 as distributed by the clisp project, installs in Sage running on sage.math and it can re-build (-f ...) maxima-5.13.0.p1, axiom4sage-0.3.1 and the full version of FriCAS (rev: 134). I did only a fairly mimimal change to 'clisp-2.43-alpha.spkg' to eliminate all patches and adapt to the slightly changed build process (no intermediate makemake step necessary). FFI is automatically included. It it quite possible that this version may not build on OSX etc. however I know that the clisp developers have made some significant improvements in the build since 2.41. I would be glad in anyone can try this 'clisp-2.43-alpha.spkg' and let me know what works and what doesn't. Also please feel free to take the above and run with it. ;-) Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: build failure using clisp
William, Do you recall why you explicity set the following option: ./makemake --without-dynamic-ffi ... in clisp-2.41.p11/spkg-install ? Is it required for some other parts of Sage? For the purposes of building the full version of Axiom using clisp it is necessary to allow '--with-dynamic-ffi'. Regards, Bill Page. On 12/5/07, Waldek Hebisch <[EMAIL PROTECTED]> wrote: > > Bill Page wrote: > > While trying to build fricas: > > > > [EMAIL PROTECTED]:~$ cd ~/fricas-src > > > [EMAIL PROTECTED]:~/fricas-build$ cd ~/fricas-build > > > > using clisp: > > > > > Features: > > (REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP > > LISP=CL > > INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT > > UNICODE > > BASE-CHAR=CHARACTER PC386 UNIX) > > My version of Clisp gives: > Features: > (READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL > COMMON-LISP > LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI > GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) > > Note that FFI is absent in version on sage, but present in my (standard) > version. > > > C Modules: (clisp i18n syscalls regexp) > > Installation directory: /home/page/sage-2.8/local/lib/clisp/ > > User language: ENGLISH > > Machine: X86_64 (X86_64) sage.math.washington.edu [128.208.160.191] > > > > [EMAIL PROTECTED]:~/fricas-build$ ../fricas-src/configure > > --prefix=/home/page/local --with-lisp=clisp > > ... > > [EMAIL PROTECTED]:~/fricas-build$ make > > > > I get the following error: > > > > ... > > Bootstrap object copy > > Checking for foreign routines > > AXIOM="/home/page/fricas-build/target/x86_64-unknown-linux" > > spad-lib="/home/page/fricas-build/target/x86_64-unknown-linux/lib/libspad.so" > > sock-fasl="/home/page/fricas-build/target/x86_64-unknown-linux/autoload/ffi-func2.lisp" > > foreign routines found > > ;; Loading file > > /home/page/fricas-build/target/x86_64-unknown-linux/autoload/ffi-func2.lisp > > ... > > *** - READ from > ># > > > #P"/home/page/fricas-build/target/x86_64-unknown-linux/autoload/ffi-func2.lisp" > > @4> > > : there is no package with name "FFI" > > Yes, apparently FFI is not present. Graphic and HyperDoc require > FFI. I am not sure if we should seriously support clisp without FFI... > We could try to detect lack of FFI in installed clisp (but we do not > try to detect lack of FFI in other Lisps, where in theory one can also > omit FFI). > > -- > Waldek Hebisch > [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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage-2.9.alpha1 released
On 12/6/07, mabshoff wrote: > > The clisp update didn't work out due to a known issue with > gcc 4.2.3 with Debian testing on x86. So I reverted back > to clisp-2.41.p11.spkg. :-( Michael, do you mean that this is a problem known to the clisp developers? If so do you know if they have developed a work around? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage-2.9.alpha1 released
On 12/6/07, mabshoff wrote: > ... > You might want to let Sam & Bruno know that we are counting on > them :) > Right. Thanks! > What we can do is offer clisp-2.43.spkg as experimental, so > that people who want to install FriCAS or OpenAxiom can > install it and cross their fingers that it works. > +1 Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] sage package
Martin, You are right. The version of axiom4sage (fricas4sage) is a bit old and based on only the first experimental release of the Lisp caching scheme implemented by Waldek. It is time to update it. But do you think maybe we should wait until Waldek declares the next official release of FriCAS or base it on the last official release? I think that one of these two options would be better than just building a new fricas4sage from the current version in trunk (since that remains a moving target). What do you think? In principle doing a new fricas4sage release is fairly easy. First you need to generate a cached Lisp distribution and then just replace the contents of the source directory in the fricas4sage.spkg (tgz format) file. There are a few things that should also be done in the 'axiom.py' interface code: 1) the hack to disable readline in clisp is required in order to run FriCAS built with clisp to run properly on some systems. 2) I really really would like to include a new method to allow sage to compile spad programs. 3) It would be great to have standard mechanism to build and install optional Axiom/FriCAS packages, e.g. JETbundles and PAFF. Also, it would be great to allow the 'axiom.console()' command to start the *full* version of FriCAS including HyperDoc and Graphics. Unfortunately this requires building FriCAS using a newer version of clisp than what is currently distributed with Sage. Finally, I would like to hear from anyone else actually wanting to use Axiom/FriCAS in sage. Regards, Bill Page. On 17 Jan 2008 20:28:49 +0100, Martin Rubey <[EMAIL PROTECTED]> wrote: > > Dear Bill, > > I try to push it a little: do you think you could make a new fricas package > for > sage. It seems to me that the last one is already a bit dated, isn't it? It > seems to be from last July. > > I'm afraid, we missed the current sage release, although I doubt that it > matters. > > Many thanks, > > Martin > > > > > --~--~-~--~~~---~--~~ 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 package
On 1/17/08, mabshoff <[EMAIL PROTECTED]> wrote: > > [I am not CCing the FriCAS google group since I am not subscribed] > > On Jan 17, 10:44 pm, "Bill Page" <[EMAIL PROTECTED]> wrote: > ... > > > > In principle doing a new fricas4sage release is fairly easy. First you > > need to generate a cached Lisp distribution and then just replace the > > contents of the source directory in the fricas4sage.spkg (tgz format) > > file. There are a few things that should also be done in the > > 'axiom.py' interface code: 1) the hack to disable readline in clisp > > is required in order to run FriCAS built with clisp to run properly on > > some systems. > > Sage installs readline per default in $SAGE_LOCAL > I am sorry. Could you please explain how this applies or helps? The problem to which I was referring is that readline as compiled and linked into clisp can not be disabled through any command line option. readline when used with pexpect (on some machines) seems to cause problems with the 'axiom.py' interface. Discussions with Sam Steingold about this problem lead to his suggestion that we can disable readline for programs built with clisp by ensuring that stdin and stdout refer to different streams. Doing this solves the problems that have been reported when using axiom4sage (fricas4sage) on some platforms. The problem also does not occur for Axiom built using GCL when readlib support is disabled. Unfortunately I have to been able to provide Sam with a simplified test environment which demonstrates the problem so as of this date he has not considered this a bug in clisp. > 2) I really really would like to include a new method to > > allow sage to compile spad programs. 3) It would be great to have > > standard mechanism to build and install optional Axiom/FriCAS > > packages, e.g. JETbundles and PAFF. > > > > Also, it would be great to allow the 'axiom.console()' command to > > start the *full* version of FriCAS including HyperDoc and Graphics. > > Unfortunately this requires building FriCAS using a newer version of > > clisp than what is currently distributed with Sage. > > Note that we renamed the clip binary into clisp.bin in order to make > %clisp work when the sage directory has been moved. We fixed maxima, > but obviously nobody fixes the FriCAS optional spkg. > How can I reproduce this problem with the FriCAS optional spkg? Thanks. Regards, Bill Page. --~--~-~--~~~---~--~~ 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] [the Algebraist Network] Your user profile at Algebraist
Bill Page from the Algebraist Network has sent you a message: First of all, thank you to everyone for your interest and participation in Algebraist! Algebraist on crowdvine.com is intended as a "social network" between developers and users of Aldor as well as a front-end to other developer and user resources for Aldor. To that end, I think it would facilitate interactions if everyone could provide some basic information in their online profiles. I understand of course most people's reluctance to expose too much personal information about themselves to the Internet but I believe that there is a need also to be recognized for work done and to establish contacts on subjects of mutual interest. It is necessary to find a balance between these concerns and objectives that works for you. If you haven't done so already, please login and review your profile information on the "My Profile" tab at: http://algebraist.crowdvine.com There you can find links to * edit profile * edit answers * add external feeds * add a post If you have any questions about how to use these features, please let me know. I would also be especially grateful if the users of the Algebraist Network would find some time comment to other users about their interests. To do this you can find other people with common interests by clicking on the tags found on the right hand column, e.g. "Axiom", "category theory", "Python", etc. Click on their image or icon to view their profile and then leave them a message by clicking "+ add a comment". This is how conversations get started. You can of course add a "blog" entry of your own (see "add post" on you own profile page as mentioned above). These messages and blog entries will be visible to other users of Algebraist when they visit the Home page. Finally, I would like to strongly encourage you to make the Algebraist Network grow! If you know of other people who might be interested in joining Algebraist please invite them to join us by going to the "My Network" tab and click on "invite friends". A large network of interested users and developers could be a great benefit for the long term prospects of projects such as Aldor. Cheers, Bill Page. - http://algebraist.crowdvine.com http://algebraist.crowdvine.com/profile/12668 --~--~-~--~~~---~--~~ 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: Project
On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: > ... > I do not doubt that gcl is a good tool, but I doubt it is a good tool > to use in Sage. > ... > > > In the end it all boils down to platform support and I see ecls as > > > the silver bullet here for Sage+lisp. > > > Tim Daly wrote: > > I have no idea why you think ECLS is a silver bullet. Three years > > ago I moved Axiom onto the handheld Zaurus using GCL. ?? The Debian arm version of Axiom installs on Zaurus without problems. As far as I know all of the Debian Axiom builds were done by Camm Maguire who is also the primary maintainer of GCL. > > And many years ago I moved Axiom onto DOS 3.0 using GCL. Maxima > > runs (fast) using GCL. Why do you want to move off that platform? It > > contains everything you need, it builds from source, it is actively > > maintained, and is very fast. > I am not so sure one could honestly say that "it is actively maintained", but I would have to agree that Camm Maguire is usually very responsive. > No, it fails to build on Solaris and since Sage on Solaris is of > essential importance we will/cannot use it. That is strange. I have built recent versions of GCL from cvs on Solaris 10 - both sparc and x86 - without problems. I am using the gnu tool chain from Blastwave. Have you contacted Camm Maguire about the problems you are having? > ... > I just works with little need to do have a magic lisp machine working > since it uses a C compiler directly. > GCL uses the C compiler directly. I am not suggesting that GCL is necessarily the "right" lisp for Sage (or even that Sage needs a lisp compiler at all) but I do rather think you should give GCL another try. I would be glad to try to help you debug the problems on Solaris. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: Project
On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote: > ... > In the defense of GCL, *most* components of Sage were a mess > like above when I/you/whoever first tried to add them to Sage. > I personally haven't tried much using cvs GCL only, partly because > it scares me to use cvs for a deployed quality product. Since cvs > might be broken one day, not the next, etc., and one has no clue > if the code has been tested or not or what. The last released > version is from 2005, and it's clear the website is just dead (maybe > somebody lost the password?!) I mean, it just looks a little silly > for the website (http://www.gnu.org/software/gcl/) to start with: >NEW! (20050810) GCL 2.6.7 is released. The release notes can > be found here. > ... > The GCL-devel mailing list has on average about 5-6 messages > a month during the last couple of months, except for a bunch of > messages in January about people trying to build GCL from cvs. > No doubt about it - GCL does not have sufficient resources for maintenance and has been somewhat neglected of late. As you say: It is not a situation that you find entirely uncommon among the packages that have been added to Sage in the past. Necessity is what drives most of this kind of work. > I've made a gcl Sage optional spkg: > >http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg > > It's just GCL-from-cvs + a simple spkg-install. I have never got it to > build on any system. It's a pretty big spkg, since it appears to > include the entire gas assembler, some version of GMP, etc. Try > it out and see if it *doesn't* work for you too :-) > >wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg >sage -i gcl-20080421.spkg > Thanks. It doesn't work for me either. :-( You are right that the source is bloated by a bunch of code that it does not use. As I understand it gcl needs only a small part of binutils - depending on the build options for a particular system. Is this source from cvs head at: http://savannah.gnu.org/projects/gcl/ as of today? This version of GCL fails on my Solaris x86 system with the following obscure error message: gcc -c -fsigned-char -pipe -Wall -O3 -fomit-frame-pointer -I/export/home0/wspa ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c cmpaux.c: In function `object_to_fcomplex': cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function) cmpaux.c:329: error: (Each undeclared identifier is reported only once cmpaux.c:329: error: for each function it appears in.) cmpaux.c: In function `object_to_dcomplex': cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function) gmake[1]: *** [cmpaux.o] Error 1 rm list.c gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o' gmake: *** [unixport/saved_pre_gcl] Error 2 --- At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl' I see changes as recent as 3 months ago. The last time I built GCL from head was about 10 months ago. The most recent branch 'Version_2_6_8pre' is what we normally use to build Axiom. There is a change about 4 months old. If I recall correctly 'Version_2_6_8pre' actually corresponds to the version distributed on Debian and would probably be the most likely to be stable on the largest number of platforms. > Bill Page -- I would be interested in any comments you might have. > For example, is the fact that GCL doesn't build for us anywhere, > something that you think we'll get passed by just trying harder? > Or is it going to be really really hard. > The fact that it doesn't build for you anywhere is definitely strange. I would give it a try again with $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gcl co -r Version_2_6_8pre gcl I do expect that (with the right help) you will be able to build gcl everywhere that you build Sage. Instead of just trying harder I think it is very appropriate to ask for help. Only if there is no help forthcoming, perhaps I would agree that the problems might be of a kind that you will not be able to get passed just by "trying harder". I expect that like me, you would find the learning curve for the GCL source code very high. -- Now since you asked, maybe I should take a deep breath and try to explain my personal views on this subject... I am in fact fully sympathetic with the expressed desire to eliminate Lisp from Sage. As you may know, I am also in favor of eliminating Lisp from Axiom! I believe that was the direction in which Axiom was headed when it was last sold as commercial software and would have very much preferred it if that development had continued. The Aldor compiler (written in C) was positioned to replace the exising library compiler for Axiom. Aldor could be tar
[sage-devel] Re: Project
Michael, Wow, it sure it nice to have someone on the "other end of the phone", so as to speak ... :-) I think it is really great that Google came through with financial support that is making it possible for you and others to dedicate so much time to this. On Tue, Apr 22, 2008 at 2:41 AM, mabshoff wrote: > > On Apr 22, 7:36 am, "Bill Page" wrote: > ... > > The most recent branch 'Version_2_6_8pre' is what we normally > > use to build Axiom. There is a change about 4 months old. If I > > recall correctly 'Version_2_6_8pre' actually corresponds to the > > version distributed on Debian and would probably be the most > > likely to be stable on the largest number of platforms. > > At least testing ships CVS head. Are you sure? I suppose that we had better check with Camm. > And not to be too picky here: The last tarball from the website > predates OSX 10.5 and also Solaris 10, so maybe it is time to > cut another bug fix release since everybody seems to be using > 2.6.8CVS anyway. Yes, 2.6.8pre (as in pre-release). 2.6.8 was never "officially" released. > But when I build stable releases I do not poke around in the CVS > repo. Asking could have helped, but if nobody bothered to update > the website in three years anyway what is the point? 2.6.7 actually > also miserably fails on Solaris 9 for me, and that has been out for > a while before 2.6.7. > This is open source age and GCL existed well before that. I am not making excuses but ... > ... > Well, since the Maxima folks now have told us that they will > support ecls soon the decision has been made on our end to > switch to Maxima +ecls. Choose your own poison. ;-) Actually I don't know much about ecl but I seriously doubt the long term viability of ecl will be any different than the half dozen other alternatives. Of course I am all for co-operation between projects so if Maxima is willing to make a version that is more suitable for use in Sage, the more power (money and resources ...) to them! :-) > There is no point in beating the dead horse that is gcl. I take offense. gcl is not a dead horse no matter how neglected it might look to you. > ecls has MSVC support *today* and is probably trivially to port to > Sun Forte if it doesn't run already. The mailing list is alive and well. > I have looked at the code and fixed some issues myself, so why > would I want to touch gcl? > I don't know. The OpenAxiom and FriCAS forks of Axiom work on ecl so I am also not too worried about gcl in the long run. > > --- > > > > Anyway, none of this solves the immediate problem of providing > > support for symbolic mathematics in Sage without adding the > > burden of supporting Lisp in all target environments. Right now > > you depend on the linkage with Maxima for this feature, And I > > think you see symbolic manipulation as a particular domain or > > mode of computation within Sage rather than the reason d'etre > > of computer algebra systems. > > > > I would like to argue however that from an overall design perspective > > Axiom is a better match for Sage than Maxima. Like Sage itself, > > the Axiom library is built-up in a (more or less) rigorous manner > > from more fundamental mathematical constructions. One of these > > complex constructions is called 'Expression'. This is the domain > > in which most symbolic calculations are done in Axiom. However > > as it will be in Sage, it is necessary that Expression interact in > > a well-defined manner with other Axiom domains of computation. > > I believe that if you were to re-implement the Maxima symbolic > > functionality within Sage (Python) then you would essentially be > > implementing something rather similar to the Expression domain > > in Axiom. > > > > In the longer term (pending resolution of the remaining open > > source license issues), Aldor could provide much of the same > > set of functionality of Axiom through it's BasicMath and other > > libraries without the overhead of the Axiom interpreter interface. > > This would completely eliminate the need for Lisp. I still have > > some hope that this could happen in the near future. If Sage > > were to pursue this path, I think the Aldor license issues might > > be resolved more quickly. > > Well, I think NAG chose the "non-commercial only" license on > purpose. Well yes, of course it was on purpose. They have stated that they felt obligated to do this by the terms under which they originally received Axiom (and Aldor) from IBM. NAG itself is a non-commerical organization. > We have discussed the
[sage-devel] Re: Project
On Tue, Apr 22, 2008 at 3:25 PM, mabshoff wrote: > > I googled for it and it seems lenny is using 2.6.7 while sid is using > 2.6.7-36.1. So I might have gotten my wires crossed with unstable > here. So my bad. Beware of the release numbering. The most recent reference I could find is: http://lists.gnu.org/archive/html/gcl-devel/2008-01/msg2.html "2.6.8pre by contrast is nearer at hand. I do think we will need a windows installer for this release. I'd also like a working mac intel port. Otherwise, the image (packaged as Debian gcl-2.6.7-36) is carrying axiom, maxima, acl2, and hol88 to all 12 Debian platforms." So I guess as of January this year Debian "2.6.7-36.1" was actually "2.6.8pre" in cvs. > But it still raises the point that the website should either > have snap shots or a pointer to the Debian page. I know that > Camm is heavily involved with Debian, so I knew where to look > after the 2.7CVS failed for me the first time I checked it eight > months or so ago. > Yes it would be nice to have accurate up to date information at the gcl website. Maybe a wiki would be nice but it still takes someone with time and motivation. > > ... > > > Well, I think NAG chose the "non-commercial only" license on > > > purpose. > > > > Well yes, of course it was on purpose. They have stated that they > > felt obligated to do this by the terms under which they originally > > received Axiom (and Aldor) from IBM. > > Odd, IBM as a whole seems to be very OS friendly, but in reality > it somewhat depends on the unit you deal with. > I also suspect that if it were possible to approach IBM about the license situation with Axiom and Aldor now, one might obtain a different picture than the one presented by NAG. But NAG's relationship with IBM was circa 1995 and this is now. Different people are involved. > > > NAG itself is a non-commerical organization. > > Well, be that as it may, but their numerical library isn't free. Therein lies the rub. Originally, acquiring Axiom was a way for NAG to package and market it's numerical library. They did a *lot* of work to link Axiom to the numerical library - all of which was lost in the open source version of Axiom. When the numerical library was licensed to Maple circa 2000, NAG found themselves in a bit of a conflicted position. > ... > Nope, I am fully aware of "the power of Sage." But "let's get $FOO > into Sage" is not the solution and will not magically make a project > better. > It seems to me that my proposal for the place that Axiom/Aldor could have in Sage has more depth to it than that... :-( > ... Regards, Bill Page. --~--~-~--~~~---~--~~ 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: Project
On Tue, Apr 22, 2008 at 10:42 AM, William Stein wrote: > > On Tue, Apr 22, 2008 at 6:50 AM, Bill Page wrote: > ... > > I should also admit that most of my rant in the previous email > > was in fact a prelude to asking William to try to intervene with > > NAG on our behalf precisely become of this new found > > influence. > > Interesting. I think you have a point -- in connection with Sage > we have successfully got I think about 10 or more projects now > to go GPL-compatible (GPL or BSD). I think this is really good > for the open source math software community. [Note: many of > these packages are fairly specialized math software programs > or libraries, but are very very important to researchers in those > area.] > > Will there be any NAG people at ISSAC in Austria this summer? > I'll be there. > I also plan to be there. http://www.risc.uni-linz.ac.at/about/conferences/issac2008 I think it is great that you were invited to present at ISSAC. As you probably know, the ISSAC meetings have a very long history with ACM. http://www.sigsam.org/issac/ I believe that your presentation of Sage at this meeting should be considered a significant milestone for Sage! :-) I am quite sure there will be several people from NAG at ISSAC 2008 but I cannot name names right now. Following ISSAC there will also be a meeting specifically about Axiom and Aldor. A very preliminary draft announcement (not yet formally announced) is here: http://axiom-wiki.newsynthesis.org/SandboxWorkShopRISC2008 I will be there. I think it would be great if you and anyone else interested in Axiom and Aldor could also be present. For more information please contact Ralf Hemmecke or Martin Rubey. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: FriCAS/Open-Axiom and SAGE
On Wed, Apr 23, 2008 at 4:28 AM, Michael.Abshoff wrote:
>
> Martin Rubey wrote:
>
> > I do not see how the problem of differing representations can be
> > resolved. Up to now I thought that Sage simply doesn't have an
> > "internal" representation, and just uses the one from the external
> > program - that's how my polymake interface for FriCAS/Axiom
> > works.
>
> I am not 100% clear, but I believe for elements in a symbolic ring
> we do not yet have a Sage internal representation. It is being written
> in Cython since arithmetic is probably slowed down by a factor of
> 10,000 by using pexpect+Maxima. That is largely the fault of pexpect.
>
I think that what Martin means is that if Sage has it's own internal
representation of something then the problem of converting from one
representation to another is unavoidable if the symbolic manipulation
is done by an external program. This is independent of whether one
uses the pexpect interface or not. Of course if symbolic manipulation
is implemented in the Sage interpreter or compiled Cython code, then
this conversion may not be necessary. However it is sometimes
convenient also to change the internal representation depending on the
type of manipulation to be done.
So far as I can see Sage does have an internal representation for
"Symbolic Ring".
But the idea of a "Symbolic Ring" seems very strange to me. What is
this from a mathematical point of view? How is it different from, say,
a polynomial? Do you really mean that the variables of the ring do not
commute as in the sense of a free algebra?
http://en.wikipedia.org/wiki/Free_algebra
I worry sometimes that the Sage type system is a little too ad hoc... :-(
Anyway, here is an example computation that includes conversion from
the internal Sage representation to the internal Axiom representation
of a symbolic object:
[EMAIL PROTECTED]:~# sage
--
| SAGE Version 3.0, Release Date: 2008-04-22 |
| Type notebook() for the GUI, and license() for information.|
--
sage: # Construct some symbolic expression in Sage
sage: var('a b c d')
(a, b, c, d)
sage: A = matrix([[a,b],[c,d]])
sage: A
[a b]
[c d]
sage: x=det(A)
sage: x
a*d - b*c
sage: x.parent()
Symbolic Ring
sage: x?
Type: SymbolicArithmetic
Base Class:
String Form:
a d - b c
Namespace: Interactive
Docstring:
Represents the result of an arithmetic operation on
f and g.
sage: # Convert it to an object in Axiom
sage: y=axiom(x)
sage: y
a*d+(-b*c)
sage: y.type()
Polynomial Integer
sage: y?
Type: AxiomElement
Base Class:
String Form:a*d+(-b*c)
Namespace: Interactive
Docstring:
a*d+(-b*c)
> ...
> So: What should you do:
>
> a) wait a week or two for ecls and gdbm to become optional
> b) build an optional FriCAS/OpenAxiom spkg using ecls
> c) write a pexpect interface to use integration/ODE/guess if that
> is something where you see FriCAS/OpenAxiom as "better
> than anything else".
>
> In parallel take a look at
>
> http://wiki.sagemath.org/spkg/InclusionProcedure
>
> and write some proposal *why* FriCAS/OpenAxiom should become
> part of standard Sage and *what* it should/can [via pexpect] do.
> ...
Martin I would be interested in working with you on doing this (and
anyone else who would like to join in), that is provided you are
willing to take the lead. :-)
> Then eventually it will come down to the vote and if for example
> FriCAS beats Maxima and the 4Ms at integration I would consider
> it very like that it could make it in. FriCAS full [without gcl] weighs
> in at 9MB, so if you can strip out unneeded parts for an initial bare
> bone distribution it would be great.
>
Do you mean, for example eliminating the hyperdoc browser and Axiom
graphics? I think that trying to eliminate mathematical functionality
is not likely to save much in a "bare bones" distribution.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: [sage-devel] Re: FriCAS/Open-Axiom and SAGE
On Wed, Apr 23, 2008 at 1:48 PM, Gary Furnish wrote: > ... > Right now, most functionality of the sage.calculus module is dictated > strictly by how maxima is designed. As we move to our own internal > representation, this obviously will not be sufficient. It is not immediately obvious to me that this is not sufficient. To decide it might first be necessary to define more carefully exactly what you want to be able to do in Sage. > I'd be interested in hearing which features of FriCAS/OpenAxiom has > that might be useful in more detail. Here is a very short and personally biased summary: I think a big difference between Maxima and Sage is that Maxima is *untyped* or rather, there is really only one type of object in Maxima - an expression - while Sage attempts to treat objects as belonging to different mathematical categories. For example: a Polynomial is built over some coefficient Ring, etc. Sage is like Axiom in this respect. On the other hand Axiom has a domain called 'Expression' which fits into the overall mathematical category struture in a well-defined manner, i.e. it consists of a formal extension of the rational functions (Fraction Polynomial). The Expression domain is very different from simply being a "symbolic expression" in the sense used in Maxima. Axiom has another domain called InputForm which is much more like Maxima's symbolic expressions but in Axiom it is used only for the internal representation of input to the interpreter. Very little expression manipulation occurs in Axiom at this level although some people have argued that Axiom should have better support of doing this sort of thing. Closely related to this is another set of domains in Axiom related to pattern matching in Expression and other less highly structured symbolic domains. > My main technical concerns are that anything interacting > through a pexpect interface is going to be slow and will not > interact with Sage's internal coercion system (aside from the > fact that adding another dependency to the standard core > increases code complexity for symbolics dramatically). Could you explain more about why you say this will not (can not?) interact with Sage's coercion system? > I downloaded FriCAS to try to investigate, but I couldn't > find a good introduction to the high level structure of the > FriCAS code (at the file level). Does such a thing exist? > Do you really mean "structure of the code at the file level" or do you want something more conceptual? For example: Have you looked at the Axiom book (a little over 1000 pages). Chapters 11, 12 and 13 describe the tools used to build the Axiom library. Have you tried hyperdoc to navigate the mathematical structure? If you really mean "at the file level", the files that you will probably care most about are those found in the src/algebra directory. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: Sage, Maxima, Lisp
2008/4/23 Waldek Hebisch wrote: > ... > For FriCAS in longer run dropping Lisp is likely -- most Lisp code > is machine generated during FriCAS build. With enough effort we > could directly generate C code. Currently effort to drop Lisp would > be prohibitive, but the FriCAS code is constanly cleaned up and > simplified so in the future such change will be much easier. > I have a question that might at first seem heretical, but I think that the answer might possibly be of some interest to the Sage developers... Both you and Gaby have discussed the possibility of defining an abstract machine (aka. run-time system) to replace the role that Lisp plays for Axiom. We also know that Aldor has already defined such a machine called FOAM. FOAM can be implemented either in Lisp (for interface with Axiom) or by a run-time system written entirely in C for stand alone use. In fact this strategy is quite common and we here a lot for example about the Java Virtual Machine. Now it turns out that Python also has this notion of an abstract virtual machine that is the target for the Python interpreter. There are already some languages other than Python that can produce low level code for the Python virtual machine. I believe that the current Python virtual machine would very likely be adequate to support the run time requirements of Axiom/Aldor. So my question is: Is there be any possibility and interest in producing either an Axiom/Spad or Aldor compiler that targets this same virtual machine? In principle (and I admit that this is a big leap) this would allow complete interoperability between Sage and Axiom or Aldor. Perhaps you have other ideas about how to achieve this kind of interoperability? I could imagine for example linking Python directly into the Aldor C run-time system or maybe linking the Python into the lisp image that runs Axiom? What do you think? Is this crazy? Regards, Bill Page. --~--~-~--~~~---~--~~ 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: ISSAC abstract
On Wed, Apr 30, 2008 at 1:57 AM, William Stein wrote: > > Hi, > > I'm giving a plenary talk at ISSAC in Linz, Austria this summer. I'm > supposed > to write a 2-page "abstract/paper" for the proceedings. I just wrote > something: > >http://sage.math.washington.edu/home/was/tmp/abstract.pdf > > I've been advised by some people on this list to focus on algorithms in Sage > and purely technical things, but I've totally ignored that advice and instead > written something very social in which I as honestly as possible lay out > exactly > why Sage exists and try to describe somewhat just what Sage is. > > I have to submit this in a couple days, but comments are welcome. > Hmmm, I have to give it a -1. :-( I don't like it much. But it's your show. ... I really don't think that you will find many people at this meeting who are interested in open source alternatives to commercial software as such. Many of the attendees will have and may still be involved in developing software for the commercial systems. Most are also involved in some form of academic research in computer algebra systems. I don't mean that people wont be interested in hearing about the advantages of open source, but I believe that it would not normally be viewed as their primary motivation or preoccupation. And I think they will probably already have a fairly good idea about why Sage exists. I think the advice you received from other people on this list to "focus on algorithms and technical things" was probably pretty good for the intended audience. It seems that usually there are three speakers and they are all "technical" in a general sense. For example at ISSAC 2006 http://issac2006.dima.unige.it there were three plenary speakers: Christopher Umans Group-Theoretic Algorithms for Matrix Multiplication Hennie Poulisse Computational Communicative Algebra Joachim von zur Gathen Who was Who in polynomial factorization and at ISSAC 2005 http://www.mmrc.iss.ac.cn/issac2005 these five: Stephen M. Watt A Framework for Pen-Based Mathematical Computing Prof. Hai Jin The ChinaGrid and its Impact on e-Science in China Bruno Salvy D-finiteness: Algorithms and Applications Bruno Buchberger A View on the Future of Symbolic Computation Wen-Tsun Wu On a Finite Kernel Theorem for Polynomial-Type Optimization Problems and Some of its Applications (perhaps two here somewhat less technical) and ISSAC 2004 http://www.risc.uni-linz.ac.at/about/conferences/issac2004/invitedtalks.html 1. Numerical Algebraic Geometry and Symbolic Computation by Jan Verschelde 2. Triangulations of Polytopes and Algebraic Geometry by Francisco Santos 3. Sum of Squares of Polynomials and Their Applications by Pablo Parrilo - Talking about what Sage "is", however does make sense to me. If you are not inclined to speak specifically about how Sage is used in your own or other people's research, then why not say something about how Sage actually achieves integration between such a large number of systems? How do you make Maxima results available to Gap and then compute something that you display a fancy 3d graphic etc. What is the importance of Python as the interpreter? What about trade-offs for compiled code in Cython or interfaces to external libraries? How important is the web-based notebook interface? ... Just some different ideas. I know ideas are cheap, but you did ask. :-) Regards, Bill Page. --~--~-~--~~~---~--~~ 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: ISSAC abstract
On Wed, Apr 30, 2008 at 9:53 AM, William Stein wrote: > > On Wed, Apr 30, 2008 at 12:02 AM, Bill Page wrote: > > > > On Wed, Apr 30, 2008 at 1:57 AM, William Stein wrote: > > > > > > I'm giving a plenary talk at ISSAC in Linz, Austria this summer. I'm > supposed > > > to write a 2-page "abstract/paper" for the proceedings. I just wrote > something: > > > > > >http://sage.math.washington.edu/home/was/tmp/abstract.pdf > > > > > > I really don't think that you will find many people at this meeting > > who are interested in open source alternatives to commercial > > software as such. > > I guess they will just be bored by my talk and fall asleep. > I certainly hope not! I think the ISSAC community needs Sage very badly - they just don't know it yet. > > > Many of the attendees will have and may still be involved in > > developing software for the commercial systems. Most are also > > involved in some form of academic research in computer algebra > > systems. I don't mean that people wont be interested in hearing > > about the advantages of open source, but I believe that it would > > not normally be viewed as their primary motivation or preoccupation. > > And I think they will probably already have a fairly good idea about > > why Sage exists. > > I actually imagine that a lot of them won't have a good idea about > why Sage exists. The main reason Sage exists is because exactly > those people failed for a very long time to make the tools that I need > for my research in number theory, so I had to take matters into my > own hands. I suspect they won't see things that way. > I agree that they probably do not see it that way. On the other hand I do expect that they see it *exactly* the same way you do: For the most part the things *they* created exist because *they* had need of such tools to do the research that *they* wanted to do and it seemed to them that no one else had created the right tools for the job. (I said "seemed" because in some cases it might have seemed easier to re-invent what was needed rather than learning enough about what someone else had created.) In other words the reason (most of) those other systems exist is the same as the reason that Sage exists. The arguments for or against proprietary and/or open source models for development came later. Even systems like Axiom were essentially "open source" when they were first created - all you had to do was show some interest in the work of the developers and ask for their source code. I think the problem was mainly that there really was no infrastructure in place yet (e.g. the web) that would allow the open source model to work. Unless large government research funding was available, the argument that the proprietary commercial/non-profit development model was the best approach was easy to sell - and still appeals to many people. If by presenting Sage ISSAC you succeed in convincing some of these people that open source really is a viable approach today, then I agree that that would be a good thing! > ... > > Talking about what Sage "is", however does make sense to me. > > > > If you are not inclined to speak specifically about how Sage is used > > in your own or other people's research, then > > I certainly will speak about how Sage is used in my research and others > during my talk. The abstract I posted is limited to 2 pages, and hence > is a lot shorter than my talk. > Yes, of course. I think I was a bit mislead by the style of the abstract. Do you think quoting testimonials from other people is such a good idea? On Wed, Apr 30, 2008 at 10:21 AM, William Stein wrote: > > On Wed, Apr 30, 2008 at 3:26 AM, David Joyner wrote: > ... > > 3. A specific example could be mentioned which smoothly integrates > > several systems. As Michael B suggests, a group invariant computation > > in a number field mixes GAP (for groups), Pari for the number field (is > > this correct?), and Singular (for the polynomial ring invariant theory > > computations). > > > > I will demo computation and visualization > of modular abelian varieties during my talk, and keep the above > suggestions in mind. Computing modular abelian varieties > brings together numerous components of Sage, and is exactly > the functionality I started Sage for. It's fairly technical, > but not impossibly so (it's just homology groups of modular > curves, which are compact Riemann surfaces, etc.) > I think it is important emphasis in the abstract that your talk will include such examples. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: fast vs viable (offline post)
William, On Thu, May 1, 2008 at 2:42 PM, you wrote: >... > [A lot of interesting observations and recommendations about > how to do software development in Sage.] Everything you wrote in the this email made extremely good sense to me and I think it deserves to be repeated... > You know, I think I should partly scrap my previous ISSAC abstract/talk > plan and change it to be much more about the Sage development > process and how it is simply a merging of traditional software > engineering, traditional mathematical publishing, and standard > social networking tools (email and irc). Perhaps that's a reasonable > thing to talk about for that conference... > I think it would be great if you could spend at least 50% of your talk on this subject - or better - way not plan to give two talks! :-) > ... Regards, Bill Page. --~--~-~--~~~---~--~~ 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: ISSAC abstract
On Thu, May 1, 2008 at 5:51 PM, William Stein <[EMAIL PROTECTED]> wrote: > > Hi, > > I wrote a new version of my ISSAC talk abstract. What do you think: > > http://sage.math.washington.edu/home/was/tmp/abstract.pdf > This is abstract number 3, right? I hope I got that right. Well, ah ... -1. I thought this message sounded like at good idea in the context of the other thread but in this context I find I don't like it much, sorry. :-( It does not sound nearly as good as your email, which made several other points besides the one contained herein. The previous abstract (the second one?, definitely not the first) seemed like a good balance to me: What is Sage? What can it do? This one is more about: What you would like to do to make Sage more than what it is so far. It seems to me that at best that deserves a few minutes toward the end of the second abstract. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: Fwd: Tensor products
On Wed, May 7, 2008 at 8:50 AM, David Kohel wrote: > ... > A good design is very important. > > In fact this is a vey generic categorical construction of (a sum or > coproduct in the category of rings). We should first consider how > general products and coproducts should be constructed, and set > up a common infrastructure and syntax. It needs to be (1) easy > and natural to use, (2) mathematically correct and complete. > +1 I strongly agree with this. I think a more direct representation of categorical constructions in Sage would be a very good thing. Some similar work along these lines has been done by Saul Youssef in the Aldor language. Perhaps something like this is possible in Python/Sage? See for example the links at: http://axiom-wiki.newsynthesis.org/SandBoxAldorCategoryTheory Most of the coding is done in terms of Aldor "categories" (something like generic interfaces in Java) and there is no direct counterpart to this in Python programming language as far as I know. I have seen here on this list a mention of some ideas for implementing generic programming in Sage but I do not know where to go for details. I think that whatever one might do with category theory in Sage is likely to require or at least interact with such generic programming features. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: problem installing fricas
William is right, GCL was not required to install fricas. The original version I uploaded 10 months ago built fricas from pre-generated lisp source using clisp. The install took about 10 minutes to complete. After downloading and untaring the file 'fricas-1.0.2.spkg' from: http://www.sagemath.org/packages/optional the file SPKG.txt shows that the version apparently came from Burcin Erocal on April 1, 2008: ... == Changelog == === fricas-1.0.2 (Burcin Erocal) === * update to FriCAS-1.0.2 release === fricas-0.3.1 (Bill Page) === * FriCAS-0.3.1 release Certainly it is the not the spkg that I created. This new version seems to require GCL and builds from source. This takes much! longer (~2 hours?). The version I uploaded last is here: http://sage.math.washington.edu/home/page/packages But I must admit that I have not tried it with more recent releases of Sage. Regards, Bill Page. On Wed, May 28, 2008 at 3:22 PM, William Stein <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 12:12 PM, John Cremona <[EMAIL PROTECTED]> wrote: >> >> I tried to install fricas (prompted by an earlier thread -- I wonder >> which?) but this happened (with 3.0.2 on linux): >> >> axiom_build_bindir = >> /home/jec/sage-3.0.1/spkg/build/fricas-1.0.2/build-dir/build/x86_64-suse-linux/bin >> checking for gcl... no >> configure: error: GCL and GCL sources missing, see README.wh >> *** >> Failed to configure Axiom. >> *** > > Wow, that stinks. The situation last time I tested fricas > was that it didn't require gcl to build (only clisp, which we > shipped), and I'm very unpleasantly surprised this is now broken. > > Maybe Bill Page or Waldek Hebisch could comment... > In any case, we should open a ticket, I think. > > >> >> real0m0.546s >> user0m0.280s >> sys 0m0.268s >> sage: An error occurred while installing fricas-1.0.2 >> Please email sage-devel http://groups.google.com/group/sage-devel >> explaining the problem and send the relevant part of >> of /home/jec/sage-3.0.1/install.log. Describe your computer, >> operating system, etc. >> If you want to try to fix the problem, yourself *don't* just cd to >> /home/jec/sage-3.0.1/spkg/build/fricas-1.0.2 and type 'make'. >> Instead type "/home/jec/sage-3.0.1/sage -sh" >> in order to set all environment variables correctly, then cd to >> /home/jec/sage-3.0.1/spkg/build/fricas-1.0.2 >> (When you are done debugging, you can type "exit" to leave the >> subshell.) >> >> >> Is there somewhere where package dependencies are listed? Are these >> checked (I guess not)? >> >> John --~--~-~--~~~---~--~~ 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: problem installing fricas
On Wed, May 28, 2008 at 3:23 PM, mabshoff wrote: > > On May 28, 9:12 pm, John Cremona wrote: > >> I tried to install fricas (prompted by an earlier thread -- I wonder >> which?) but this happened (with 3.0.2 on linux): >> >> axiom_build_bindir = >> /home/jec/sage-3.0.1/spkg/build/fricas-1.0.2/build-dir/build/x86_64-suse-linux/bin >> checking for gcl... no >> configure: error: GCL and GCL sources missing, see README.wh > > It seems to expect gcl to be installed, so it is likely that once you > install a system wide gcl it would get beyond that point. In the past > there was trouble building FriCAS/Axiom/OpenAxiom with the clisp > Sage provides since we do not build libsigsev [Maxima doesn't require > it] and we do wrap the binary clisp into a thin shell wrapper because > otherwise on relocation clisp does not find its default memory image. > Maxima is build with some switch telling it to use clisp as clisp.bin > for example. Apparently this is a result of changes made by Burcin Eroal. Fricas without X support can be built with the version of clisp included with Sage. X is only required to run Axiom graphics and Hyperdoc - neither of which are normally accessible from within Sage. http://groups.google.com/group/sage-devel/browse_thread/thread/90bd5cd51238c848/a891aee4688e88f3?lnk=gst&q=fricas+clisp#a891aee4688e88f3 > We will soon [a months or two] switch to using ecl [Maxima in > interpreted mode works already] and FriCAS's test suite on > the latest ecl is actually about 30% faster than clisp. And there > are already speed ups beyond that. > Has this result for FriCAS been previously reported somewhere? What is the build time for the complete system? Is anyone working on making preparing a Sage spkg for FriCAS based on ecl? > ... Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: > > On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: > ... >> I consider homsets to be a gigantic flaw in coercion that >> absolutely have to be fixed for me to consider using more >> of the coercion system in symbolics. > > Ironically, other people see it as a plus that coercion has > been given a more categorical founding. > Absolutely! :-) BTW, where can I read more about these categorical concepts that are currently built-in or planned for Sage? Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 5:48 PM, William Stein wrote: > > On Tue, Jun 3, 2008 at 2:45 PM, Bill Page wrote: >> >> On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: >>> >>> On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: >>> ... >>>> I consider homsets to be a gigantic flaw in coercion that >>>> absolutely have to be fixed for me to consider using more >>>> of the coercion system in symbolics. >>> >>> Ironically, other people see it as a plus that coercion has >>> been given a more categorical founding. >>> >> >> Absolutely! :-) >> >> BTW, where can I read more about these categorical concepts >> that are currently built-in or planned for Sage? >> > > This is very relevant: > > http://wiki.sagemath.org/days7/coercion > Thanks for the reference. No mention of "homsets" here. :-( Only one mention in /days7/coercion/todo ... But reading this makes me feel a little, well ah, "light-headed". At best it seems like something very hastily grafted-on to the design. Is this part of Sage about which you would like comments and more discussion? Or is there more information somewhere that I am missing? I am afraid that there is not much here that category theorists are likely to find interesting. I have many many questions, but mostly I wonder what the overall intention of this construction really is in Sage? Is it only relevant to coercion? How does it related to the concept of "parent" - which seems equally ill-defined to me? What is the relationship to inheritance in Python? Is the intention to give all mathematical objects defined in Sage some categorical structure? What about categories themselves as mathematical structures - e.g. a category is a kind of directed graph with additional structure? Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
Robert, Thanks for the elaboration. I hope that this follow-up is not too far off topic and I don't want to distract you (or any of the Sage developers) from your main tasks. I wrote this mostly as notes and questions to myself - but if you or anyone else have some time or the inclination to correct or comment as time permits, that would be great. On Tue, Jun 3, 2008 at 10:04 PM, Robert Bradshaw wrote: > > On Jun 3, 2008, at 4:50 PM, Bill Page wrote: > >> How does it [categories in Sage] relate to the >> concept of "parent" - which seems equally ill-defined to me? > > A Parent is an Object in the category of Sets, though in the context > of coercion one usually assumes one can some kind of arithmetic > (binary operations) on their elements. > ... > On Jun 3, 2008, at 7:11 PM, David Harvey wrote: > ... >> Don't you mean to say something more like "a parent is an object >> of a concrete category", i.e. a category C with a faithful functor >> f : C -> Set, such that the "elements" (as understood by Sage) of >> the parent P are exactly the elements of f(P)? Ok (and thanks also for the clarification, David). There are of course two different uses of "object" here: 1) object of some category, 2) Python object. All Python objects have a 'type', i.e. belong to some Python class. So in Sage 3.0.2 I observe for example: sage: type(1) sage: parent(1) Integer Ring sage: type(parent(1)) sage: category(parent(1)) Category of rings sage: type(category(parent(1))) and sage: type(1.0) sage: parent(1.0) Real Field with 53 bits of precision sage: type(parent(1.0)) sage: category(parent(1.0)) Category of fields sage: type(category(parent(1.0))) These seem consistent to me, albeit rather complex. However I am not sure I understand the following: sage: parent(IntegerRing()) sage: parent(RealField()) Could you explain why the parent of an object of some category is a type? > >> What is the relationship to inheritance in Python? Is the intention >> to give all mathematical objects defined in Sage some categorical >> structure? What about categories themselves as mathematical >> structures - e.g. a category is a kind of directed graph with additional >> structure? > > A big push of this model is to divorce the relationship between > inheritance (which primarily has to do with implementation) and > mathematical categorization. At first blush it still seems strange to me to distinguish between the parent of an object and the type of an object. The instances of a type are often considered elements. Is the invention of 'parent' in Sage due to some inherent limitation of Python classes? Do you really want to say more abstractly that a certain type *represents* a certain parent? E.g. Does 'sage.rings.real_mpfr.RealNumber' represent 'RealField()'? Can there be other representations of 'RealField()' in Sage? How can I find out for example if 'sage.rings.integer.Integer' represents 'IntegerRing()'? >From my experience with Axiom I am sympathetic to the separation of implementation and specification but in Axiom "domains" are both parents and types. A domain can inherit it's implementation from another domain (via add). A domain can also serve as the representation for some other domain (via Rep). For example IntegerMod(5) is the representation of PrimeField(5). IntegerMod(5) in turn is represented by SingleInteger, etc. In Axiom, at the deepest level all types are ultimately provided by Lisp. These types are not really Axiom domains and so I suppose the situation is analogous to Python types and Sage parents. Axiom categories on the other hand form a lattice. Domains belong to categories by assertion or by virtue of the subdomain relationship. In Axiom there is an operator named 'has' which provides the same information as 'category' in Sage so that: x has y is just 'y == category(x)'. For example 'Float has Field' is equivalent to: sage: Fields() == category(RealField()) True Although in Axiom a domain may satisfy more than one category. Will this be possible in Sage in the future? What information does Sage actually have about a given category? For example, what does Sage know about the relationship between Rings() and Fields()? E.g. functors? None of this has much to do with "category theory" as such. Categories in Axiom are only vaguely related to categories in Mathematics. So I suppose from your description that categories in Sage will play a similar role but will be more strongly related to the mathematical concept? > This will allow categories to play a larger role (though work in that > area can be done after the merge as it is not disruptive). For > example, Z/nZ[x] is implemented the same w
[sage-devel] parent of component of CartesianProduct
In: http://modular.math.washington.edu/msri06/work/kohel/msri_magma.pdf "A Brief Magma Tutorial" by David R. Kohel gives this example: -- The parent structure of a tuple is more important than in the case of sequences or sets. > C := CartesianProduct(Integers(),RationalField()); > t := C!<1,1>; > Parent(t[2]); Rational Field -- The analogous computation in Sage 3.0.2 yields: sage: C = CartesianProduct(Integers(),RationalField()) # case 1 sage: t=C([1,1/2]) sage: parent(t[0]) Integer Ring sage: parent(t[1]) Rational Field # case 2 sage: t=C([1,1]) sage: parent(t[0]) Integer Ring sage: parent(t[1]) Integer Ring - Notice that the parent of t[1] is incorrect in the 2nd case. Is there any interest in also implementing the Co-product constructor? What about Record and Union constructors? Regards, Bill Page. --~--~-~--~~~---~--~~ 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: parent of component of CartesianProduct
On Wed, Jun 4, 2008 at 6:07 PM, William Stein wrote: > > On Wed, Jun 4, 2008 at 3:03 PM, Bill Page wrote: >> >> Is there any interest in also implementing the Co-product constructor? > > Yes. > >> What about Record and Union constructors? >> > > I don't know what those are (at least what Record is). > Records and Unions are products and co-products with named projections and injections. Records are like struct in C. Unions are sometimes called "tagged-unions" but that suggests a particular implementation detail rather than an essential feature. Union is also sometimes called a "variant-record". But in my opinion the semantics is best described in more categorical terms. http://en.wikipedia.org/wiki/Record_(computer_science) http://en.wikipedia.org/wiki/Coproduct http://en.wikipedia.org/wiki/Product_(category_theory) Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Wed, Jun 4, 2008 at 1:54 PM, Robert Bradshaw wrote: > > On Jun 4, 2008, at 4:07 AM, Bill Page wrote: > ... >> >> These seem consistent to me, albeit rather complex. However I am >> not sure I understand the following: >> >> sage: parent(IntegerRing()) >> >> sage: parent(RealField()) >> >> >> Could you explain why the parent of an object of some category is a >> type? > > David's explanation of this is right on. We need parent() to work in > some sensible way on non-Elements (e.g. Python ints, objects from > outside Sage) to be able do some kind of coercion reasoning on them. > Python is a dynamically typed language, ever object has a type. > So is this essentially an admission that the concept of 'parent' is superfluous and could have in fact been implemented just at Python 'type'? I am not sure that I would actually advocate this now, but for argument's sake: Why not do it this way all of the time? Python classes all end up as (potential) parents. I think that this more or less is what at least some Magma developers had in mind. E.g. We read in the preface to the Magma HTML Help Document: http://magma.maths.usyd.edu.au/magma/htmlhelp/preface.htm "Every object created during the course of a computation is associated with a unique parent algebraic structure. The type of an object is then simply its parent structure." > ... > One should think of the type of an object as what specifies its > implementation (including its internal representation). In this sense > it is like a class in Java, C++, or any other programming language. > (In Python there is a subtle (and mostly historical) difference > between types and classes depending on whether or not it's written > in C, but for the most part they can be used interchangeably). > Python has multiple inheritance, but Cython does not (the C > format of a compiled Python class is a C struct, so this is not so > much a Cython limitation as a Python/C API limitation.) > The lack of multiple inheritance in Cython seems to be a major design obstacle. Although a C struct is not a real class, it is not clear to me why this is not adequate in compiled code. Wouldn't it be sufficient to merge (flatten) the components of the multiple ancesters into one struct? If not (e.g. if it is necessary to retain some knowledge of their origins), why not provide nested structs? But I suppose that this is quite off-topic... > Most of the time there is a 1-to-1 correspondence between Parents > and the types of its Elements. For example, and element of the Parent > RR (= RealField(53) is represented by sage.rings.real_mpfr.RealNumber. > If I do RR(3) I get back an object of type sage.rings.real_mpfr.RealNumber > representing the floating point number 3 to 53 bits of precision, and it's > Parent is RR. RealField (100) is a new Parent, whose elements are > again of type sage.rings.real_mpfr.RealNumber but to 100 bits of > precision. > > Sometimes, however, the same type is used for multiple parents. > There are several integer mod types (depending on whether or not > the modulus fits in a single word) and they are used for both generic > Z/nZ and prime-order finite fields. Thus we have > > sage: [type(mod(-1, 100^k)) for k in [2..5]] > [, > , > , > ] > > sage: [parent(mod(-1, 100^k)) for k in [2..5]] > [Ring of integers modulo 1, > Ring of integers modulo 100, > Ring of integers modulo 1, > Ring of integers modulo 100] > Hmmm... what I think I see here is multiple Python types (_int, _int64, _gmp) being used for the *same* parent, i.e. "Ring of integers modulo n" (for some parameter n). Simple inheritance should make this easy, no? > On the other hand, some parents may have elements of several > types. The "SymbolicRing" is one such example. > > sage: [type(a) for a in v] > [, > , > , > ] > > sage: [parent(a) for a in v] > [Symbolic Ring, Symbolic Ring, Symbolic Ring, Symbolic Ring] > "SymbolicRing" is another thing that worries me a little. Exactly what (mathematically) is a symbolic ring? E.g. Why is it a ring and not a field? Operations like 'sin(sin(sin(x))).parent()' doesn't look much like a ring to me. Probably most other computer algebra systems would just call this an "expression tree" or AST or something like that. Why do we need different types (sub-classes)? >> From my experience with Axiom I am sympathetic to the separation of >> implementation and specification but in Axiom "domains" are both >> parents and types. A domain can inherit it's implementation from >> another domain (via add). A domain can also serve as the >> representatio
[sage-devel] Re: coercing of sqrt(2)
On Wed, Jun 4, 2008 at 11:06 PM, William Stein wrote: > > On Wed, Jun 4, 2008 at 7:35 PM, Bill Page wrote: >> >> On Wed, Jun 4, 2008 at 1:54 PM, Robert Bradshaw wrote: >>> >>> David's explanation of this is right on. We need parent() to work >>> in some sensible way on non-Elements (e.g. Python ints, objects >>> from outside Sage) to be able do some kind of coercion reasoning >>> on them. Python is a dynamically typed language, ever object has >>> a type. >> >> So is this essentially an admission that the concept of 'parent' is >> superfluous and could have in fact been implemented just as >> Python 'type'? > > That is not the case, except that of course *anything* that can > be implemented, can be implemented in any turing complete > language. > I did not mean to pose this question in a trivial way. I meant to suggest that the concept of type in the Python programming language, i.e. classes, could directly implement the concept of "parent" as used in Sage without abusing either concept at all. Can you suggest an example that demonstrates that this is not the case? > ... > There are infinitely many different parents, one of each value > of n. For a given n, the ring Z/nZ is a specific mathematical > object, which is itself for many many reasons worth modeling > in a computer. If nothing else, it is the place on which to hang > functions like "multiplicative_generator()". Python classes can also take parameters. > Any computer algebra system that doesn't have first class > actual objects that represent basic mathematical structures > such as rings, fields, etc., feels extremely barren if one has > used Magma for a sufficient amount of time. > Sure. Rings and fields are categories. Magma was not the first system to represent these mathematical structures in a computer. > Specific rings, fields, vector spaces, etc., are all basic objects of > mathematics, that are just as important to fully implement and > model in a CAS as polynomials, rational numbers, vectors, etc. > I firmly believe Magma was the first ever system to really get this > right, and Sage merely copies this. I really greatly appreciate > what Cannon et al. did... > I am sure Magma is an interesting system - everything I have been reading about it confirms that - but I do not think it was the first. I am also not yet convinced that it has implemented these general mathematically concepts in any substantially better way then, for example Axiom. Some things it does seem peculiar and ad hoc to me. These are the things that standout in my mind when I think about in what ways Sage resembles Magma. Of course there are some specific computations that Magma does much more efficiently than any other system. But that is not the point. We are talking here about general design issues. > ... >> "SymbolicRing" is another thing that worries me a little. Exactly >> what (mathematically) is a symbolic ring? E.g. Why is it a ring >> and not a field? Operations like 'sin(sin(sin(x))).parent()' doesn't >> look much like a ring to me. Probably most other computer algebra >> systems would just call this an "expression tree" or AST or >> something like that. > ... > To me, the SymbolicRing is the mathematical structure in which > calculus teachers, engineers, etc., are kept happy. In Sage > that was 100% its purpose. Ask Marshall Hampton, who is teaching > calculus right now using Sage, about what he needs to make > teaching calculus easy, and the answer is "The Symbolic Ring", > plus graphics and interact. > I don't doubt that doing symbolic mathematics by computer is very useful for teaching calculus - after all that is what is normally meant by the term "calculus", i.e. a method of calculation based on the symbolic manipulation of expressions. The name "Symbolic Ring" however makes it sound more "algebraic",i.e. concerned with structure, relation and quantity. So I was looking for a more formal mathematical definition of this sort. I did not expect it was a name intended just to keep certain people happy. :-( > ... Regards, Bill Page. --~--~-~--~~~---~--~~ 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: parent of component of CartesianProduct
On Thu, Jun 5, 2008 at 10:17 AM, David Kohel wrote: > > Note that the intent of these SAGE constructors is not (just) > to replicate the design (and errors) of Magma or other languages. :-) Agreed. > There are natural product and coproduct constructions in > various mathematical categories (e.g. a coproduct in Sets > _is_ the union). Co-product in Set is *disjoint* union. > The constructor CartesianProduct should be the product in > the category of Sets (although you give an example which > the sets are also rings). However this identification does not > conflict with its role in enumeration in loops (over enumerable > sets). Agreed. > A categorical perspective should aid in the design of efficient > and useful structures for mathematics and computation, many > of which could map to natural constructions in various languages. Agreed. Although I think the fact that it might also be "efficient" has yet to be convincingly demonstrated. There are also distinct notions of efficiency that need to be addressed: computational efficiency, design efficiency, learning efficiency, etc. It is not clear that a categorical perspective aids in all of these areas. > The Coproduct in Sets equals the Union, as you indicate. > Disjoint union. > Similarly there should also be a product and coproduct constructor, > for example, in the category of commutative rings, which are different > objects. "Should be" means when someone finds the need and time > to implement such structures. > Product (co-product) is a type of limits (co-limit). Objects that live in categories that support limits should automatically provide such generic structures. It should not be necessary to implement then specifically unless there is some good too - e.g. computational efficiency. > Record appears not to fit in a (mathematical) category framework, > but an equivalent functionality may be provided by some existing > Python structure. > Records are just an implementation of the standard categorical product construction as the limit: h: Record(a:A, b:B) -> A x B 'a' and 'b' are names for the projection maps a: Record(a:A, b:B) -> A b: Record(a:A, b:B) -> B See for example: http://axiom-wiki.newsynthesis.org/SandBoxLimitsAndColimits It is odd perhaps that Python does not currently implement record or union, although it has been considered as a possible extension to Python by the original developer: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 It is possible to write a Python class that provides these types. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 1:47 AM, William Stein wrote:
>
> On Wed, Jun 4, 2008 at 10:16 PM, Bill Page wrote:
>> ...
>> Python classes can also take parameters.
>
> I didn't know that. I thought the only way to create a Python class
> is for the Python interpreter to execute Python code that looks like this:
>
> class Foo(...):
> ...
>
> That makes a new class called Foo. How are you going to make, at
> runtime, new classes for each of Z/nZ say, for 1 <= n < 10^5, i.e.,
> something like this in Sage:
>
> v = [Integers(n) for n in range(1,10^5)]
>
> I do not think it is possible to concisely create a hundred thousand
> separate Python classes like that.
>
See Python MetaClasses. E.g.
http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html
sage: X = type('X', (object,), dict(a=1))
sage: x=X()
sage: x.a
1
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 12:23 PM, Gonzalo Tornaria wrote: > On Thu, Jun 5, 2008 at 1:47 AM, William Stein wrote: >> ... How are you going to make, at >> runtime, new classes for each of Z/nZ say, for 1 <= n < 10^5, >> i.e., something like this in Sage: >> >> v = [Integers(n) for n in range(1,10^5)] >> >> I do not think it is possible to concisely create a hundred thousand >> separate Python classes like that. > ... > WRT your example: > > sage: def classinteger(m): > ... class A: > ... def __init__(self, n): > ... self.__n = n % m > ... def __repr__(self): > ... return "%d mod %d" % (self.__n, m) > ... A.__name__ = "classintegers mod %d" % m > ... return A > sage: classinteger(5)(3) > 3 mod 5 > sage: time v = [classinteger(n) for n in range(1,10^5)] > CPU time: 3.64 s, Wall time: 4.14 s > sage: time w = [Integers(n) for n in range(1,10^5)] > CPU time: 15.75 s, Wall time: 16.21 s > sage: v[1256](34251235) > 499 mod 1257 > ... Excellent example. Thank you! > I was going to say that using classes built at runtime like this > was fine but not a good option for performance reasons, but the > example above shows the overhead of python class creation time > is not so significant. > Agreed. Python can treat types as fully first class objects. I think this strongly supports William's initial decision to choose Python as the basis for a new computer algebra system comparable to Magma and Axiom. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 1:18 PM, William Stein wrote: > ... > On Thu, Jun 5, 2008 at 12:23 PM, Gonzalo Tornaria wrote: > ... >> sage: def classinteger(m): >> ... class A: >> ... def __init__(self, n): >> ... self.__n = n % m >> ... def __repr__(self): >> ... return "%d mod %d" % (self.__n, m) >> ... A.__name__ = "classintegers mod %d" % m >> ... return A >> sage: classinteger(5)(3) > ... > OK, I have to come clean and admit that already actually knew > all about metaclasses, but considered using them this way so > unnatural and ugly that I would not recommend it. > Do you still consider the example code like that given above by Gonzalo "unnatural and ugly"? It seems like pretty standard Python to me. There of course various ways of packaging the metaclass machinery to provide an even cleaner user interface. The point I am making is that Python already has everything you need to implement the concept of the "parent" of an element as a type, i.e. directly as an instance of the class that creates it. This could result in considerable simplification compared to the current situation. Right now a Sage user has to deal with three separate type-related concepts: type (Python class), parent (an object in some category) and category. Metaclasses are a good match for Categories. Thus you can have everything in one package and remain closer to conventional Python programming in spirit. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 4:16 AM, Robert Bradshaw wrote: > > On Jun 4, 2008, at 7:35 PM, Bill Page wrote: > ... > Types are all about the implementations of things, they > synonymous with the "classes" of Object Oriented programming, > and are insufficient (and the wrong vehicle) to carry deeper > mathematical structure. That is precisely the claim that I am trying to dispute. Axiom for example specifically takes the point of view that mathematical structure should be implemented as types in a sufficiently rich programming language, i.e. one where types are first order objects. I think that Axiom (and later the programming language Aldor that was originally implemented as the "next generation" library compiler for Axiom) has demonstrated that this view is viable. > For example, an element of Z/5Z and an element of Z/7Z have > the same type (i.e. they're instances of the same class, with > the same methods, internal representation, etc), but not the same > parent (which is data). > I think Gonsalo Tornaria in this thread has demonstrated that this need not be the case. > ... >> "SymbolicRing" is another thing that worries me a little. Exactly what >> (mathematically) is a symbolic ring? E.g. Why is it a ring and not a >> field? Operations like 'sin(sin(sin(x))).parent()' doesn't look much >> like a ring to me. Probably most other computer algebra systems >> would just call this an "expression tree" or AST or something like >> that. > > Most symbolic systems (Magma and Axiom excluded) have very > little notion of algebras, rings, modules, etc.--virtually everything is > an expression or list of expressions. SymbolicRing is a way to fit > these abstract "expression trees" into a larger framework of Sage. > It not only keeps engineers and calculus students happy, it keeps > me happy when just want to sit down and "solve for x" or compute > a symbolic integral. It's also a statement that rigor should not get > in the way of usability (an important component of being a viable > alternative to the M's). > It seems to me that symbolic computation need not lack rigor. And in a computer algebra system rigor should not compromise usability. These are design challenges that we face. This is one of the things that strongly-typed systems like Axiom and Magma (and now Sage) offer over these other systems. > ... >> >> To the best of my knowledge, the formal concept of "representation" >> in a computer algebra systems is unique to Axiom. Each domain >> has a specified 'Rep'consisting of some domain expression. E.g. >> >>Rep == Integer >> >> or >> >>Rep == Union(Record(car:%, cdr:%), "nil") >> >> % stands for "this domain", so this definition amounts to some >> recursive structure. Of course recursively defined classes are also >> possible in Python but they require much more discipline on the >> part of the programmer. >> >> Now there are two operators 'rep' and 'per' that provide coercion to >> and from Rep. So we might say for example that some operation * >> in this domain is implemented by * from Rep: >> >> x * y == per( rep(x) * rep(y) ) >> >> The trouble is: I don't see anything here that could be called a >> "parent". Or perhaps, they are all "parents" except for those >> initial domains for which we never explicitly specify a Rep. > > Nope, nothing I see here could reasonably be called a Parent. > Is there an object that formally represents "the ring of integers" > that one could pass to a function? > Sure. For example in OpenAxiom one can write: (1) -> Integer has Ring (1) true Type: Boolean (2) -> Pick(x,A,B)==if x=0 then A else B Type: Void (3) -> i:=1 (3) 1 Type: PositiveInteger (4) -> n:Pick(i,Integer,Float):=1 Compiling function Pick with type (PositiveInteger,Domain,Domain) -> Domain (4) 1.0 Type: Float And of course even easier in Sage :-) sage: category(IntegerRing()) Category of rings sage: def Pick(x,A,B): if x==0: return A else: return B : sage: i=1 sage: n=Pick(i,IntegerRing(),RealField())(1) sage: n; parent(n) 1.00 Real Field with 53 bits of precision > ... >> >>> One of the changes in this latest coercion push is to allow >>> Parents to belong to several categories. >>> >> >> That sounds good. So does this me
[sage-devel] Re: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 5:19 PM, Robert Bradshaw wrote: > > Your Integer object also stands for the ring of Integers. So can > you do stuff like > > sage: ZZ.is_commutative() > True > sage: ZZ.krull_dimension() > 1 > sage: ZZ.is_finite() > False > (1) -> Integer has Finite (1) false Type: Boolean (2) -> Integer has CommutativeRing (2) true Type: Boolean (3) -> characteristic()$Integer (3) 0 Type: NonNegativeInteger Finite and CommutativeRing are categories. characteristic is a method of Integer. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: coercing of sqrt(2)
On Thu, Jun 5, 2008 at 6:39 PM, Carl Witty wrote: > > OK, I'm convinced that unifying parents and types is elegant and > works very well in Aldor, and that it's possible in Python. However, > I don't think it's a good idea for Sage, because of pragmatic > limitations due to Python/Cython. These points were all made by > other people in this thread, but I'm combining them into one > convenient list here for debating purposes. Thanks for summarizing the arguments against unifying parents and types in Sage. As I stated near the start of this thread, it was not my intention to recommend that Sage actually take this approach. Sage is 3.0 and the current approach is established and working well for the end user. My regret however is that it seems to make new development in Sage more complicated, with a steeper learning curve for new developers than it really needs to be. On Thu, Jun 5, 2008 at 9:09 PM, Gonzalo Tornaria <[EMAIL PROTECTED]> wrote: > >> >> On Thu, Jun 5, 2008 at 1:18 PM, William Stein wrote: >> > OK, I have to come clean and admit that already actually knew >> > all about metaclasses, but considered using them this way so >> > unnatural and ugly that I would not recommend it. >> > >> > On 6/5/08, Bill Page <[EMAIL PROTECTED]> wrote: >> Do you still consider the example code like that given above by >> Gonzalo "unnatural and ugly"? It seems like pretty standard >> Python to me. There of course various ways of packaging the >> metaclass machinery to provide an even cleaner user interface. > > I do think my code (as posted) is "unnatural and ugly". Just an > example, not even a class. I'd really love to figure out a proper > model of parent-element relationship using metaclasses, etc. > It seems to me that the parent-element relationship is already there. It is inherent in the Python concept of an instance of a class. In this model classes *are* parents. Instances are elements. Your example code presents a function that generates classes based on a parameter - a standard "class factory". As you say, what might be more interesting is a class that behaves like a category, i.e. whose instances themselves are classes. Python's type module is an example of such a metaclass. I think this is all very well and concisely described here: http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html A Primer on Python Metaclass Programming by David Mertz > I tried very hard (several times) to find such a model, or at least > "a cleaner user interface", and I played with some interesting ideas > but cooked no cake. > > Maybe you have some cool ideas on how one can make this work > (and appealing to others). > Have you looked at the 'type' class? I think that is pretty cool. >> category) and category. Metaclasses are a good match for >> Categories. > > Also cool. I remember I was hit by the python version of a few of > the paradoxes in early days set theory. YMMV. > I don't think you should let apparent paradoxes in set theory worry you. OpenAxiom for example has a domain called Domain. Domain is an instance of Domain so we can write: x:Domain:=Domain and the world does not end.. And would I really would like to get as much mileage as possible from native Python constructions. In the Axiom world we have a bit of a problem: Unlike Axiom itself, the new generation Axiom library compiler - Aldor - is not free (although just last year it finally became at least "semi-open"). In my opinion, to progress rapidly and as intended when Axiom was still a commercial product Axiom badly needs Aldor. The existing compiler in Axiom - SPAD - is significantly harder to use and to extend (although Gabriel Dos Reis has started to do some wonderful new things with it in the OpenAxiom fork of the original open source Axiom project.). I think this is one of the main reasons why Axiom has had a relatively difficult time attracting new uses and developers. Even Aldor however is already a rather "old" language. There has been a lot of progress in programming language design since the mid 1990's. Python is one result. It seems to me that Python has many of the attributes of the kind of language that the Axiom developers were trying to achieve. This is one of the primary reasons why I was interested in the Sage project in the first place. Sage is not Axiom, but it is (more or less) based on Magma and Magma has at least some of the features that I think make Axiom rather special as a computer algebra system. So like several other people before me, e.g. the developers of Sage and the developers of SymPy, I am now thinking quite seriously about how much of the Axiom design could actually be accommodated in Python. Implement
[sage-devel] Re: [fricas-devel] Re: SAGE and FriCAS
Martin,
On Sat, Aug 16, 2008 at 1:59 AM, Martin Rubey wrote:
>
> Bill Page writes:
>
>> I am not so sure that a similar role can be played by FriCAS.
>> The FriCAS/Axiom libraries are not so easily called by an
>> external program. Instead we have the same option to interface
>> with FriCAS as we have with Maxima - via the pseudo-terminal
>> (pty) serial interface. This has the same drawbacks in both
>> Maxima and FriCAS.
>
> I recently thought that it might be quite easy to have a domain
> SAGEForm, similar to OutputForm or --
>
> actually, doesn't OpenMath provide what SAGE needs?
>
OpenMath was an early attempt to do something much more ambitious than
what Sage needs. *If* the OpenMath option in Axiom was working today,
then it would indeed be a good way to pass output from Axiom back to
Sage while retaining as much of the Axiom type information as
possible. The necessary hooks for OpenMath generation are present in
the current panAxiom code, but OpenMath as implemented in Axiom
depends on an external library that is not currently included with any
panAxiom version.
But as I said, OpenMath attempts to solve the general problem of
exporting full semantic information from a computer algebra system.
This is more than what is required for a good interface to Sage. In
panAxiom we also have the MathML output. Currently only presentation
MathML is generated but there is an extension of MathML that include
much more content (semantic) information without getting into the
generalities of OpenMath. Perhaps a 'SAGEform' domain could be based
on an extension of the MathML output option.
But still misses one of the hardest parts - mapping Axiom type
structures back to Sage in a way that other parts of Sage understand
these structures. At a mathematical level (e.g. various kinds of
polynomials) this is probably not too hard, but at a more fundamental
level things get more difficult. For example, Sage (actually
originating with Python) has not data structure directly corresponding
to 'Record' or 'Union' in Axiom. This can cause a lot of trouble when
trying to access the results of those computations in Axiom that
return complex results. You will no doubt be aware that this occurs
when accessing the output of GUESS from within Sage.
The "dumb" mode of calling an external program like Axiom just passes
a string, e.g.
sage: axiom('x^2+1')
then the parsing of 'x^2+1' occurs entirely within Axiom. But it is
not so interesting to always be creating and passing strings.
There is very a little documentation available in Sage about how the
conversion from Sage internal format to some external format (such as
used when calling Axiom). This happens automatically when you write
something like
sage: axiom(x^2+1)
without including the 'quotes'. In this case Sage parses the expression
x^2+1
and creates a native polynomial object. Then the 'axiom' function must
now recursively process this Sage expression until it finds objects
and operations near the bottom of the tree that it knows how to
interpret as Axiom objects and operations. Most of the coding that
accomplishes this is outside of the 'axiom.py' interface itself,
distributed over several other Python classes. As far as I know
William Stein is still the best source for how this conversion works.
He has said that "really it is very simple" and I guess I do
understand parts of it, but you should expect to spend some time to
re-discover how it works sufficiently well in order to improve it.
In order to pass Axiom expressions back to Sage, it seems to me that
we might have to implement something like this only working in
reverse.
Anyway, I think there is a lot of potential for improvement in the
existing 'axiom.py' interface even without considering how to solve
the problem of an efficient application program interface. One thing
that I miss a lot when using Axiom from the Sage notebook is the
ability to embed Spad code and compile it. This should be quite
straightforward to add to 'axiom.py'.
I would be glad to work with anyone else interested in improving the
Axiom/FriCAS interface for Sage.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: SAGE and FriCAS
On Mon, Aug 18, 2008 at 11:29 AM, Ondrej Certik wrote: > > On Mon, Aug 18, 2008 at 5:10 PM, Bill Page wrote: >> ... >> Anyway, I think there is a lot of potential for improvement in the >> existing 'axiom.py' interface even without considering how to >> solve the problem of an efficient application program interface. >> One thing that I miss a lot when using Axiom from the Sage >> notebook is the ability to embed Spad code and compile it. This >> should be quite straightforward to add to 'axiom.py'. >> >> I would be glad to work with anyone else interested in improving >> the Axiom/FriCAS interface for Sage. > > In the long term there should be a way to call lisp from C or > Python directly. Then all the problems above could be solved > much more easily. If the only way of interacting with lisp is over a > pexpect interface, then something is very wrong. > I agree that an efficient API is desirable - especially if some external program is to be called very often to perform some small operation that is part of some larger calculation. That certainly is the case for the way Sage uses Maxima now. In this case the lack of an efficient API is a big limitation. But I do not see how this is the case with Axiom. It is not clear to me that any of "the problems above could be solved much more easily" given such an API. From my point of view the problems are at a different conceptual level. There is supposed to be an "easy" way to call programs compiled with ECL from C (and thus via some suitable wrapper from Python or from Cython), but I have yet to see this demonstrated. Even in this case there remains the problem of conversion of data structures which is likely to add back some (hopefully small part) of the overhead that you removed by eliminating pexpect. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: SAGE and FriCAS
On Mon, Aug 18, 2008 at 12:06 PM, Ondrej Certik wrote: > > On Mon, Aug 18, 2008 at 5:51 PM, Bill Page wrote: >> ... >> There is supposed to be an "easy" way to call programs compiled >> with ECL from C (and thus via some suitable wrapper from Python >> or from Cython), but I have yet to see this demonstrated. Even in >> this case there remains the problem of conversion of data structures >> which is likely to add back some (hopefully small part) of the overhead >> that you removed by eliminating pexpect. > > Just like with sympy or ginac. Just holding the pointer to the > expression in ginac or sympy. > I don't understand what "just holding the point to expression" has to do with the conversions that are done when I type something like sage: axiom(x^2+1) and hope to get the result back in Sage as something Sage understands natively as a polynomial. > If you know what I mean. Maxima and axiom are basically out of > the game, because of this. No, I am not yet sure I know what you mean. > I'd like to compare the symbolics engines on a fair basis, > so calling them over pexpect is not the way. > It seems to me it depends on what exactly what aspects you are comparing. > I think if any program wants to be successful, it's a good idea > to figure out how to call it from C without (much) overhead. Imho. > Maybe. But again I think it depends how you intend to achieve "success". It is not so easy to call Python code from a C mainline program either, is it? But the reverse is simple. Likewise calling C from Lisp is quite normal but the reverse is hard. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: SAGE and FriCAS
On Mon, Aug 18, 2008 at 12:48 PM, Ondrej Certik wrote: > > On Mon, Aug 18, 2008 at 6:24 PM, Bill Page wrote: >> >> ... It is not so easy to call Python code from a C mainline >> program either, is it? > > Thanks to Cython, it is very easy to call my Python implementation > of something from pure C. And it's fast, for example: > > http://freehg.sympy.org/u/certik/csympy/file/991e40db913e/basic.c > > line 841: > > 841 import_csympy(); > 842 coeff = multi(m, n, &len); > > multi is implemented here > http://freehg.sympy.org/u/certik/csympy/file/991e40db913e/csympy.pyx: > > 146 from multinomial import multinomial_coefficients > 147 > 148 > 149 cdef api sympyint *multi(int m, int n, int *list_len): > 150 r = multinomial_coefficients(m, n) > 151 cdef int len2 = len(r) > 152 list_len[0] = len2 > 153 l = [] > 154 for k, v in r.iteritems(): > 155 l.extend(k) > 156 l.append(v) > 157 cdef sympyint *cl = malloc(len(l)*sizeof(sympyint)) > 158 for i in range(len(l)): > 159 try: > 160 cl[i] = l[i] > 161 except OverflowError: > 162 print "Overflow occured, using 'cl[i] = 2'." > 163 print l[i] > 164 cl[i] = 2 > 165 return cl > > So you see it calls pure Python function and just converts the > dictionary it returns to a C array of integers. > Ok, thanks for the example. Yes I admit that using Cython this way is quite nice. It makes me think that maybe it would be interesting to write such Cython wrappers for calling larger parts of Sage from some external program (such as FriCAS) this way. But these sort of conversions are exactly the kind of thing to which I was referring. In your example, the conversion is quite simple but it even looks a little clumsy in this case. My main point in these comments, is that when converting between two different high-level representations of some more complex mathematical object, e.g. a matrix of p-adic polynomials, etc. these conversions can potentially dominate the interface. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: SAGE and FriCAS
On Mon, Aug 18, 2008 at 1:51 PM, Ondrej Certik wrote: > > On Mon, Aug 18, 2008 at 7:08 PM, Bill Page wrote: >> >> Ok, thanks for the example. Yes I admit that using Cython this way >> is quite nice. It makes me think that maybe it would be interesting >> to write such Cython wrappers for calling larger parts of Sage from >> some external program (such as FriCAS) this way. > > Yes, exactly. I always wanted to call Sage like a library. > >> But these sort of conversions are exactly the kind of thing to which >> I was referring. In your example, the conversion is quite simple but >> it even looks a little clumsy in this case. My main point in these >> comments, is that when converting between two different high-level >> representations of some more complex mathematical object, e.g. >> a matrix of p-adic polynomials, etc. these conversions can >> potentially dominate the interface. > > Agree. So what's the other option? > The only "other option" that I can think of is something like Martin Rubey suggested near the start of this thread: a new domain in FriCAS named 'SAGEForm'. The representations used in 'SAGEForm' would correspond directly to actual Sage data structures. In order to do this in a general manner it would be very convenient for FriCAS to be able to call Sage functions via Cython wrappers in the manner you have described in this thread. The 'SAGEForm' domain would provide an application interface to Sage for the rest of the FriCAS system. This API would have to provide something like a shared buffer in which to make the native Sage representation that it constructs available to the rest of Sage. Each FriCAS domain that you want to be able to represent directly in Sage would have to provide an operation such as: coerce: % -> SAGEForm (similar to 'coerce: % -> OutputForm' and 'coerce: % -> InputForm'). This operation would convert values of that domain to it's corresponding representation in Sage and in the case of complex "type towers" in Axiom, these conversions could be called recursively. It also should be possible to write a default coercion from 'InputForm' to 'SAGEForm' that would work in some cases. 'InputForm' is the existing domain in FriCAS that represents input to the Axiom interpreter. In fact using 'InputForm' in this way is exactly what the current 'axiom.py' interface does now. Computed FriCAS/Axiom values are converted to 'InputForm' (which is just a Lisp 'SExpression') and then from that form to the unparsed linear string form which is returned to Sage (over the pty serial interface). The representation in 'InputForm' eliminates almost all type information but in a lot of cases this is sufficient for Sage to convert to its native form since when converting this representation backwards, Sage makes many of the same type inferences that are made by the Axiom interpreter. But rather than converting 'InputForm' to a linear string representation and back, we want to go directly to a Sage data structure. This means that in many domains a simple generic conversion (e.g. integer literals to integer values) might not be the best one can do. Important semantic information relevant to the representation might be lost. In this case the domain could provide it's own direct coercion to 'SAGEForm'. In this proposed solution, writing SAGEForm in FriCAS is where most of the work would be done. Regards, Bill Page. --~--~-~--~~~---~--~~ 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] Fwd: axiom
-- Forwarded message -- From: Ondrej Certik <[EMAIL PROTECTED]> Date: Tue, Aug 19, 2008 at 4:23 AM Subject: Re: axiom To: Bill Page <[EMAIL PROTECTED]> Yes, please post it to sage-devel and I'll reply there. I wasn't sure what your reply would be, so I started offlist. :) Ondrej On Tue, Aug 19, 2008 at 1:54 AM, Bill Page <[EMAIL PROTECTED]> wrote: > Ondrej, > > I would be glad (with your permission) to post this question and my > reply on-list somewhere - sage-devel if you prefer. > > On Mon, Aug 18, 2008 at 6:50 PM, Ondrej Certik wrote: >> Hi Bill, >> >> since you know both Python and Aldor or Axiom and now you know >> Sage quite a bit, do you think Aldor or the Axiom style of things >> (domains) is viable? I know it's not 100% equivalent to Python and >> it can be fast with Aldor. >> > > Yes, certainly I think Axiom domains are viable. Another way of asking > this question is: if static strongly typed language with first-order > polymorphic dependent types is viable? I think this has been answered > in the positive by other experiments besides Axiom such as the ML > series of languages and Haskell. Axiom (and Aldor) however does have a > slightly different angle on the object-oriented part of the language > by introducing the concept of 'category'. Categories are named subsets > of domains. Categories allow a kind of generic programming that seems > quite suitable to mathematical algorithms but I think this part of the > design is less proven. So a better form of your question might be: Is > the Axiom concept of 'category' viable? The existence of the Axiom > library (and some of the libraries available in Aldor) provide some > positive evidence, but I do not consider it proven. > > The Sage concept of 'parent' is an attempt to capture similar generic > relationships that are represented by categories in Axiom, but I do > not like the fact that this concept needs to be added on to Sage > rather than being supported by some more fundamental feature of > Python, e.g. Python meta-types. > >> What are your personal goals with Axiom (and forks)? >> > > My personal goals do shift a little over time but currently I am > mostly focused on the goal of using many algebraic notions from > mathematical category theory (not the same as the notion of category > in Axiom), in computer algebra. Ultimately, like you I want to be able > to use computer algebra in theoretical physics but perhaps my goals > are a little more abstract. > > http://axiom-wiki.newsynthesis.org/CategoryTheoryAndAxiom > >> I don't know how to judge it. I was looking at fricas mailinglist, >> currently it has 59 members. Sympy list has 172 members. But >> these numbers can easily change, so it imho doesn't say much. >> > > What do you mean by "judge"? Are you trying to consider which of Sympy > or FriCAS is more "viable"? I think you first have to define more > exactly what you mean, e.g. viable for what purposes etc. You have > previously argued that the simply popularity of a language like Python > trumps any technical advantage that FriCAS may or may not have. I do > accept that as largely true. On the other hand Python would *not* be > my language of choice for doing more abstract things in category > theory. > >> Sympy compared to fricas is really stupid, it cannot do many things. > > Probably it is more accurate to compare Sympy to some of the libraries > that are available in Aldor, e.g. 'libAlgebra' and 'BasicMath'. These > libraries also "cannot do many things" but they attempt to do at least > a small number of things reasonably well. FriCAS likewise has the > Axiom library but it is not so easily separable from the rest of the > Axiom environment and interpreter (some people might call it: "the > Axiom ecosystem"). So maybe it is better to compare FriCAS to Sage > and/or Maxima etc. As I understand it Sympy does not attempt to become > such an "ecosystem" but rather just a rather more lightweight library > for Python programmers. Right? > >> So this means that there is a big barrier for people who would like >> to use fricas, even its advanced features doesn't seem to track >> attention. >> > > If you mean that the type system of FriCAS is a big barrier, then I > agree. On the other hand, depending on what you want to do with FriCAS > this might be an essential advantage. > >> So I am just interested in your opinions on this. >> > > Thank you. I am also interested to know other people's opinions on this issue. > > Regards, > Bill Page. > --~--~-~--~~~---~--~~ 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: Fwd: axiom
On Thu, Aug 21, 2008 at 12:50 AM, mhampton wrote: > > I really need to go to sleep so I won't do a top-ten, but here's a > top 2: > > 1) Powerful substitutions and rules. Sage does not have anything > comparable. The .subs() function is buggy even in its limited > domain. There have been previous posts on sage-devel that give > good examples of this. > Because of the subject of this thread I feel justified in giving the following examples from Axiom: http://axiom-wiki.newsynthesis.org/ManipulatingExpressions Perhaps Sage can implement some form of pattern matching and subsitution such is done by Axiom's rewrite rules? I think that in many respects these provide a functionality similar to Mathematica. There is also a similar re-writing system in Maple (applyrule). > ... > On Aug 20, 11:38 pm, William Stein wrote: >> On Wed, Aug 20, 2008 at 9:37 PM, mhampton <[EMAIL PROTECTED]> wrote: >> >> > I used to really enjoy writing programs in mathematica, but maybe >> > I'm a strange person. I only stopped in order to force myself to >> > get fluent with Sage. I think it just depends on your background, >> > what you are used to, and what you want to do. For symbolic >> > calculations and programming I still miss mathematica quite often. >> >> Could you remind me (yet again) of the top ten things you miss about >> mathematica for symbolic calculations? >> --~--~-~--~~~---~--~~ 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: [fricas-devel] Sage's Axiom/FriCAS Interface
erface object"? Why/How does this code behave the same way as the first example? > The Macualay2 interface in sage/interfaces/macaulay2.py has some > good examples of moving objects back and forth between systems. > > Anyway, I did some work on the Axiom interface today such as > doctesting it, removing broken code, adding tab completion, etc. > You can see my changes at > http://trac.sagemath.org/sage_trac/ticket/4028 Great. I have applied these changes to my test version of axiom interface. > Things like the online help didn't work with either the fricas spkg > or just on a local copy, but I'd be more than happy to help adding > that functionality (as well as anything else). > Thanks for your work! I hope it will attract more developers interested in the Axiom interface in Sage. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: Fortran names in unparse
On Sat, Sep 6, 2008 at 12:40 AM, Mike Hansen wrote:
>
> Hello,
>
>> I think it is not so bad since by defining the function float
>> appropriately this can easily parse this into a Sage floating point.
>> If this really is inconvenient then the
>>
>>> The linear representation of the object is much less important
>>> than it being human readable.
>>>
>>
>> -1 No! I disagree strongly with this.
>
> There are two different things going on here.
Yes.
> When you display an object, the purpose is to let the human know
> what the object is.
Yes.
> The unparsed version of float does definitely not do that.
That is just an artifact of the peculiar way that 'unparse' works in Axiom now.
> Converting objects between systems is a totally different problem.
>
As I said, to me this the *most* important issue. If I just wanted the
output printed I probably would not use Sage at all.
>
>> It seems to me that the reason why 2-d output from Maxima and other
>> external packages is disabled is specifically to enable them to
>> interact.
>
> The 2-d output is disabled is simply because it's just more to get
> them to print nicely (for example, if you have a Python list of
> maxima objects).
>
And in the case of a Python list of Axiom objects? How does that work
with Axiom's 2-d output?
But you also said in an earlier thread that using conversions from the
unparsed form was actually the default that is used in the case that
no other specific conversion have been implemented.
>> The Axiom interface was intentionally modeled after the
>> Maxima interface and I still believe that it should operate in
>> essentially the same manner. Your change breaks what I
>> consider to be one of the most important features of the
>> Sage:
> ...
>> sage: axiom(maxima('1/2'))
>>
>> 1
>> -
>> 2
>> sage: maxima(axiom('1/2'))
>> -1
>
> The only reason these examples work is by chance. The current
> code was not designed to work this way, and this approach would
> only work in general for the simplest of examples (such as integers
> or rational numbers).
That is not true. Exactly this sort of example was used to illustrate
the original design of Sage.
> Expecting one system to recognize a particular string
> representation of an object just isn't feasible.
Of course it has limitations but it works reasonably between pari,
maxima, gap, maple andmathematica now and I can see no reason to
deliberately break this in Axiom.
> What should be done is a conversion path Axiom -> Sage -> Maxima
> and vice versa. It's only a couple lines of code to add those hooks.
Yes that is the correct way. What is required to replace the old
unparsed output is to implement Axiom -> Sage analogous to the Maxima
-> Sage. The same should be done with the other interfaces such as
maple and mathematica.
>
>> When producing printed output I suppose that really Sage should do
>> things in a more object-oriented manner and simply ask the external
>> package to display it's own objects in whatever manner is natural for
>> that package. But there needs to be a common "linear representation"
>> available when passing computations from one package to another and
>> to native Sage.
>
> There have two main approaches taken in converting objects from
> other systems into Sage. With Magma, there is some code written
> in Magma's language which produces the Sage commands used to
> create the object. William will be working a lot this upcoming quarter
> on making it so that pretty much any object can go back and forth
> between Sage and Magma.
This could also be done with Axiom, or even more directly by calling
Sage external functions from within Axiom.
> For the Macaulay2 code, all of the logic is on the Sage side.
> You can look at the to_sage method at
> http://www.sagemath.org/hg/sage-main/file/69d774a64568/sage/interfaces/macaulay2.py.
> The way an object gets converted into Sage depends on its type in
> Macaulay2.
>
Do you think the way it was done in maxima.py was not correct?
> What's more important than what string representations you choose
> to use is figuring out how to get answers to questions like "what are
> the generators of the polynomial ring?" or "what is the term order of
> the polynomial ring?", etc.
>
String representations which specify (or assume) generators and term
ordering are available in all systems by design and so I see no good
reason not to use them until a better approach is implemented.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: Fortran names in unparse
On Sat, Sep 6, 2008 at 9:22 AM, Martin Albrecht wrote:
>
>> >> sage: axiom(maxima('1/2'))
>> >> 1
>> >> -
>> >> 2
>> >> sage: maxima(axiom('1/2'))
>> >> -1
>> > The only reason these examples work is by chance. The current
>> > code was not designed to work this way, and this approach would
>> > only work in general for the simplest of examples (such as integers
>> > or rational numbers).
>>
>> That is not true. Exactly this sort of example was used to illustrate
>> the original design of Sage.
>
> AFAIK only interfaces Sage <-> $someothersystem are implemented
> and not $someothersystem <-> $yetanothersystem.
Yes. By definition that is the only way that Sage can operate. A
function like 'foo.get' takes something from Sage (a string) which it
will interpret in the external package foo and returns something (also
a string) which in principle may be interpretable in another package
(or Sage itself) although string manipulations such as substitutions
or other translations might be necessary. Functions more complicated
than 'get' of course could deal with more complex Sage objects than
strings but passing a linear string representation should be the
default.
> However, I think one could make it work like this:
>
> if isinstance(foo, ExpectElement) and not foo.parent() is self:
> foosage = foo._sage_() # i.e. convert to Sage and then to the other
> system return self(foosage)
>
Yes, I think this is a good idea that allows the external interface to
be more intelligent.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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.1.2.alpha4 released
On Tue, Sep 2, 2008 at 9:06 AM, mabshoff wrote:
>
> So expect rc0 with hopefully most of the above fixed. It has been
> a little over 2 weeks since 3.1.1, so we need to get this release
> out of the door.
>
> Sources and a sage.math only binary is in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/
>
> #4028: Mike Hansen: doctest and improve sage/interfaces/axiom.py
> [Reviewed by Michael Abshoff]
I have looked carefully at the changes to 'axiom.py' by Mike Hansen
and I think there is a serious problem: The change relating to
displaying Axiom output in 2-d form breaks an important design
principle in python which all other external packages (and Sage
itself) currently satisfy: "The repr function makes an attempt to
return a string that would yield an object with the same value when
passed to eval()."
sage: p=maxima('1/2')
sage: p==maxima(repr(p))
True
sage: p=maple('1/2')
sage: p==maple(repr(p))
True
sage: p=mathematica('1/2')
sage: p==mathematica(repr(p))
True
sage: p=gap('1/2')
sage: p==gap(repr(p))
True
sage: p=pari('1/2')
sage: p==pari(repr(p))
True
sage: p=axiom('1/2')
sage: p==axiom(repr(p))
False
Mike's changes result in 'repr' returning a "2-d" representation:
sage: repr(p)
' 1\r\n -\r\n 2'
which of course is not correctly parsed as input to axiom.
As discussed in a separate email thread, I believe that the axiom
interface should implement essentially the same functionality as the
maxima interface with at least some extensions to account for the
Axiom type system.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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.1.2.alpha4 released
On Sat, Sep 6, 2008 at 9:31 PM, Bill Page wrote:
>>
>> #4028: Mike Hansen: doctest and improve sage/interfaces/axiom.py
>> [Reviewed by Michael Abshoff]
>
> I have looked carefully at the changes to 'axiom.py' by Mike Hansen
> and I think there is a serious problem: The change relating to
> displaying Axiom output in 2-d form breaks an important design
> principle in python which all other external packages (and Sage
> itself) currently satisfy: "The repr function makes an attempt to
> return a string that would yield an object with the same value when
> passed to eval()."
>
> sage: p=maxima('1/2')
> sage: p==maxima(repr(p))
> True
> ...
After sending this email I reviewed some of the previous messages
about the use of repr in Sage. One way of summarizing this is that
Sage does not actually follow the usual Python convention here (in
spite of my examples :-). But I just wanted to add here that the same
issue applies if one substitutes 'str' for 'repr':
sage: p=axiom('1/2')
sage: str(p)
' 1\r\n -\r\n 2'
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: [sage-devel] Sage 3.1.2.alpha4 released
On Sat, Sep 6, 2008 at 10:32 PM, Mike Hansen wrote:
>
> Another data point:
> sage: str(maxima(1/2)).strip()
> '1\r\n -\r\n
> 2'
>
Oh, groan! It's bad enough that Sage rejects the Python convention
concerning repr but this is terrible. :-(
>
> I think the quality of a particular interface in Sage is inversely
> proportional to the amount of strings you need to pass around.
Actually, I can easily agree with you about that. It's not that I am
so much in favor of passing strings - it's just that in the case of
all (almost all?) other external packages this has turned out to be a
very convenient default, the reason being I think, that in spite of
some obvious differences most systems actually implement a rather
similar input language in their user interfaces. Converting to a
string representation therefore allows one to take advantage of the
assumptions and common type inferences of the target system. But of
course this is sometimes (perhaps even often) not what one really
wants when converting from one system to another.
> For example, http://wiki.sagemath.org/MuPADInterface hardly
> uses any strings at all. Using MuPAD(-Combinat) from that
> interface feels pretty natural. Also notice
>
> sage: mupad(x^2)
>2
> x
>
> I still find the following behavior much worse than the current
> behavior (which is why I made the change):
>
> sage: axiom(2.123)
> float(156649750673941527080,-66,2)
>
> That's not useful to anyone or any other system.
>
By default Axiom uses arbitrary precision floats. This function call
is an attempt to retain all of the available precision in the internal
representation. Perhaps this could be implemented in Sage as a mpfr
function call?
If you wrote:
sage: axiom('2.123::DoubleFloat')
you would see what you expect.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: [sage-devel] Sage 3.1.2.alpha4 released
On Sat, Sep 6, 2008 at 10:49 PM, Bill Page wrote:
> On Sat, Sep 6, 2008 at 10:32 PM, Mike Hansen wrote:
>>
>> I still find the following behavior much worse than the current
>> behavior (which is why I made the change):
>>
>> sage: axiom(2.123)
>> float(156649750673941527080,-66,2)
>>
>> That's not useful to anyone or any other system.
>>
>
> By default Axiom uses arbitrary precision floats. This function call
> is an attempt to retain all of the available precision in the internal
> representation. Perhaps this could be implemented in Sage as a mpfr
> function call?
>
Does this function definition help?
sage: def float(x,e,b):
return 0.0+x*b^e
:
sage: eval(repr(axiom('2.123')))
2.123000
The 0.0 + ... hack just forces coercion to mpfr. Probably there's a better way.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: [sage-devel] Sage 3.1.2.alpha4 released
Here is a better definition:
def float(x,e,b):
return RealField(axiom('precision()$Float'))(x)*b^e
On Sat, Sep 6, 2008 at 11:10 PM, Bill Page wrote:
> On Sat, Sep 6, 2008 at 10:49 PM, Bill Page wrote:
>> On Sat, Sep 6, 2008 at 10:32 PM, Mike Hansen wrote:
>>>
>>> I still find the following behavior much worse than the current
>>> behavior (which is why I made the change):
>>>
>>> sage: axiom(2.123)
>>> float(156649750673941527080,-66,2)
>>>
>>> That's not useful to anyone or any other system.
>>>
>>
>> By default Axiom uses arbitrary precision floats. This function call
>> is an attempt to retain all of the available precision in the internal
>> representation. Perhaps this could be implemented in Sage as a mpfr
>> function call?
>>
>
> Does this function definition help?
>
> sage: def float(x,e,b):
>return 0.0+x*b^e
> :
> sage: eval(repr(axiom('2.123')))
> 2.123000
>
> The 0.0 + ... hack just forces coercion to mpfr. Probably there's a better
> way.
>
--~--~-~--~~~---~--~~
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: [fricas-devel] Axiom interface
Mike,
On Sun, Sep 7, 2008 at 4:00 AM, Mike Hansen wrote:
>
> There is a patch up at
> http://trac.sagemath.org/sage_trac/attachment/ticket/4036/trac_4036-2.patch
> which improves conversions between Axiom and Sage. It defaults
> to your unparsed input form if it can't find anything smarter to do.
Excellent. I have applied this patch to
sage-3.1.2.alpha4-sage.math-only-x86_64-Linux and with fricas-1.0.3
installed. I tried a few things and so far it seems to work great!
I'll have more time to test it thoroughly in the next 24 hours and let
you know if I find any problems.
> Bill, if you're interested, this would be one area that would greatly
> benefit from someone who actually knows Axiom. For example,
> a number of questions came up as I was writing this.
>
Yes I am *very* interested. Thank you again for your continuing work
on this interface.
> * Is there only one global precision for floating point numbers or can
> different floating point numbers each have different precisions?
Axiom has several different types of floating point numbers:
DoubleFloat (double precision), MachineFloat (single precision), and
Float (arbitrary precision). The latter is the default. In Axiom Float
values are presumed exact, i.e. they correspond to rational numbers of
the form (mantissa*2^exponent) where the mantissa and exponent are
arbitrary precision integers, but computations involving Float are
carried out in a given globally-set precision and so have a known
possible error.
For a given Float value one can determine the minimum precision
necessary to represent that value by finding the binary length of the
mantissa. E.g.
Create two approximations to pi:
sage: axiom('precision(68)$Float')
68
sage: p=axiom('%pi::Float')
sage: axiom('precision(100)$Float')
68
sage: q=axiom('%pi::Float')
Then determine their precision:
sage: p.mantissa().length()
68
sage: q.mantissa().length()
100
Because of normalization this is the case for most values.
> What happens if you create a number in one precision and then change the
> precision?
>
New computations are carried out in the new precision after the change
but nothing else changes.
> * Given a domain like "Polynomial Integer", how do I get the base ring
> "Integer" programatically? This would be like the base_ring method in
> Sage.
>
There is no direct way in standard Axiom, but you could for example
ask for the type of the value of the leading coefficient:
sage: p=axiom('x+1/2')
sage: p.type()
Polynomial Fraction Integer
sage: p.leadingCoefficient().type()
Fraction Integer
> * Are constructors like "Polynomial" first class objects? I can't
> seem to assign "Polynomial" to a variable -- it always wants it to
> be filled in like "Polynomial Integer".
>
Types are first class objects in Axiom but 'Polynomial' is not a type
- it is a "functor", i.e. it is a constructor that takes an argument.
'Polynomial(Integer)' on the other hand is a type.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Axiom interface
> On Sun, Sep 7, 2008 at 4:00 AM, Mike Hansen wrote:
>>
>> There is a patch up at
>> http://trac.sagemath.org/sage_trac/attachment/ticket/4036/trac_4036-2.patch
>> which improves conversions between Axiom and Sage. It defaults
>> to your unparsed input form if it can't find anything smarter to do.
>
On Sun, Sep 7, 2008 at 9:46 PM, Bill Page wrote:
> Excellent. I have applied this patch to
> sage-3.1.2.alpha4-sage.math-only-x86_64-Linux and with fricas-1.0.3
> installed. I tried a few things and so far it seems to work great!
> I'll have more time to test it thoroughly in the next 24 hours and let
> you know if I find any problems.
>
Mike,
So far everything is looking good to me in your patch. :-) I wonder if
there is still time to get it into the next release of Sage?
I have a question about the best way to add some new functionality to
the axiom interface. Maybe this is an interface design issue or maybe
it is just a Python question ...
In Sage we can call the Axiom 'guess' function (written by Martin
Rubey) to guess expressions for integer sequences. Eg.
sage: g=axiom('guess [1,3,5,7,9]')
sage: g
n 2
[[function= [[x ]f(x): (x - 2x + 1)f(x) - x - 1= 0],order= 0]]
sage: g.type()
List Record(function: Expression Integer,order: NonNegativeInteger)
---
As I understand the code in axiom.py, I can write:
sage: g[1]
n 2
[function= [[x ]f(x): (x - 2x + 1)f(x) - x - 1= 0],order= 0]
to return the first item in the Axiom List because __getitem__ is
defined in class AxiomElement. Right?
But now I have something of this type:
sage: g[1].type()
Record(function: Expression Integer,order: NonNegativeInteger)
The labels (e.g. 'function' and 'order' above) in an Axiom Record are
rather like attributes in Python. In Axiom I can write 'g(1).function'
and 'g(1).order'
sage: axiom(g.name()+'(1).function')
n 2
[[x ]f(x): (x - 2x + 1)f(x) - x - 1= 0]
sage: axiom(g.name()+'(1).order')
0
So I thought maybe I could also define
def __getattr__(self, attrname):
if attrname[:1] == "_":
raise AttributeError, attrname
if str(self.type()).startswith('Record'):
P = self.parent()
return P('%s.%s'%(self.name(), attrname))
else: raise AttributeError, attrname
in AxiomElement. And then in Sage write more naturally:
sage: g[1].function
n 2
[[x ]f(x): (x - 2x + 1)f(x) - x - 1= 0]
and I get the result I hoped for! :-) But when I write:
sage: g[1].order
I do not get the expected result of 0. :-(
How can I persuade Sage to treat '.order' as a call to __getattr__ ?
As far as I understand, 'order' is a method inherited via
ExpectElement from RingElement. I do not understand why ExpectElement
subclasses RingElement. Why Ring? Anyway, in general I am looking for
a convenient and natural way to access elements of Axiom type Record
and Union.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: Axiom interface
Mike,
Here's a minor issue with your patch to axiom.py.
I noticed that you included a hack for Axiom function names with ? and
! suffixes. As you know Sage/Python does not permit these characters
in identifiers. The Axiom convention is that functions with names
ending in ? return True or False and functions with names ending in !
modify mutable data structures in-place.
Rather than using _q and _e as suffixes representing ? and !
respectively, I think it would be more in keeping with Sage
conventions to use prefixes is_ and set_ as below:
-
class AxiomFunctionElement(FunctionElement):
def __init__(self, object, name):
"""
TESTS:
sage: a = axiom('"Hello"') #optional -- requires Axiom
sage: a.is_upperCase#optional
upperCase?
sage: a[1].is_upperCase()
true
sage: a.set_upperCase #optional
upperCase!
sage: a.set_upperCase() #optional
"HELLO"
"""
if name.startswith("is_"):
name = name[3:] + "?"
elif name.startswith("set_"):
name = name[4:] + "!"
FunctionElement.__init__(self, object, name)
--
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] Re: Axiom interface
Mike,
Here is another function to add to axiom.py:
def compile(self,code, filename="temp.spad", verbose=False):
"""
Compiles a library module written in spad
EXAMPLES:
sage: axiom.compile('''
)abbrev package FOO foo
Foo():with
bar: Integer->Integer
== add
bar(x) == x+1
''')
sage: axiom.bar(1)
2
"""
fh=open(filename,"w")
fh.write(code)
fh.close()
s = self.eval(")compile "+filename)
if verbose:
print s
else: # cleanup some of the mess
cleanup = re.compile(r'^\)compile [^\n]*\n|'
r'(?:^\s*Compiling[^\n]*\n|'
r'\n\s*;;[^\n]*\n|'
r'\n\s*---[^\n]*\n|'
r'\n\s*compiling into[^\n]*\n|'
r'\n\s*\n)|'
r'\n\s*Time:[^\n]*\n|'
r'\n\(time[^\n]*\n',
re.DOTALL+re.MULTILINE)
s=cleanup.sub(r'\n',s)
s=cleanup.sub(r'\n',s)
print cleanup.sub(r'\n',s)
This provides preliminary support for compiling new Axiom library code
written in the Spad language.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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] Aldor for Sage
In email with subject: [fricas-devel] Re: Alert, heavy patch committed ...
On Wed, Sep 10, 2008 at 2:30 AM, Martin Rubey wrote:
>
> Did you use --with-algebra-optimization="((speed 3) (safety 0))" ?
> When you do, the resulting friCAS should be quite a bit faster...
>
I used only the defaults in configure. I will try --with-algebra-optimization
next.
> I am *very* impressed by the robustness of Peter and Ralf's aldor
> interface! And it's wonderful to be able to build it just using
> --enable-aldor. This uncovers quickly many little bugs.
>
Yes, it's great.
My next objective is to make Aldor available to Sage users via the
Axiom interface in Sage. Recently Mike Hansen has made some major
improvements to the 'axiom.py' interface that will likely be available
in the next release of Sage. And I recently added the ablity to run
the Axiom library compiler from the Axiom interface in Sage, e.g. like
this:
sage: axiom.compile("""
)abbrev domain TEST Test
Test(): with ...
""")
This is Spad code by default but it would already work to compile
aldor code if an appropriate file name is provided:
sage: axiom.compile("""
Test(): with { .. }
== add {
...
}
""", filename="test.as")
(Unlike Spad, file names are significant when compiling Aldor code in Axiom.)
So what I would like to do in produce an update to the Sage
'fricas-1.0.3.spkg' optional package to include building the Aldor
interface if Aldor is present.
The Sage people, however are very concerned about the build time for
packages. To solve that problem for FriCAS Waldek implemented the
cached-Lisp approach. The spkg distribution of FriCAS includes
machine-generated architecture-independent Lisp code. When the package
is installed by a Sage user, FriCAS is built from the cached Lisp in
about 5 to 10 minutes (compared to 1 to 2 hours from raw source).
The build time for the Aldor interface will be an issue unless we can
find a way to do something similar for it. I know that Aldor is able
to generate high-level architecture-independent intermediate code and
even Lisp code, but I am not sure if the make scripts written by Ralf
make caching of this intermediate code or Lisp possible. Building the
Aldor interface currently takes about 30 minutes. We know that this
can be reduced at the expense of a larger library file by optimizing
the use of 'ar'. (Maybe this is due to a bug in 'ar'? Or is it a
problem in the way we are using 'ar'?)
It would be nice to reduce the build time for the Aldor interface to
something under 5 minutes.
With the work being done by Pippijn on the Aldor compiler, it may soon
also be possible to package Aldor itself as an optional Sage package.
Because of licensing issues the FriCAS and Aldor package for Sage must
currently remain separate. I am doubtful however if compiling Aldor
from source can be made much less than 10 or 15 minutes in total. So
maybe it is a good thing that they remain separate packages anyway.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] How do I get the most current version of axiom.py
Martin, The patches are at: http://trac.sagemath.org/sage_trac/attachment/ticket/4036 Click on for example: trac_4036-2.patch http://trac.sagemath.org/sage_trac/attachment/ticket/4036/trac_4036-2.patch This displays the patch with additions and deletions highlighted. At the bottom of the page under the heading: Download in other formats Click the link * Original Format This is the format you can use with patch. There were a couple of other changes that I suggested in emails to Mike (including the compiler patch) but he has not yet included them here yet. Regards, Bill Page. On Sat, Sep 13, 2008 at 2:05 PM, Martin Rubey <[EMAIL PROTECTED]> wrote: > > I see the trac items, but I do not see how to get the latest version of > axiom.py... > > Thanks, > > Martin --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: axiom interface, was:: How do I get the most current version of axiom.py
Martin, Without trying to solve the more general problem of rationalizing InputForm and unparse in FriCAS, attached is a patch to 'axiom.py' (relative to sage-3.1.2 + Mike's patches (trac_4036.patch trac_4036-2.patch trac_4036-3.patch trac_4036-fixes.patch)) that solves the problem of parsing 'sin x' so that now we get: sage: axiom(sin(x)).sage() sin(x) @@ -693,7 +731,11 @@ in unparse_input_form +if r: +# juxtaposition is always function application +if axiom.get(self.type()) != "String": # except in strings +return re.sub(r'([^ ]+) ([^ ]+)',r'\1(\2)', r.groups(0)[0]) +else: +return r.groups(0)[0] +else: +return s adds the missing parenthesis. We need to deal here with the special case of a String. @@ -761,7 +803,8 @@ in _sage_ +if type == "String": +return self.unparsed_input_form() handles conversion of Axiom strings to Sage strings. @@ -559,13 +595,15 @@ is a minor fix to axiom.type so that calls 'typeOf'. @@ -820,17 +867,17 @@ changes the hack for the ! and ? suffix in Axiom function names form xxx_e and xxx_q to what I consider a more common convention of set_xxx and is_xxx. This patch also includes the necessary code to compile spad files @@ -362,6 +362,41 @@ Regards, Bill Page. On Sat, Sep 13, 2008 at 7:07 PM, Martin Rubey wrote: >> >> I think the following *should* work... >> >> sage: a = axiom.sin(x) > > I hacked around axiom.py a little, and came up with the following: > >#If all else fails, try using the unparsed input form >try: >import sage.misc.sage_eval >try: >vars = str(self.variables())[1:-1] >return > sage.misc.sage_eval.sage_eval(self.unparsed_input_form(),cmds='var(\''+vars+'\')') >except: >return > sage.misc.sage_eval.sage_eval(self.unparsed_input_form()) >except: >raise NotImplementedError > > This takes into account the fact that in sage we have to introduce all > variables... > > Unfortunately, we are still not there, because unparsed_input_form returns > > 'sin x' > > (In FriCAS, one can omit parentheses, if a function takes only a single > argument.) > > Is there an easy way to massage this string in python, or should I rather do > it > in FriCAS? (I guess I should...) > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- axiom.py.patch Description: Binary data
[sage-devel] Re: [fricas-devel] How do I get the most current version of axiom.py
Mike,
Perhaps you are already aware that the 'FOO.NRLIB' is not really a
temporary thing. This is where the compiler puts it's object files
prior to loading them. After compiling a spad file like this:
)co foo.spad
which assuming the the file 'foo.spad' starts with
)abbrev domain FOO Foo
...
will create the directory 'FOO.NRLIB', it is also possible (usually in
another session) to just load the file like this:
)lib FOO
and use it as you would any other code in the Axiom library.
After the fricas-1.0.3.spkg installation the Axiom library is located here:
$SAGE_ROOT/local/lib/fricas/target/x86_64-unknown-linux/algebra
This is where all the algebra-related object files are located.
Probably this is also a logical place to set as the default location
when Sage starts FriCAS. That way, after compiling some spad code in
Sage like this
sage: axiom.compile('''
)abbrev package FOO Foo
Foo():with
bar: Integer->Integer
== add
bar(x) == x+1
''')
sage: exit
Later you are assured that you can start Sage again and write:
sage: print axiom.eval(')lib FOO')
Foo will be automatically loaded when needed from
/home/page/sage-3.1.2.alpha4-sage.math-only-x86_64-Linux/devel/sage-main/sage/interfaces/FOO.NRLIB/code
sage: axiom.bar(1)
2
without having to re-compile the source for FOO again. The NRLIB would
remain there indefinitely until replaced or deleted by the user.
Regards,
Bill Page.
On Sat, Sep 13, 2008 at 5:15 PM, Bill Page <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 13, 2008 at 3:00 PM, Mike Hansen wrote:
>> Bill Page wrote:
>>> There were a couple of other changes that I suggested in emails
>>> to Mike (including the compiler patch) but he has not yet included
>>> them here yet.
>>
>> I have a patch for your changes, but we need to find a way so that
>> with your example in compile, FriCAS does not make a
>> "FOO.NRLIB" directory in the current directory. I can get a
>> temporary directory from Sage, but I don't know how to tell FriCAS
>> to use it.
>>
>
> In FriCAS you can change the current directory with the commmand:
>
> )cd /tmp
>
> now
>
> )compile ...
>
> will create FOO.NRLIB in /tmp
>
> Regards,
> Bill Page.
>
--~--~-~--~~~---~--~~
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: [fricas-devel] How do I get the most current version of axiom.py
On Tue, Sep 16, 2008 at 10:11 PM, Bill Page wrote:
> ...
> After the fricas-1.0.3.spkg installation the Axiom library is located here:
>
> $SAGE_ROOT/local/lib/fricas/target/x86_64-unknown-linux/algebra
>
> This is where all the algebra-related object files are located.
> Probably this is also a logical place to set as the default location
> when Sage starts FriCAS.
> ...
Here is a small patch that sets this default path:
$ diff -a u axiom.py-old axiom.py-new
--- axiom.py-old2008-09-16 19:32:18.0 -0700
+++ axiom.py-new2008-09-16 19:38:34.0 -0700
@@ -29,6 +29,11 @@
the FriCAS fork of the Axiom project by Waldek Hebisch that
uses pre-compiled cached Lisp code to build Axiom very quickly
with clisp.
+-- Mike Hansen (2008-09) made major improvements to the interface
+ including conversion to and from native Sage.
+-- Martin Rubey (2008-9) contributed conversion of Axiom expressions
+ like 'sin(x)' to sage expressions.
+-- Bill Page (2008-9) implemented compiling Spad code
If the string "error" (case insensitive) occurs in the output of
anything from axiom, a RuntimeError exception is raised.
@@ -239,6 +244,7 @@
out = self._eval_line(')set functions compile on', reformat=False)
out = self._eval_line(')set output length 245', reformat=False)
out = self._eval_line(')set message autoload off', reformat=False)
+out = self._eval_line(')cd
'+SAGE_ROOT+'/local/lib/fricas/target/x86_64-unknown-linux/algebra',
reformat=False)
def _read_in_file_command(self, filename):
"""
@@ -368,7 +374,7 @@
EXAMPLES:
sage: axiom.compile('''
-)abbrev package FOO foo
+ )abbrev package FOO Foo
Foo():with
bar: Integer->Integer
== add
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
axiom.py-2.patch
Description: Binary data
[sage-devel] Re: [fricas-devel] How do I get the most current version of axiom.py
On Tue, Sep 16, 2008 at 10:46 PM, Mike Hansen wrote:
> ...
> It is better to put it somewhere in DOT_SAGE
>
You mean like:
out = self._eval_line(')cd '+DOT_SAGE+'/fricas/algebra', reformat=False)
How/when to create this directory?
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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: [fricas-devel] How do I get the most current version of axiom.py
On Tue, Sep 16, 2008 at 10:51 PM, Bill Page wrote:
> On Tue, Sep 16, 2008 at 10:46 PM, Mike Hansen wrote:
>> ...
>> It is better to put it somewhere in DOT_SAGE
>>
>
> You mean like:
>
>out = self._eval_line(')cd '+DOT_SAGE+'/fricas/algebra',
> reformat=False)
>
> How/when to create this directory?
>
Here's another patch (stolen from gap.py):
--- axiom.py-old2008-09-16 19:38:34.0 -0700
+++ axiom.py-new2008-09-16 19:57:52.0 -0700
@@ -155,6 +155,9 @@
seq = 0
COMMANDS_CACHE = '%s/axiom_commandlist_cache.sobj'%DOT_SAGE
+if not os.path.exists('%s/fricas/algebra/'%DOT_SAGE):
+os.makedirs('%s/fricas/algebra/'%DOT_SAGE)
+
# The Axiom commands ")what thing det" ")show Matrix" and ")display
# op det" commands, gives a list of all identifiers that begin in
@@ -244,7 +247,7 @@
out = self._eval_line(')set functions compile on', reformat=False)
out = self._eval_line(')set output length 245', reformat=False)
out = self._eval_line(')set message autoload off', reformat=False)
-out = self._eval_line(')cd
'+SAGE_ROOT+'/local/lib/fricas/target/x86_64-unknown-linux/algebra',
reformat=False)
+out = self._eval_line(')cd '+DOT_SAGE+'/fricas/algebra',
reformat=False)
def _read_in_file_command(self, filename):
"""
-
[EMAIL PROTECTED]:~$ ~/sage-3.1.2*/sage
--
| SAGE Version 3.1.2.alpha4, Release Date: 2008-09-02|
| Type notebook() for the GUI, and license() for information.|
--
sage: axiom.compile('''
: )abbrev package FOO Foo
: Foo():with
: bar: Integer->Integer
: == add
: bar(x) == x+1
: ''')
FOO abbreviates package Foo
initializing NRLIB FOO for Foo
compiling exported bar : Integer -> Integer
FOO;bar;2I;1 is replaced by +x1
Cumulative Statistics for Constructor Foo
finalizing NRLIB FOO
Processing Foo for Browser database:
WARNING in |FOO;bar;2I;1| in line 6 :
variable $ is not used.
Misspelled or missing IGNORE declaration?
0 errors, 1 warning
Foo is now explicitly exposed in frame initial
Foo will be automatically loaded when needed from
/home/page/.sage/fricas/algebra/FOO.NRLIB/code
sage: exit
Exiting SAGE (CPU time 0m0.06s, Wall time 0m4.99s).
Exiting spawned Axiom process.
[EMAIL PROTECTED]:~$ ~/sage-3.1.2*/sage
--
| SAGE Version 3.1.2.alpha4, Release Date: 2008-09-02|
| Type notebook() for the GUI, and license() for information.|
------
sage: print axiom.eval(')lib FOO')
Foo is now explicitly exposed in frame initial
Foo will be automatically loaded when needed from
/home/page/.sage/fricas/algebra/FOO.NRLIB/code
sage: axiom.bar(1)
2
sage:
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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.1.2.rc5/final released
Michael, #4028: Mike Hansen: doctest and improve sage/interfaces/axiom.py [Reviewed by Michael Abshoff] was originally in 3.1.2.alpha4 but got removed somewhere along the line. In trac is now says it's closed and "Merged in Sage 3.1.2.alpha4" but I do not think that is actually true. Or did some part of this actually get into 3.1.2? Mike, Martin and I have been discussing and improving on this change in http://trac.sagemath.org/sage_trac/ticket/4036 which is still listed as "needs work". Can we set some kind of milestone for getting this into the next release? What do we really need to do to make this happen? I have sent a few more patches related to this to Mike, but I am not sure if he really wants to carry this task or not. Mike? Also I sent Michael a request some days ago that I me added as a user to trac, that way I could post patches there (once I figure out how). Is there any problem with that? Regards, Bill Page. On Wed, Sep 17, 2008 at 12:43 AM, mabshoff wrote: > > Hello folks, > > after 251 closed tickets here we go. This is rc5/final and likely > identical to the 3.1.2 release. There was an rc4 that never got > publicly announced since it had some Gremlins in it. As far as we know > there are no know build issues and doctest failures (assuming you > don't have Fink or MacPorts in $PATH). Give it a whirl and report any > issue as usual. > > Sources are available at > > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/ > > Next up is 3.1.3 which should be not as drawn out, i.e. a quick bug > fix release. If you have patches in trac please check them out and > make sure they apply to 3.1.2 and pass doctests. > --~--~-~--~~~---~--~~ 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: in-place WYSIWYG text-cell editing
On Fri, Oct 10, 2008 at 7:45 PM, Jason Grout wrote: > > mhampton wrote: >> Shift-click for a text cell? That doesn't do anything different at >> the moment, does it? > > Any objections to creating or editing a text cell on a shift-click? In > other words, when the "new cell" line appears, shift-click will create > a text cell. Shift-clicking on a text cell will make it available for > in-place editing. > > A keyboard modifier seems okay since you'll generally starting > writing text in the cell immediately anyway. > +1 I miss a simple and natural way to enter plain text. However I am also in favor of including some visual clue, e.g. like the 'evaluate' link. In spite of how ugly it seemed to me at first, I have to admit that seems very intuitive to many of the people I have introduced to Sage. I have observed that helps get them over some initial shyness with the unfamilar keystrokes. They learn to shift-Enter a little later. Maybe one could put an 'add text' link formatted like 'evaluate' somewhere near the top right of the cell? These links could be visible by default, but it might also be nice to be able to turn them off (display:none) when one get tired of the cues. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: SF.net SVN: fricas:[429] releases/1.0.4/
> On Oct 28, 6:28 am, Ralf Hemmecke wrote: >> > Tag 1.0.4 release. >> > >> maybe the .spkg should also change its version number. I still have >> no clue where the standard place for the fricas.spkg is. Is there a >> link on the Axiom-Wiki? > ??? The "standard place" for the fricas-xxx.spkg is on the sage.math server, of course. There are links on Axiom-Wiki to this server, but probably there should also be some wiki pages specifically devoted to the Axiom interface for Sage. Right now besides the mention in AboutSage all we have is an out-of-date page here: http://axiom-wiki.newsynthesis.org/SandBoxAxiomInterface Or did you mean something else? Are you thinking that creation of the spkg should become a direct part of the fricas distribution? On Tue, Oct 28, 2008 at 9:41 AM, mabshoff wrote: > I don't know, but standard procedure is to open a ticket in Sage's > trac and link to an updated FriCAS.spkg. Someone reviews it and > given a positive review I push it on the main sagemath.org spkg > repo so that "sage -optional" lists it. > Ralf, I would strongly encourage you (and any other interested fricas developers) to obtain an account on the Sage trac system. One thing that is badly needed right now is a reviewer for the changes to the Axiom interface posted by Mike Hansen: http://trac.sagemath.org/sage_trac/ticket/4036 If/when these changes are reviewed, they will be included in the next Sage release. I have tested these changes and they work fine for me. I have also made some local extensions which I have posted by email to Mike Hansen and the sage developer list. Michael Absoff did setup a trac account for me but I just have not found enough time to complete the Sage trac review process. As I understand the process, I should also create a new trac entry for the additional changes I have made and post a patch there. Other FriCAS/Sage developers working in parallel on this would be a very good thing. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: [fricas-devel] Re: field extensions
On Tue, Oct 28, 2008 at 12:39 PM, Martin Rubey wrote:
>
> Waldek Hebisch writes:
>
>> Martin Rubey wrote:
>> >
>> > Waldek Hebisch writes:
>> >
>> > > 2) I think we have all tools to do actual computations: we can
>>> > factorise in algebraic extensions, so we can verify irreducibility
>>> > assumptions. We have functions to compute primitive elements.
>> >
>> > I was unable to use the latter. Do you think you could compute the
>> > example I gave with FriCAS?
>> >
>>
>> Is te following what you want?
>>
>> pol1 := x^2+1
>> pol2 := z^3-2
>> primrec := primitiveElement([pol1, pol2], [x, z])$PrimitiveElement(Fraction
>> Integer)
>> Ae := SAE(Fraction(Integer), SparseUnivariatePolynomial(Fraction(Integer)),
>> primrec.prim)
>> (primrec.poly.1::Ae)^2
>> (primrec.poly.2::Ae)^3
>
>
> Oh, how very very nice! I didn't know about PrimitiveElement. Many
> thanks, I'll sent this to my colleague!
>
> BTW: this also means that the polynomial is not unique? I got a
> different one using Sage/pari...
>
Here also is a Sage/Fricas example of this computation:
sage: var('z')
z
sage: pol1=x^2+1
sage: pol2=z^3-2
sage: axiom.eval(')expose PrimitiveElement')
''
sage: primrec=axiom.primitiveElement([pol1,pol2],[x,z])
sage: Ae=axiom('SAE(Fraction(Integer),
SparseUnivariatePolynomial(Fraction(Integer)),%s.prim)'%primrec.name())
sage: axiom('(%s.poly.1::%s)^2'%(primrec.name(),Ae.name()))
- 1
sage: axiom('(%s.poly.1::%s)^3'%(primrec.name(),Ae.name()))
12 5243 4160 32106 28481 9828
- ? - - ? + - ? - - ? + - ? + -
18659 74636 18659 18659 37318 18659
sage:
The string manipulation in the last three lines is the kind of thing
that I would like to eliminate from the Sage/Axiom user interface by
improving the integration between Sage and Axiom types in 'axiom.py'.
If any has some ideas about how best to do this, I would be very
interested.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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-combinat-devel] Categories for the working programmer
Warning: This email consists mostly of a "rant" on category theory, computer algebra, and a comparison of implementations that is somewhat tangential to the main subject. >> On Tue, Aug 19, 2008 at 8:14 PM, Bill Page wrote: >> >> The Sage concept of 'parent' is an attempt to capture similar >> >> generic relationships that are represented by categories in >> >> Axiom, but I do not like the fact that this concept needs to >> >> be added on to Sage rather than being supported by some >> >> more fundamental feature of Python, e.g. Python meta-types. > >> William Stein: >> Unlike you, I personally like that parent is not a fundamental >> feature of Python, but a "design pattern" that can be implemented >> on top of Python. That means one can directly use the same idea >> in C/C++/etc. code. On Sun, Nov 9, 2008 at 10:31 AM, Nicolas M. Thiery wrote: > > Let me reuse this thread for further discussions about categories. > > To start with: a disclaimer. I am a complete practitioner here. > Language design is not at all my specialty. But I do have a bit > of experience using and designing categories in MuPAD > (MuPAD-Combinat adds about 60 categories to the standard > MuPAD hierarchy) as a design pattern for organizing and factoring > out generic code. > Thank you for "re-using" this thread. :-) I still think this subject is important so let me start by explaining why I did not continue the original thread. William's comment quoted above struck me as representing a view of computer algebra systems so different than mine that I did not think there was any chance of consensus - so merely stating opinions seemed like an adequate closure of the subject at that time. In spite of this I do still strongly support the idea of Sage, including many of William's other visions of how it should/does work. And in fact I find myself using Sage more and more these days in spite of my continuing devotion to most other things more Axiom-related. The difference of opinion about parents and categories in Sage versus Axiom probably runs rather deep. I was amused to realize that this difference might even be summarized rather well by your choice of title for this thread: "Categories for the working programmer". The significance of this title might be lost on some readers who might not know the classic text on category theory by Saunders Mac Lane: "Categories for the working Mathematician". Not only does the term "category" mean something very different in these titles, but also there is a fundamental different in the point of view. It comes down to this question: What is one really doing in computer algebra: *programming* or *mathematics* ??? In perhaps a too terse manner, I think the difference between Axiom and Sage can be summarized in the following anecdotal manner: The developers of Axiom were/are largely computer scientists (aka. programmers) attempting to implement a system for doing mathematics on a computer. The developers of Sage on the other hand are (mostly) mathematicians attempting to program a computer system to do mathematics. The peculiar thing perhaps is that there is somewhat a reversal of the usual perspective of mathematics versus computer science: Sage is often pragmatic where Axiom is pedantic. > My feeling is that we need both concepts of parents *and* of > categories (more rant about this upon request). And I like the idea > of having them as design pattern not tighten too much to the language. > In particular, this means that we can progressively improve the design > pattern to increase its expressiveness in our context. We used that > a lot in MuPAD. Of course, in the long run, further and deeper support > from the language could help improve the safety. > I think there is something deeper at issue here as well. Python is a dynamically typed language while Axiom is statically typed. What this means is that in Python it is the *values* that carry the type information and the associated methods while in Axiom it is the container, i.e. variable that carries the type. This distinction is obscured somewhat by Axiom's interpreter which does try to implement a kind of compromise (and bridge) between these two ideas about types, but it is very obvious when one compares the Axiom library compiler language Spad and Python. This difference has a big impact on the role of parents in Sage and categories in Axiom. To some extent I view the notion of "parent" in Sage as attempting to "put back" some of the rigor (and type safely) that is lost in the dynamic approach to typing implemented in Python. The library compiler in Axiom on the other hand can (at least in principle) make good use of static typing to produce type-safe and efficient machine code. I ha
[sage-devel] Re: [sage-combinat-devel] Categories for the working programmer
On Tue, Nov 11, 2008 at 12:50 AM, Mike Hansen wrote: > > On Mon, Nov 10, 2008 at 9:31 PM, Bill Page wrote: >> ... >> It seems to me that of all the existing computer algebra systems, >> because of it's strong and often pedantic type system, Axiom >> seems most compatible with taking category theory as a foundation. >> Unfortunately in most respects Axiom does not do nearly enough to >> exploit this. Magma apparently also takes a formal approach that is >> at least in part motivated by category theory but I was rather >> disappointed to see how little of this remains in the approach now >> implemented in Sage. > > Just a quick note. Categories in Sage are modeled after the > mathematical categories rather than Ralf's universal algebra notion. > That is, you have objects, morphisms, functors, homsets, etc. They > just happen to be a convenient place to put generic methods for their > objects. > Although I am vaguely aware that Sage does implement these notions, even after working with Sage now for the last two years I still know very little about what is actually implemented and what is planned. Unless I missed it, it seems to me that there is an extreme lack of documentation on all of this in Sage. Also, I have some trouble reconciling your comments with the comments of Nicolas Thiery at the start of this thread. Is Nicolas talking about mathematical categories in Sage or something more like categories in Axiom/MuPAD? Finally, I should note that I do not agree with Ralf's views (quoting Doye's article on Aldor) on the importance of universal algebra notions to categories in Axiom. But I do think that this article is very relevant to the subject of coercions in computer algebra and so also important in Sage. Regards, Bill Page. --~--~-~--~~~---~--~~ 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: Categories for the working programmer
On Thu, Nov 13, 2008 at 3:24 AM, Robert Bradshaw wrote: > > On the note of making it easy to understand, what would people think > of renaming Parent to SetObject or even just Set? This would clear up > the very frequently asked question "what is a Parent?" to give it a > more mathematically-grounded name. > Although I seriously doubt that the Sage developers would agree to change the name of something quite this fundamental in Sage, since I was/am one of the people who have been most critical "parent" in Sage, it is hard to let this pass without comment. In fact we have discussed this previously in the thread: http://groups.google.com/group/sage-devel/msg/423c69d7f48dcd3d David Harvey proposed what I think is a more precise definition of "parent": >> Bill Page wrote: >>> How does it related to the concept of "parent" - which seems equally >>> ill-defined to me? > On Jun 3, 2008, at 10:04 PM, Robert Bradshaw wrote: >> A Parent is an Object in the category of Sets, David Harvey wrote: > huh? Don't you mean to say something more like "a parent is an object > of a concrete category", i.e. a category C with a faithful functor > f : C -> Set, such that the "elements" (as understood by Sage) of the > parent P are exactly the elements of f(P)? I rather like David's definition because it is careful to make a connection to category theory. Unfortunately, as far as I can tell Sage does not directly implement this notion. I mean: there is no such identifiable concrete category in Sage as such, even if it is true that a parent "behaves" in this manner. In any case, perhaps it would be helpful if 'parent' was replaced with sage: concrete_category(1) Integer Ring But there is a further complication since there already is some kind of "category" associated with elements: sage: category(1) Category of elements of Integer Ring I do not understand what this really is yet. It does not seem to me that the elements of Integer Ring actually form a category as such. Regards, Bill Page. --~--~-~--~~~---~--~~ 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] problem with sage -update to sage-2.1 on SuSE 10.2
While trying to update by sage-2.0 installation on SuSE 10.2 I received the following error: [EMAIL PROTECTED]:~/sage-2.0> ./sage -update ... sage-2.1.0.1/.hg/data/sage/schemes/elliptic_curves/ell_rational_fie1d.py.1 Sage-2.1.0.1/.hg/data/sage/schemes/elliptic_curves/formal_group.py.1 Finished extraction There is no spkg-install script, no setup.py, and no configure script, So I do not know how to install /home/wapape/sage-2.0/spkg/standard/sage-2.1.0.1.spkg. make: *** [installed/sage-2.1.0.1] Error 1 real 15m46.335s user 2m42.922s sys 4m45.238s [EMAIL PROTECTED]:~/sage-2.0> -- Any advice? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem with sage -update to sage-2.1 on SuSE 10.2
On February 10, 2007 1:10 AM William Stein wrote: > > Use "sage -upgrade" not "sage -update". > Yes, sorry, that was a typo. I *did* use sage -upgrade ( 'sage -update' gives an error message now.) > > On Fri, 09 Feb 2007 22:53:38 -0700, Bill Page > <[EMAIL PROTECTED]> wrote: > > > > > While trying to update by sage-2.0 installation on SuSE 10.2 > > I received the following error: > > > > [EMAIL PROTECTED]:~/sage-2.0> ./sage -update > > ... > > > sage-2.1.0.1/.hg/data/sage/schemes/elliptic_curves/ell_rationa > l_fie1d.py.1 > > Sage-2.1.0.1/.hg/data/sage/schemes/elliptic_curves/formal_group.py.1 > > Finished extraction > > There is no spkg-install script, no setup.py, and no > configure script, > > So I do not know how to install > > /home/wapape/sage-2.0/spkg/standard/sage-2.1.0.1.spkg. > > make: *** [installed/sage-2.1.0.1] Error 1 > > > > real 15m46.335s > > user 2m42.922s > > sys 4m45.238s > > [EMAIL PROTECTED]:~/sage-2.0> > > > > -- > > > > Any advice? > > > > Regards, > > Bill Page. > > > > > > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem with sage -update to sage-2.1 on SuSE 10.2
On February 10, 2007 1:55 AM William Stein wrote: > ... > Your download must have been corrupted or something. Delete > >spkg/standard/sage-2.1.0.1.spkg > > and try again. > ... Thanks, that worked. During the initial 'sage -upgrade' step, I did not receive any notice of problems with the download. After deleting the file and repeating 'sage -upgrade' everything seems to have worked as expected. Could this indicate some unreliability in the download process that is used by -upgrade? Perhaps the download should incorporate some kind of download verification by checking signatures such as an 'md5sum'? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] first axiom command hangs sage
In sage-2.0 and sage-2.1.0.1 the first Axiom command that I enter
hangs the sage process but if I hit control-c and re-enter the
command, it works as it used to work. This also affects Axiom
commands entered via the notebook.
sage: axiom('1+1')
... waits indefinitely ...
^C
...
sage: axiom('1+1')
2
sage:
---
I will take a look at the axiom inteface code when I get time
but perhaps someone already knows what might have changed in
the way the interface works?
BTW, I am using the axiom4sage-0.1 download from sage.math but
I had a problem with the simple
sage -I axiom4sage-0.1.spkg
command. I apparently received only a partial download and the
install failed. Later, I downloaded axiom4sage-0.1.spkg directly
to the sage root directory and repeated the command:
sage -I axiom4sage-0.1.spkg
Then Axiom was built and installed as expected on my OpenSuSE 10.2
x86 linux system.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: problem with sage -update to sage-2.1 on SuSE 10.2
On February 11, 2007 4:24 PM William Stein wrote: > > Regarding your question about the axiom interface, I'll check it > out. > Thanks. > By the way, has any progress been made on porting axiom to OS X? > Yes. Some Axiom developers have reported successfully building the experimental build-improvements branch of Axiom on OS X. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] FW: [Axiom-math] [ANN] Axiom Workshop 2007
Perhaps of interest to some Sage developers ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Rubey Sent: February 22, 2007 2:30 PM To: axiom-mail; axiom-math; aldor-l; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Axiom-math] [ANN] Axiom Workshop 2007 Dear all, We are happy to announce the _ (_) __ ___ ___ ___ _ __ ___ / _` \ \/ / |/ _ \| '_ ` _ \ | (_| |> <| | (_) | | | | | | \__,_/_/\_\_|\___/|_| |_| |_| _ (_) __ __ _ _ __ _ __ _ \ \/ / __ \| __ \| |/ // | | | |/ __ \| __ \ \ \ /\ / / | | | |__) | ' /| (___ | |__| | | | | |__) | \ \/ \/ /| | | | _ /| < \___ \| __ | | | | ___/ \ /\ / | |__| | | \ \| . \ ) | | | | |__| | | \/ \/ \/|_| \_\_|\_\_/|_| |_|\/|_| ___ ___ ___ __ |__ \ / _ \ / _ \ | ) | | | | | | | / / / /| | | | | | | / / / /_| |_| | |_| |/ / ||\___/ \___//_/ Symmetric Functions It will take place at the RISC institute near Linz from Thursday, June 14 to Saturday, June 16. Axiom is a Computer Algebra System with a long tradition. It recently became free software, see http://www.axiom-developer.org The workshop aims at a cooperation of Axiom developers with developers of packages written for other Computer Algebra Systems, and mathematicians that would like to use a computer algebra system to perform experiments. One goal of the workshop is to learn about the mathematical theory, the design of packages written for other CAS and to make those functionalities available in Axiom. If you would like to attend the workshop, please send mail to <[EMAIL PROTECTED]>. There will be time for a very limited number of contributed talks. If you would like to give a talk, please send us title and a short abstract as soon as possible. There will be no conference fee, but it is expected that participants pay accommodation and meals themselves. There is a limited number of rooms available in Hagenberg for approximately 28 EUR/night including breakfast. The following talks are planned: François Descouens and Nicolas Thiéry Symmetric functions and Hopf algebras Usage and design in MuPAD-Combinat Bertfried Fauser Calculations in character Hopf algebras using SCHUR and Maple Harald Fripertinger TBA Axel Kohnert Symmetric functions in MAGMA Organisers: Ralf Hemmecke Martin Rubey Email: [EMAIL PROTECTED] ___ Axiom-math mailing list Axiom-math@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-math --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Tests of sage.
On March 7, 2007 12:16 PM William Stein wrote:
> ...
> I distinctly remember fixing the problem.
>
> > For example in Sage on my OpenSuse 10.2 system after I typed an
> > Axiom command such as:
>
> > sage: axiom('1+1')
>
> > the system would hang until I pressed control-C. Thereafter, if
> > I repeated the command, or other Axiom commands, everything would
> > work fine.
>
> I think my fix was just to send an extra line to axiom on startup.
> This should work on all platforms.
> ...
Thanks! Much appreciated.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] RE: Tests of sage.
Francois,
I am sorry that is has taken a bit of time but I promised to let you
know when the problem using Axiom with Sage that you reported back
in January is fixed. I just tried the new release 2.3 of Sage today
and I can confirm that the problem is gone, however I can not say
yet exactly what has changed in the new verison that makes this now
work for me.
http://modular.math.washington.edu/sage
In my testing the problem seemed to have something to do with the
communication between Sage and Axiom that is handled by an interface
called pexpect.
For example in Sage on my OpenSuse 10.2 system after I typed an
Axiom command such as:
sage: axiom('1+1')
the system would hang until I pressed control-C. Thereafter, if I
repeated the command, or other Axiom commands, everything would work
fine.
The affect of this problem in the notebook() interface was more
severe since when the notebook tries to run the first Axiom command
there is no way to interrupt and restart this computation that did
not repeat the same problem.
The problem seemed to occur on some systems but not on others. For
example it failed for me on OpenSuse 10.2 linux but it works on the
axiom-developer.org server and William Stein told me a few weeks ago
that he could not reproduce the problem on his systems. Perhaps there
has been a subtle change in the way pexpect works. I will discuss
this with William.
In any case, you should be able to upgrade your installed version of
Sage to the latest version by the following simple command:
$ sage -upgrade
Sage will download all of the necessary updates and automatically
rebuild the system.
The version of Axiom I used for testing this was also installed using
Sage via the command:
$ sage -i axiom4sage-0.1.spkg
This downloads and builds a version of the Axiom build-improvments
branch dated '2006-10-10'. I hope to release a new package
'axiom4sage-0.2.spkg' based on the current source from the wh-sandbox
branch some time in the near future - sooner if anyone else expresses
some interest in this.
Please let me know if you have any more problems.
Regards,
Bill Page.
On February 1, 2007 10:25 PM Bill Page wrote:
>
> Thank you for testing this.
>
> I have been able to reproduce this problem. The same thing
> happens to me. I am looking into the problem and I will let
> you know a solution soon.
>
> Regards,
> Bill Page.
>
> On January 31, 2007 9:31 AM Francois Maltey wrote:
> >
> > Many thanks for your pretty mail, Bill :
> >
> > > Please see the examples at:
> > >
> > > http://sage-notebook.axiom-developer.org/axiom
> > >
> > > I would be happy to answer any questions you have.
> >
> > So I download sage (a 130 MB file), untar and make the system.
> >
>
> What version of Sage did you download? As far as I can see the
> most recent version of Sage (version 2.0) is "only" about 88 Mb.
>
> http://modular.math.washington.edu/sage/dist/src/index.html
>
> or
>
> http://sage.scipy.org/sage/dist/src/index.html
>
> I just finished downloading, untar and make of Sage-2.0 on a
> OpenSuSE 10.2 linux system.
>
> > As root I add axiom binary in the $PATH,
> > and add also the main sage directory in the $PATH.
> >
> > I can run axiom -nox -nocle in a root-xterm.
> >
>
> On my system I have Axiom built from a recent version of the
> build-improvements branch.
>
> > As root I can run sage everywhere
> > run install_scripts('/usr/local/bin') in sage,
> > and lauch notebook()
> >
> > In x11 I open http://localhost:8000 with firefox.
> > I get the screen of the sage system.
> > I can type commands in bluebox.
> >
> > But I almost never obtain any results.
>
> Make sure to press Shift+Enter to execute the contents of
> the bluebox.
>
> > Neither without system when I test 2*3
> > neither for axiom when I type in two lines %axiom \\ 2+3.
> >
>
> I have very similar problems. But if I only enter Sage
> commands, everything seems to work. If I try Axiom commands
> then it fails. I see an error traceback in the Sage session
> log. These same commands work properly on the Sage server
> which is apparently running the same version of Sage but a
> different version of Axiom.
>
> > Return adds a break-line.
>
> Use Shift+Enter to execute a cell.
>
> > Evaluate rerun the session but result remains green box.
> >
> > What I forget ?
> >
>
> I think you are doing everything correct. There seems to be
> some problem with Sage and/or Axiom. I recall that I had some
> problem with readline when I first tested this and I am quite
> sure that the 'axiom4sage-0.1.spkg
[sage-devel] Summer of Code
Students of Sage might be interested in the Axiom/Sage project supported by an Axiom sister organization (LispNYC) that has been accepted for the Google Summer of Code program. Axiom had a previous successful Summer of Code project that was funded in a similar manner through LispNYC in the first Summer of Code cycle. See: http://lispnyc.org/soc.clp for details. Summer of Code proposals for these or similar projects will be greatfully considered by LispNYC and the Axiom developers. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Summer of Code
On March 19, 2007 2:44 PM Bill Page wrote: > > Students of Sage might be interested in the Axiom/Sage project > supported by an Axiom sister organization (LispNYC) that has > been accepted for the Google Summer of Code program. Axiom had > a previous successful Summer of Code project that was funded > in a similar manner through LispNYC in the first Summer of Code > cycle. > > See: http://lispnyc.org/soc.clp for details. > > Summer of Code proposals for these or similar projects will be > greatfully considered by LispNYC and the Axiom developers. > Please note that the deadline for student applications is March 24th! If you are interested apply online now at: http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-t he-gsoc-web-app-for-student-applicants Don't hesitate if your interests do not exactly match the project proposals. All applications relevant to Lisp and Axiom will be considered. Regards, Bill Page --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Science calls Sage a "supercomputer"
In a recent widely distributed online edition of Science Magazine, SCIENCE News This Week March 23 2007, 315 (5819) Dana Mackenzie writes: MATHEMATICS: Mapping the 248-Fold Way Dana Mackenzie This week, an international team of 18 mathematicians and computer scientists called the Atlas Project announced that a supercomputer called Sage has successfully "mapped" a vast, 248-dimensional entity known as E8. (Read more.) http://www.sciencemag.org/cgi/content/full/315/5819/1647 "On 8 January, Sage, a supercomputer at the University of Washington, computed the last entry in the table for E8." As much as I value getting some long needed press for things related to computer algebra, I am particularly disturbed that a high profile publication like Science Magazine from the American Association for the Advancement of Science should so badly misrepresent the nature of a computer algebra system! :-( Oh please, won't somebody please to Science Magazine the difference between a supercomputer and a computer program? Ok, it is true that the server that Sage runs on at the math department at University of Washington is a nice and fast 16-processor linux system, but the last time I looked that didn't qualify it as a supercomputer... http://www.sagemath.org/sage.html Even here at http://aimath.org/E8/ we can read: "News flash: Congressman Jerry McNerney will deliver a commendation of the Atlas team to Congress on Tuesday, March 27. Watch it on TV!" and "In the end the calculation took about 77 hours on the supercomputer Sage." Would it be *that* embarrassing to admit that almost anyone with a high end "gaming" desktop computer could do this same calculation in about the same amount of time? Perhaps yes, given how much NSF money has gone into supporting super computer projects... For some reason this type of journalism and "science by press release" disturbs me. Am I alone in this reaction? Do we have to promote our work this way? BTW, congratulations to the mathematicians of the Atlas project. In spite of the hype, this is of course a momentus result! Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SymPy
On April 13, 2007 11:02 AM William Stein wrote: > > On 4/13/07, Mike Hansen wrote: > > I definitely agree that SAGE's goals are quite a bit higher > > and more ambitious than those outlined on the SymPy project. > > While looking over the SymPy website, I was just surprised > > because I had never heard of the project and their scope > > seemed to be much wider than I had initially thought (quantum > > field theory calculations, a port of grtensorii, Groebner > > bases calculations, symbolic linear algebra, etc.) While > > there may be a limited (if any) amount we could benefit from > > their current codebase, I thought it'd be good just to be > > aware of any other work done with computer algebra in Python. > > I certainly agree. At a minimum it would be nice to have a > SAGE optional package that install SymPy. Anybody want to > make one? > It turns out that running SymPy in Sage is quite easy after you install the prerequisite pygame package that is already available as an experimental SAGE package sage -i pygame-1.7.1release I have been experimenting a little with it here: http://wiki.axiom-developer.org/SandBoxSymPy It might be interesting to know (and a bit galling - at least it was for me as an Axiom developer) to know that the SymPy got 5 Google Summer of Code funded projects! Axiom partnered with LispNYC for SOC 2007 but we did not get any qualified applications. :-( Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to [EMAIL PROTECTED] 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [Maxima] Computer algebra system? / SAGE and Pipes
On May 12, 2007 11:39 AM David Joyner wrote: > > more "SAGE in the News" > > -- Forwarded message -- > From: Richard Fateman <[EMAIL PROTECTED]> > Date: May 12, 2007 10:20 AM > Subject: Re: [Maxima] Computer algebra system? / SAGE and Pipes > To: [EMAIL PROTECTED] > > > The comment that SAGE's mechanisms are good (or adequate) for > linking various systems is either naïve, or assumes that users > of SAGE use SAGE only for simple things, or the systems SAGE is > linking together are naïve. ( I think the last is false since > it includes Maxima). > ... I think it is obvious that Fateman's comments can be easily answered by the Sage developers who have certainly thought about exactly these details. Fateman's sceptism is, I think quite typical of people who have not looked closely at the Sage design. Surely rather than passing on these messages from list to list, it would be better for each group if the participants in the discussion where subscribed to those lists where the discussion can take place more naturally. :-) Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Fwd: [sage-devel] predefined symbolic variable names
On 7/7/07, William Stein wrote: > ... > So I propose that the only symbolic variables that are predefined > are x (since it's so useful to have this predefined), I (=sqrt(-1)), > and e (=2.7...). > If users want a symbolic variable, they have to use the var command. > ... In my opinion there should be *no* predefined symbols. For me even having only these 3 symbols predefined would lead to some initial confusion. I would very much prefer that it be necessary to ask that these things be defined via a single import or other initialization at the top of each notebook/sage session. Then the first question one asks is "What is this thing at the start of the notebook page? And the simple answer makes everything clear. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: article for CCA/SIGSAM Bull
;m > writing this email in Parallels Virtual Machine on a mac, which > uses the non-GPL commercial version of the Qt library for its GUI. > This option was apparently considered by NAG but rejected because unlike MySQL AB, NAG does not intend to offer any sort of commercial support for Aldor. > > > On Sat, Aug 04, 2007 at 04:29:05PM -0700, William Stein wrote: > > > On 8/4/07, David Joyner <[EMAIL PROTECTED]> wrote: > > > > Based on what I've read on the axiom developers list, > > > > I think because of NAG's (very unfortunate, IMHO) decision, > > > > Axiom (and FriCAS) will now be moving away from Aldor. So far as I know, the primary developer of FriCAS (Waldek) has not made any specific statements about Aldor however I know there are people who use FriCAS who have installed the interface to the binary version of Aldor so that they can use it with FriCAS. Similarly, there is an interface for Aldor that is part of the Axiom project and many people already use Aldor this way. So I do not think it is accurate to say that they are "moving away from Aldor". What is true however is that because of the announcement of the new license for Aldor source code, both projects have a renewed incentive to continue the development of the old Spad compiler. > > > > Therefore, I think it will be a waste of time for SAGE to distribute > > > > Aldor. NAG lead people on (or let people hope) that Aldor would be > > > > open source. I predict Aldor will, thanks to NAG, slowly die. > > > > I don't think this statement is not accurate. To the best of my knowledge NAG did not "lead people on" about Aldor. They (specifically Mike Dewar) was quite clear about the desire for a license with an non-commercial use clause as much as two years ago. But many people have hoped for a more open license what would be compatible with Axiom. > > > > > > Just to add agreement to that, I have no interest in distributing > > > any non-open source code, as defined by the Open Source Initiative. > > > David's probably right about the future of Aldor... > > > > > I think such conclusions are clearly premature. > > > > Emil Volcheck wrote: > > I'm optimistic about the future of Aldor, because making the > > source public ensures that it can't be killed by anyone through > > neglect. > > I agree. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: article for CCA/SIGSAM Bull
David, On 8/4/07, you wrote: > Though you clearly know more about this stuff than I do, I stand by > my statements. I am very skeptical. Seems like getting NAG to issue a > license was like pulling teeth. The only things I know about all this is from the meeting with Stephen Watt at ISSAC and a few previous emails via the axiom-developer list to which Mike Dewar is a subscriber. > They obviously want to "poison" Aldor so someone else, > like Maple, doesn't incorporate it into a product and sell it > (as idiotic as that seems). So they choose the worst license for > everyone concerned. > I definitely do *not* think this is the case. I expect that they would very much like MapleSoft to incorporate Aldor as an optional programming language for Maple. Several people, including Stephen Watt have worked on this possibility and have published several papers about how to marry the strongly-typed Aldor language with the untyped Maple environment. But so far Maple has preferred to re-invent the object-oriented approach by extending the Maple programming language. > When everyone (Axiom, FriCAS, even Watt himself!) is saying they will be > working more on extending and improving SPAD, I call that moving away from > Aldor. If it walks like a duck and quacks like a duck, it's a duck. As far as I know Stephen Watt is not working on anything related to Axiom. I do not think he has any interest in SPAD. I hope I did not inadvertently give you that impression in my previous email. > Axiom was the last chance Aldor had. NAG blew it. Steven Watt and > his students will take features they like in Aldor, add them to his > superSPAD or whatever he will call it, and Aldor will be forgotten. > I think you are wrong. Stephen Watt, his colleages at University of Western Ontarion, and his students are actively using Aldor in their teaching and research. > Also, I remember you pushing for the Aldor/Axiom, saying that Aldor would > be the next generation SPAD for Axiom. That is a statement about the past. Aldor was designed specifically to be the next generation of SPAD for Axiom. It was only when Axiom was made open source that for some reason Aldor was not included. I suspect (but do not know for sure) that the reason Aldor was excluded is because Tim Daly - the person negoiating with NAG for open sourcing Axiom - was not interested in Aldor. Tim has said publicly that he was fundamentally against the decision to implement Aldor that way it was implemented at IBM. Tim wanted to implement the 2nd generation Spad in Lisp, but Stephen Watt chose to implement it in C and provided a stand alone C runtime environment in addition to the abililty to general Lisp code for interfacing with Axiom. > In spite of what Dewar said, "... many people have hoped for a more open > license that would be compatible with Axiom." I believe it was me who said that. As far as I know Mike Dewar has not yet replied although he was included in the Cc of my email. > Indeed, aldor.org even advertised that aldor was going to be > released open source. NAG reads aldor.org and that alone tells me > that "NAG lead people on (or let people hope) that Aldor would be open > source." > Whether NAG knows what open source means is another matter. I think your last conclusion is probably correct. NAG's definition of open source is probably different than that promoted by GNU and the open software foundation. > If I was an Axiom developer, I'd be really pissed. > Personally I am past that stage. That is how I felt last year mostly because it was taking so long and in my opinion at that time Axiom development was seriously floundering. Making Aldor available with a license that was compatible with Axiom would have been a very positive development. But several significant things have happened in the Axiom project since then and development is proceeding in spite of the current disagreements in the Axiom project. So now that Aldor will be freely available for non-commercial use I think this is just one small positive step for Axiom. (Of course it could have been a much bigger step if NAG had actually agreed to a compatible license.) Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE download stats -- how to increase SAGE usage?
As technically hard as it might be, I think having a native Windows version of Sage - even if it includes only a subset of the standard packages - would likely be a big factor in attracting more users. In my experience with Axiom, potential Windows users out number Linux users by a large number (maybe a factor of 100 or more). Windows users are very reluctant in install Linux in a virtual machine or even cygwin just to run Sage. (If they were willing they would probably already be running Linux.) Having even a subset of Sage available as a native Windows application would introduce many more users to Sage and probably motivate some of them to install Linux in order to access the full version. I think the best tool for building a native Windows version of Sage is probably MSYS/MinGW which is really a cross-compiler and gnu tool set that provides a Linux-like environment only during the build. The end product is a native Windows application that does not depend on any Linux emulation layer. Unfortunately some of the standard packages in Sage can not be built in this way and to make matters worse, as far as I know the pexpect module that is required for interface with packages like Maxima has not been successfully ported to Windows. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Reduce package for Sage
William, Some months ago I promised to look into the issue of creating a Reduce package for Sage (as usual: as and when time permits :). While at the ISSAC conference where Sage was conspicuous by it's complete absence! :-(, I had a brief meeting with Winfried Neun [1] from ZIB [2] - one of main distributors of Reduce (Codemist [3] being the other main distributor, mostly of the Windows version). Reduce is not currently available under an open source license [4] but my conversation with Winfried left me with the impression that this *might* be subject to change given sufficient motivation. After discussing ideas for the Sage package, Winfried surprised me by stating that there is a version of PSL (Portable Standard Lisp - on which the ZIB version of Reduce is based) that can be called as a dynamic library API. It seems to me that to be able to interface with Reduce this way would be vastly superior to using the pexpect serial interface that Sage uses with Maxima, Axiom and several other packages). I promised to follow-up on this when I got back home, which is one reason for this email. The other reason for this email is that I would like to get some idea about the number of Sage people who might be interested in a Reduce interface. Regards, Bill Page. Ref: 1 http://www.zib.de/ 1 http://www.zib.de/neun 2 http://www.zib.de/Symbolik/reduce/ 2 http://www.zib.de/Symbolik/reduce/dist/geninfo.html 3 http://www.codemist.co.uk/index.html 4 http://www.reduce-algebra.com/ 4 http://www.reduce-algebra.com/ordering%20information.htm --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE download stats -- how to increase SAGE usage?
On 8/7/07, Alec Mihailovs wrote: > > From: "Bill Page" <[EMAIL PROTECTED]> > > > As technically hard as it might be, I think having a native Windows > > version of Sage - even if it includes only a subset of the standard > > packages - would likely be a big factor in attracting more users. > > Being a Windows user, I can't agree less. ??? In my reading of English this sounds like you strongly disagree. :-( > Also, the notebook running in IE 7 would be much more attractive for > many Windows users (including me) than in Firefox. > I draw the line there! I very much prefer FireFox and strongly encourage all the Windows users I know to switch to FireFox. I know from even simple projects that Javascript compatibility between Explorer and FireFox can be a real pain. But yes compatibility of the notebook with Explorer would be nice. What are the known problems if you try it now? > > > I think the best tool for building a native Windows version of Sage is > > probably MSYS/MinGW which is really a cross-compiler and gnu tool set > > that provides a Linux-like environment only during the build. The end > > product is a native Windows application that does not depend on any > > Linux emulation layer. Unfortunately some of the standard packages in > > Sage can not be built in this way and to make matters worse, as far as > > I know the pexpect module that is required for interface with packages > > like Maxima has not been successfully ported to Windows. > > However, for Python extensions, the compiler should be the same as the > compiler used to build Python - for Windows it is Visual Studio (Express is > OK) 2005. > I am not sure if this is necessary but apparently Python can be built under MSYS/MinGW (I haven't tried this). See: http://jove.prohosting.com/iwave/ipython/pyMinGW.html Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE download stats -- how to increase SAGE usage?
On 8/8/07, Joel B. Mohler wrote: > > I've never used colinux, but why is vmware a preferable choice than colinux? > I would think that it would be much easier to get something that felt like a > native windows application with colinux. I think both vmware and colinux do very clumsy things to the Windows network configuration. These have caused me trouble on several occasions. On Windows I find Microsoft's Virtual PC to be simpler and superior: http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx I use it to run both SuSE 10 and Solaris 10.2 on my Windows dual-processor desktop very happily. > Anyhow, an idea that builds on this is to build some X application instead of > the notebook (ok, I'll admit I'm not a fan of the web notebook) and > distribute a free x-server for windows with SAGE for windows. I believe that > there might be an x-server out there which could make this feel like a very > native solution. I run Xming and Putty: http://sourceforge.net/project/showfiles.php?group_id=156984&package_id=222154 to provide x-server support under Windows. I use it to run Linux x-windows applications like the Axiom HyperDoc browser and graphics on my Windows desktop. Xmaxima should be ok too. I rarely touch the virtual machine itself. Xming creates application windows that look and feel a lot like Windows windows (depending on the actual UI). For example you can run FireFox as a x-windows application on the same virtual machine that is running Sage. Except for some font differences it looks and works very nearly the same as native Windows FireFox. This seems faster for running the notebook than running native Windows FireFox and accessing the notebook "remotely". > Of course, there's still the file transfer problem ... that > is, the file system of colinux is distinct from the windows file system. > The usual solution is to mount a Windows shared directory via Samba smbfs. The big problem with all this is it assumes a fair amount of sophistication for the average Windows user and some knowledge of Linux fundamentals. I do not know how or if it is possible to create a single installer file that would install all of this in one step on a virgin Windows system (with Administrator rights, of course). Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sage -clisp fails in sage-2.7.3
William, et al.; I downloaded sage-2.7.3-x86_64-Linux.tar.gz, untarred it and started sage successfully. But when I ask sage to start a clisp session, it fails with the following message: [EMAIL PROTECTED]:~/sage-2.7.3-x86_64-Linux$ ./sage -clisp clisp: /home/was/sage-2.7.2.rc1/local/lib/clisp/base/lisp.run: No such file or directory I did 'sage -upgrade' and tried again, but the error remains. Any ideas how I can make this work? (It worked in sage-2.7.1) Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE in TeXmacs
On 8/10/07, Mike Hansen wrote: >... > William Stein wrote: > > Since it will be a while before this gets included into TeXmacs by > > default, it would be good to make a webpage with the plugin and > > instructions. Any suggestion for where it could be linked to from > > sagemath.org? > > I could either make one up or wait until the Wiki is back up. > ... > I've also attached a screenshot to show plotting. > +1 This is excellent! Thank you very much for doing this. BTW, I think your direct Python interface to Sage is marvelous and really demonstrates the value of basing a computer algebra system on a mainstream language like Python. Thanks again. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: article for CCA/SIGSAM Bull
I apologize for cross posting and for the extended Cc list but I wish to correct an error I made in a previous comment in this thread. On 8/5/07, I wrote: > > On 8/4/07 David Joyner wrote: > ... > > Also, I remember you pushing for the Aldor/Axiom, saying that Aldor would > > be the next generation SPAD for Axiom. > > That is a statement about the past. Aldor was designed specifically to > be the next generation of SPAD for Axiom. It was only when Axiom was > made open source that for some reason Aldor was not included. > > I suspect (but do not know for sure) that the reason Aldor was excluded > is because Tim Daly - the person negoiating with NAG for open sourcing > Axiom - was not interested in Aldor. In an email off-list referring to my suspicion stated in the above sentence, Tim Daly told me that: "This statement is clearly false." and asked that I stop posting statements that imply that he is somehow at fault without checking the facts with him first. I think that is a reasonable request and I regret that I made such a rash comment without thinking about it first. After reviewing all of the comments I could find in the axiom-devel email list archives, I could not find any evidence to support my suspicion. > Tim has said publicly that he was > fundamentally against the decision to implement Aldor that way it was > implemented at IBM. Tim wanted to implement the 2nd generation Spad in > Lisp, but Stephen Watt chose to implement it in C and provided a stand > alone C runtime environment in addition to the abililty to general > Lisp code for interfacing with Axiom. This statement, while presumably correct (but again I admit that I did not actually check with Tim that this accurately reflects his current view), is not proper grounds for my previously stated suspicion. So the reasons why Aldor was not included in the open source release of Axiom must be of a different nature. - One factor may have just been a matter of timing. The Aldor component of the commercial version of Axiom was actually publicly released *before* the rest of Axiom and under a different (not open source) license when aldor.org was created. It is only now that aldor.org and NAG have agreed on a more open license (APL2). However because of the non-commerical use clause the new license is still not completely compatible with Axiom's license so it is currently not possible to combine them both into a single GPL compatible release. But as I understand it (which might be incorrect), it would be possible to release the Axiom+Aldor combination under APL2 since Axiom's modified BSD license is technically compatible with both GPL and APL2. However I am not sure whether there is anyone currently interested and willing to do this. > ... Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [Axiom-developer] Re: Wiki
On 8/12/07, William Stein wrote: > On 8/12/07, Bill Page <[EMAIL PROTECTED]> wrote: > > | The problem I have with (2) is that I might be trading one form of > > | tyranny for another ... Certainly the Sage project's apparent ultimate > > | goal of "assimilation" of other computer algebra projects (which > > | William Stein might well deny) is a little worrisome if my goal was > > | primarily the longevity of the original Axiom source code. But the > > Of course I have to write to deny that goal :-). By far, the primary > goal of SAGE is to create a viable high-quality practical alternative to > Magma, Maple, Mathematica, and Matlab as soon as possible using > existing open source components when practical. > ... > This was the motivation for David Joyner and I offer to provide > support of various forms to a possible Axiom fork. I actually > think the direction Waldek is pushing FriCAS so far is *excellent* > from our point of view -- he is making it much easier to distribute > and build FriCAS, which will make it very suitable for SAGE users. > At the same time, it's a clear separate project. That's the optimal > situation from my point of view. ... Thank you for writing. Of course I did not seriously intend to cast you or the Sage project in a negative light. I was merely trying (perhaps too forcefully) to express what I see as a possible external reaction to the close relationship between Sage and other projects. I am glad that you have stated the Sage goals and motivations very clearly so that it is possible to base important decisions about the future of projects like Axiom in a more rational manner. I am personally very sympathetic to these goals exactly as you have statement them. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] problem building Sage from the 'sage-2.7.3.tar' sources on sage.math
William, I was trying to build Sage from the 'sage-2.7.3.tar' sources this morning but I ran into a problem. Here is a excerpt from the build log: ... installing clisplow_nl.gmo as ../locale/nl/LC_MESSAGES/clisplow.mo installing ru.gmo as ../locale/ru/LC_MESSAGES/clisp.mo installing clisplow_ru.gmo as ../locale/ru/LC_MESSAGES/clisplow.mo make[3]: Leaving directory `/home/page/sage-2.7.3/spkg/build/clisp-2.41.p4/src/s rc/po' rm -rf data mkdir data cd data && ln -s ../../utils/unicode/UnicodeDataFull.txt . cd data && ln -s ../../doc/Symbol-Table.text . gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmiss ing-declarations -Wno-sign-compare -O -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_ SINGLEMAP -DNO_TRIVIALMAP -DUNICODE -DNO_SIGSEGV -I. -x none spvw.o spvwtabf.o s pvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io .o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o deb ug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built .o modules.o libcharset.a /home/page/sage-2.7.3/local/lib/libreadline.so -Wl,-rp ath -Wl,/home/page/sage-2.7.3/local/lib -lncurses -ldl-o lisp.run ./lisp.run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW - x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" *** - The value of *ERROR-OUTPUT* was not an appropriate stream: #. It has been changed to #. *** - UNIX error 9 (EBADF): Bad file number *** - UNIX error 9 (EBADF): Bad file number ... --- Build ultimate fails with the message "Lisp stack overflow" in an infinite loop. Is this a known problem? How should I proceed to build Sage from source on sage.math? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem building Sage from the 'sage-2.7.3.tar' sources on sage.math
On 8/12/07, William Stein wrote: > > On 8/12/07, Bill Page wrote: > > I was trying to build Sage from the 'sage-2.7.3.tar' sources this > > morning but I ran into a problem. Here is a excerpt from the build > > log: > ... > Were you building like this: > > nohup make > output& > > logout, etc.? Yes. My sat uplink is sometimes unstable during thunderstorms and it can cause the session to get dropped. Restarting in the middle of a build sometimes fails. For that reason I often use nohup. > On 64-bit Linux systems clisp fails to build unless > you actually leave the console window open. For some reason, redirecting > the output to a file breaks the build. Could you delete your massive > log file, then restart the build by just typing "make" and leaving > the console window open? Yes, I can do this. > Alternatively, help me fix this problem :-) > This sounds like a clisp build problem to me. Perhaps it should be reported to the clisp developers? > The error message above says: > > > *** - The value of *ERROR-OUTPUT* was not an appropriate stream: > > #. It > > has been changed to #. > > Maybe this means that one has to do something else, e.g., >nohup make > output 2>error & > That's a good idea if it works. I'll give it a try. > ??? Any ideas are welcome. > I will let you know. Thanks. Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem building Sage from the 'sage-2.7.3.tar' sources on sage.math
On 8/12/07, mabshoff wrote: > > On Aug 12, 7:41 pm, "William Stein" wrote: > > On 8/12/07, Bill Page wrote: > > > > > > > Is this a known problem? How should I proceed to build Sage from > > > source on sage.math? > > > > Were you building like this: > > > > nohup make > output& > > > > > Instead of nohup you might want to try GNU screen which is a utlilty > to detach and reattach from console sessions. Very nice if you want to > run some big console job and log out and then reattach when you log in > again or for the case your connection gets dropped unexpectedly. > Thank you very much for the suggestion! (-: new tricks for old dogs :-) Unfortunately William's original suggestion of also redirecting stderr: > nohup make > output 2>error & did not work (same error message, same place). But using 'screen' does work... I think I'm going to like 'screen'. :-) BTW, I found I nice short tutorial on using 'screen' here: http://www.kuro5hin.org/story/2004/3/9/16838/14935 Thanks. Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem building Sage from the 'sage-2.7.3.tar' sources on sage.math
On 8/12/07, Bill Page <[EMAIL PROTECTED]> wrote: > ... > Unfortunately William's original suggestion of also redirecting stderr: > > > nohup make > output 2>error & > > did not work (same error message, same place). > ... I expect the reason for this is that the re-direction of stderr should really be applied to the make command that is embedded in the script that built clisp. We can try that later. Regards, Bill Page. --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
