diff --git a/book/2004-09.txt b/book/2004-09.txt new file mode 100644 index 0000000..5f1c6df --- /dev/null +++ b/book/2004-09.txt @@ -0,0 +1,8120 @@ +\start +Date: Wed, 1 Sep 2004 11:35:29 -0400 +From: Tim Daly +To: martin.rubey@univie.ac.at +Subject: [Axiom-developer] how to simplify exponents + + a 2a +2^a*2^(2*a) -> 2 2 + + 3a +simplify % -> 2 + +\start +Date: Fri, 3 Sep 2004 11:23:44 +0000 +From: Martin Rubey +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: how to simplify exponents + +I wrote: + > > How can I make axiom to do 2^a*2^(2*a) -> 2^(3*a) ? + > + > Ok, simplifyExp does that. But how about + > + > 2^a*4^a ? + +Furthermore, I cannot convince Axiom to do + +2^(5*a)/2^(4*a) -> 2^a + +I'm rather disappointed, in fact, although it might as well be that I'm missing +something. + +I'd be very grateful, if somebody could tell my how to make Axiom do the +following correctly. PLEASE start up Axiom and plug in the following: + + +--- the first 5 statements are just for setup, don't worry to much about them + +x n == 2^(a*n); +k := 2; +p n == A-(k+3)*a1+a1*n; +q:=interpolate('n,[i for i in 1..k],[x(i)*p(i)^(-i) for i in 1..k])$PINTERP('n, EXPR INT)::EXPR INT; +eqs:=[(p(i)^i*eval(numerator(q),n=i)-x(i)*eval(denominator(q),n=i))::MPOLY([a1,A],EXPR INT) for i in k+1..k+3]; + +--- so far, everything works out just great. eqs is a List of three polynomials +--- in a1 and A with coefficients being expressions. + +--- now I want to see, whether they have a common root. In fact, I know they +--- have: A=2^(a*n) and a1=0. + +r1:=map(simplifyExp, resultant(eqs.1, eqs.3, a1)::UP(A, EXPR INT)); + +--- now we have eliminated a1. Since we know that A=2^(a*n) and a1=0 is a +--- common root of all three polynomials, evaluating r1 at A=2^(a*n) should +--- give 0. This does not work out as smooth as I'd hoped, but with a little +--- tweaking we get at least an answer that we can see to be zero: + +simplifyExp(eval(r1 ,A=2^a)) + +--- similarly: + +r2:=map(simplifyExp,resultant(eqs.2, eqs.3, a1)::UP(A, EXPR INT)); + +--- this even works out: + +simplifyExp(eval(r2, A=2^a)) + +--- However, this is simply the wrong answer, it should contain A-2^a as a +--- factor: + +gcd(r1, r2) + +---------------------------------------------------------------------------- + +maybe the reason for that is, that Axiom cannot properly do + +divide(r1,A-2^a) + +HELP! + +\start +Date: Fri, 03 Sep 2004 13:49:45 +0100 +From: Nic Doye +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined + +Must be doing something stupid here. + +(Desktop/dev is a symlink to dev in /home/nic). + +I've tried with both yesterday's CVS and the 20040418 sources. + +nic +--- + +[njd@e082 axiom]$ ./configure + +You must set your AXIOM and PATH variables. Type: + +export AXIOM=/home/nic/dev/axiom/mnt/linux +export PATH=$AXIOM/bin:$PATH + +To build the rest of the system type: + +make + +configure finished. +[njd@e082 axiom]$ make +0 SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom SYS=axiom SPD=/home/nic/Desktop/dev/axiom LSP=/home/nic/Desktop/dev/axiom/lsp GCLDIR=/home/nic/Desktop/dev/axiom/lsp/gcl-2.6.5 SRC=/home/nic/Desktop/dev/axiom/src INT=/home/nic/Desktop/dev/axiom/int OBJ=/home/nic/Desktop/dev/axiom/obj MNT=/home/nic/Desktop/dev/axiom/mnt ZIPS=/home/nic/Desktop/dev/axiom/zips TMP=/home/nic/Desktop/dev/axiom/obj/tmp SPADBIN=/home/nic/Desktop/dev/axiom/mnt/axiom/bin INC=/home/nic/Desktop/dev/axiom/src/include CCLBASE=/home/nic/Desktop/dev/axiom/obj/axiom/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/nic/Desktop/dev/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/nic/Desktop/dev/axiom/mnt/axiom/bin/lib/notangle +10 copying /home/nic/Desktop/dev/axiom/src/scripts to /home/nic/Desktop/dev/axiom/mnt/axiom/bin +1 making a axiom system, PART=cprogs SUBPART=everything +2 Environment SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom SYS=axiom SPD=/home/nic/Desktop/dev/axiom LSP=/home/nic/Desktop/dev/axiom/lsp GCLDIR=/home/nic/Desktop/dev/axiom/lsp/gcl-2.6.5 SRC=/home/nic/Desktop/dev/axiom/src INT=/home/nic/Desktop/dev/axiom/int OBJ=/home/nic/Desktop/dev/axiom/obj MNT=/home/nic/Desktop/dev/axiom/mnt ZIPS=/home/nic/Desktop/dev/axiom/zips TMP=/home/nic/Desktop/dev/axiom/obj/tmp SPADBIN=/home/nic/Desktop/dev/axiom/mnt/axiom/bin INC=/home/nic/Desktop/dev/axiom/src/include CCLBASE=/home/nic/Desktop/dev/axiom/obj/axiom/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/nic/Desktop/dev/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/nic/Desktop/dev/axiom/mnt/axiom/bin/lib/notangle +The root module <> was not defined. +make: *** [all] Error 3 + +\start +Date: Sat, 4 Sep 2004 02:39:57 -0400 +From: "Bill Page" +To: "'Martin Rubey'" +Subject: RE: [Axiom-developer] Re: how to simplify exponents + +Martin, + +I have found some ways to deal with the problems you mentioned +below. See + + http://page.axiom-developer.org/zope/mathaction/HowTo + +I haven't had a chance to look closely at the more detailed +problems mentioned in the 2nd half of your message but I +have set it up here + + http://page.axiom-developer.org/zope/mathaction/AxiomProblem + +on the MathAction wiki just as you presented in your email. +I hope to take a closer look at it in the next few days. + +Cheers, +Bill Page. + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Martin Rubey +> Sent: Friday, September 03, 2004 7:24 AM +> To: axiom-developer@nongnu.org +> Subject: [Axiom-developer] Re: how to simplify exponents +> +> +> I wrote: +> > > How can I make axiom to do 2^a*2^(2*a) -> 2^(3*a) ? +> > +> > Ok, simplifyExp does that. But how about +> > +> > 2^a*4^a ? +> +> Furthermore, I cannot convince Axiom to do +> +> 2^(5*a)/2^(4*a) -> 2^a +> +> I'm rather disappointed, in fact, although it might as well +> be that I'm missing something. +> +> ... + +\start +Date: Sat, 04 Sep 2004 12:23:24 +0200 +From: David MENTRE +To: Nic Doye +Subject: Re: [Axiom-developer] Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined + +Hello Nic, + +Nic Doye writes: + +> export AXIOM=/home/nic/dev/axiom/mnt/linux +> export PATH=$AXIOM/bin:$PATH + +Have you put those variables in your .bashrc or entered them in the +shell before doing make? + +> [njd@e082 axiom]$ make +> 0 SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +> SYS=axiom + ^^^^ + +I have on my own build: + +SPAD=/home/david/pub/axiom-libre/i386-axiom/axiom/mnt/linux +SYS=linux + +Be aware that the ./configure script of axiom is just a dummy script and +that you should set AXIOM and PATH variables manually. + +I'm using following axiom_init shell alias that I call in my axiom +source directory: + + alias axiom_init='export AXIOM=`pwd`/mnt/linux;PATH=`pwd`/mnt/linux/bin:$PATH' + + +\start +Date: Mon, 6 Sep 2004 13:51:57 -0400 +From: root +To: axiom-developer@nongnu.org, axiom-math@nongnu.org +Subject: [Axiom-developer] A3L 2005 in Honor of Volker Weispfenning] + +FYI... + +Date: Mon, 6 Sep 2004 16:45:51 +0200 +From: "Dr. Andreas Dolzmann" +Subject: A3L 2005 in Honor of Volker Weispfenning + +Dear Friends and Collegues, + +we would like to point you at a conference to be held in Passau, +Germany, in April 2005: + + Algorithmic Algebra and Logic 2005 + Conference in Honor of the 60th Birthday of Volker Weispfenning + +Please, find all relevant information at http://www.a3l.org/ + +Andreas Dolzmann +Andreas Seidl +Thomas Sturm + +\start +Date: Tue, 07 Sep 2004 09:32:51 +0100 +From: Nic Doye +To: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined + +On Fri, 2004-09-03 at 13:49 +0100, Nic Doye wrote: +> Must be doing something stupid here. +> +> (Desktop/dev is a symlink to dev in /home/nic). +> +> I've tried with both yesterday's CVS and the 20040418 sources. + +Hmm. Worked fine at home. PBKAC. Probably setting AXIOM to /usr/local/ +axiom didn't help. + +\start +Date: Tue, 07 Sep 2004 20:32:53 +0200 +From: David MENTRE +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Axiom web site (was: Re: [Axiom-mail] Symbolic calculation with symbols) + +Hello Bill, + +"Bill Page" writes: + +> Perhaps the following pages on MathAction will be of some use +> to you +> +> http://page.axiom-developer.org/zope/mathaction/UseProductAndSum +> http://page.axiom-developer.org/zope/mathaction/CreateIndexedVariables + +As you are doing a very good job at maintaining an active web site, what +do you think of making your web site the reference web site for the +savannah Home Page link? + +If yes, what link should we put? http://page.axiom-developer.org/ ? + +\start +Date: Tue, 7 Sep 2004 14:49:48 -0400 +From: "Page, Bill" +To: 'David MENTRE' +Subject: RE: [Axiom-developer] Axiom web site + +David, + +On Tuesday, September 07, 2004 2:33 PM you wrote: +> ... +> As you are doing a very good job at maintaining an active web +> site, + +Thanks, I think... but I keep hoping that it becomes a shared +activity the way the designers of these through-the-web content +management systems intended it to be. :) Maybe that is beginning +to happen, but it is too soon to tell. + +> what do you think of making your web site the reference web site +> for the savannah Home Page link? + +First, the web site is really Tim Daly's web site. In fact so far +he is funding the hosting of this site entirely out of his own +pocket. This is a situation that I think should be resolved in a +more equitable and "official" manner - perhaps through donations? + +Second, I am not sure what being a "reference web site" entails. + +> +> If yes, what link should we put? http://page.axiom-developer.org/ ? +> + +A few weeks ago I did add links to this site from the following +page: + + http://www.nongnu.org/axiom/community.html + +by updating the webcvs at Savannah. + +\start +Date: Tue, 07 Sep 2004 21:04:04 +0200 +From: David MENTRE +To: "Bill Page (E-mail)" +Subject: Re: [Axiom-developer] Axiom web site +Cc: 'David MENTRE' + +"Page, Bill" writes: + +> Thanks, I think... but I keep hoping that it becomes a shared +> activity the way the designers of these through-the-web content +> management systems intended it to be. :) Maybe that is beginning +> to happen, but it is too soon to tell. + +You probably noticed that I wasn't very active on Axiom recently and +that won't change in following months. But I do remember that at one +point in time, I'll have to contribute more concrete things than just a +few email comments. ;) + +> First, the web site is really Tim Daly's web site. In fact so far +> he is funding the hosting of this site entirely out of his own +> pocket. This is a situation that I think should be resolved in a +> more equitable and "official" manner - perhaps through donations? + +Perhaps Tim should have made more publicity on it. I wasn't aware of the +effort. Tim is probably more benevolent than dictator. :) And probably +adding a donation web page would be useful? + +> Second, I am not sure what being a "reference web site" entails. + +The first URL you should give is somebody is interested in Axiom. + +> A few weeks ago I did add links to this site from the following +> page: +> +> http://www.nongnu.org/axiom/community.html +> +> by updating the webcvs at Savannah. + +Ok, very good idea. + +\start +Date: Tue, 7 Sep 2004 15:16:11 -0400 +From: "Page, Bill" +To: 'David MENTRE' +Subject: RE: [Axiom-developer] Axiom web site + +David, + +> > First, the web site is really Tim Daly's web site. In fact so far +> > he is funding the hosting of this site entirely out of his own +> > pocket. This is a situation that I think should be resolved in a +> > more equitable and "official" manner - perhaps through donations? +> +> Perhaps Tim should have made more publicity on it. I wasn't aware +> of the effort. Tim is probably more benevolent than dictator. :) + +{I am trying hard to think of an "American joke" to add here that +wouldn't offend anyone, but I've failed ... ;} But I think you are +right! + +> And probably adding a donation web page would be useful? + +I have mentioned this a couple of times to Tim, but we have +not yet reached any conclusion. Do you know what would be +involved in setting up an "official" donation web page? (I am +programmed to expect some bureaucracy - even on the web...) + +> +> > Second, I am not sure what being a "reference web site" entails. +> +> The first URL you should give is somebody is interested in Axiom. +> + +Do you mean just the "homepage" link at + + http://savannah.nongnu.org/projects/axiom + +or somewhere else? + +\start +Date: Tue, 07 Sep 2004 21:32:23 +0200 +From: David MENTRE +To: "Bill Page (E-mail)" +Subject: Re: [Axiom-developer] Axiom web site +Cc: 'David MENTRE' + +Bill, + +"Page, Bill" writes: + +> not yet reached any conclusion. Do you know what would be +> involved in setting up an "official" donation web page? (I am +> programmed to expect some bureaucracy - even on the web...) + +Sorry no. + +Maybe as a first start: "send a check to Tim at address....". BTW, is it +difficult for american people to receive checks in euros? + +> Do you mean just the "homepage" link at +> +> http://savannah.nongnu.org/projects/axiom + +Yep. + +\start +Date: Fri, 10 Sep 2004 15:30:53 -0400 +From: root +To: axiom-math@nongnu.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] solving polynomial equations + +General Solution for Polynomial Equations + +http://arxiv.org/pdf/math.CA/0408264 + +the report is that a Dutch student found a formula to determine the +roots of any polynomial equation. Although an exact solution has been +proven impossible for higher orders, this is not the case for numerical +solutions. + +\start +Date: Fri, 10 Sep 2004 23:19:23 -0400 +From: "Bill Page" +To: "'Martin Rubey'" +Subject: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Martin, + +I think the new content of + + http://page.axiom-developer.org/zope/MathAction + +is "lookin' good". Thanks for all your work. + +On Friday, September 10, 2004 1:47 PM you wrote: + +> ... +> One new request: please remove all subpages of SandBox. +> It seems that I do not have permission to do so. +> + +I looked at some of these pages and I think some of these are +still needed. Any page that contains + + RemoteWikiURL: + +is involved in the weird way in which links outside the local +wiki are handled by ZWiki. If I recall correctly, some of these +(lib, cat, dom, etc.) I set up specifically to deal with the links +automatically generated when Axiom library code is compiled. +I will have to take another look at this and see which of these +are still necessary. + +For now, I left the "delete page" permission dependent on first +being logged in at the Zope level of the system - something that +only I can do at the moment. Although my intention was to make +MathAction as open as possible, I thought that allowing simple +page deletions would be too much ... But depending just how +active you want to become (and how much responsibility you want +to take :), I would certainly be willing to give you these same +access rights. But let's take it slowly conservatively for now +until more than one of us knows where everything fits. + +Continuing to exchange emails such as this is a good way for me +to write some of this down and I will do my best to move these +sort of design and documentation issues on to MathAction itself. +Which brings up another issue that concerns me a little - the +use of email and the email lists versus the "subscribe" option +on MathAction and Plone. Greater integration is possible but is +it really desirable? + +Ok, back the issues at hand... + +> I think we should now ask for permission to let +> +> http://page.axiom-developer.org/zope/mathaction/FrontPage +> +> replace +> +> http://www.nongnu.org/axiom/ +> + +Do you mean the "homepage" link on Savannah? Since I have admin +rights for Axiom there, perhaps I can make this change? But +I don't know much (yet) about configuring things on Savannah... +Looking at several different projects on Savannah though, I see +that some of these do not use the http://www.nongnu.org/... link +for there homepages, so I guess what you suggest is possible. + +> Most of the content is already in MathAction, I think that only +> obsolete things are missing, like the tutorial, which can be +> accessed only every second day, if at all. + +I don't understand what you mean. Which tutorial? What problems +do you have accessing it? + +> Also, I did not move the screenshots. I think that the only one +> which is still interesting is the one with TeXmacs, which would +> fit well into a section "Axiom IDE's". I'm using (Gnu) Emacs... +> + +I like the idea of including some helpful information for stand +alone "Axiom Integrated Development Environments" like TeXmacs +users and Gnu Emacs, and I suppose also just the old native +interface. + +Tim and I (see 'doyen' on MathAction) have also been talking +about the possibility of setting up a single-user MathAction- +like environment for Axiom. The idea would be to allow an easy +transition from a private stand alone environment to and online +collaborative one like MathAction. For example, moving from TeXmacs +to MathAction could be quite traumatic for a user. In principle +making MathAction into a stripped down stand alone single user +environment is quite easy to do, but I just haven't had enough +time yet to do any serious work on this. + +> I think it should really *replace* the old homepage. I think we +> should concentrate on *one* page, and I think that the MathAction +> wiki is the perfect tool for it. + +The pages on http://www.nongnu.org/axiom/ were originally +developed by David Mentre (and/or a colleague of his). I think they +established a "nice look" for Axiom - one that I wasn't really +able to reproduce in the wiki environment. (It is possible to do +more under Plone, but I didn't spend much time at that either.) +The source for these pages is managed by CVS on Savannah as part +of the standard Savannah package. David (more or less) suggested +a few days ago that we do the same thing that you are suggesting +now - consolidate what we have now into a single "reference site" +for Axiom. But I would be happy if he first had a chance to review +the contents of your new pages to make sure that nothing of the +original intent gets lost before we complete this. + +-------- + +I am also a little concerned about how we can (or if we should) +separate the purpose of MathAction itself, as a particular type +of interface to Axiom and Reduce and possibly others in the +future, versus it's role as the "home for Axiom". Do we really +want this "mix" of systems to be so prominent? Are there really +two *separate* goals here: 1) support Axiom, 2) promote the +"Rosetta" ideal of many different systems co-existing and growing +and working together? + +The connection with Reduce through Tony Hearn is still very +tentative, although he does have a link to the Plone/ReduceWiki +page on the Reduce web site. + + http://reduce-algebra.com/projects.htm + +I setup the http://page.axiom-developer.org/zope/Plone/reducewiki +page after a few brief emails with Tony. He wanted to put a +link to the work that I was doing with Reduce on his web site, +so I setup that page on Plone since it was more permanent that +anything I was doing on MathAction itself. Originally it only +pointed to the stuff on test.axiom-developer.org. But notice that +I changed it a couple of weeks ago when I moved the support for +Reduce to MathAction. Currently it contains links back to MathAction +and also to the test.axiom-developer.org site (for GNUplot). + +The support for the GNUplot/Reduce interface is still a little +incomplete because it requires the user to invent a file name +and choose some device options that really should be fixed and +transparent in the ReduceWiki environment. Since this is still +under development, I didn't move the GNUplot stuff to MathAction +yet. + +Anyway, perhaps making the distinction between Axiom support +and the broader Rosetta goals and support for Reduce, etc. is +just a matter of the right web site design for MathAction and/or +Plone? But MathAction is a wiki and kind of "fluid" by nature... + +What do you think? + +I am thinking (out loud) that maybe there is still a role for +http://www.nongnu.org/axiom/ ?? + +\start +Date: Fri, 10 Sep 2004 23:22:53 -0400 +From: "Bill Page" +To: "'Martin Rubey'" +Subject: RE: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Sorry. Corrected url: + +> +> I think the new content of +> +> http://page.axiom-developer.org/zope/mathaction +> +> is "lookin' good". Thanks for all your work. +> +> ... + +\start +Date: Sat, 11 Sep 2004 00:10:24 -0400 +From: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] Re: mathaction +Cc: dmentre@linux-france.org + +Bill, + +>For now, I left the "delete page" permission dependent on first +>being logged in at the Zope level of the system - something that +>only I can do at the moment. Although my intention was to make +>MathAction as open as possible, I thought that allowing simple +>page deletions would be too much ... But depending just how +>active you want to become (and how much responsibility you want +>to take :), I would certainly be willing to give you these same +>access rights. But let's take it slowly conservatively for now +>until more than one of us knows where everything fits. + +It would be "oh-so-convenient" if the pages were backed into a CVS. +Of course, I realize that involves yet another level of work but I've +been meaning to express the idea. I've been watching your posts but +I'm hip-deep in things-to-do as school started this past week and the +world has returned from vacation. + +\start +Date: Sat, 11 Sep 2004 12:23:32 +0000 +From: Martin Rubey +To: "Bill Page" +Subject: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Bill Page writes: + > Martin, + > + > I think the new content of + > + > http://page.axiom-developer.org/zope/MathAction + > + > is "lookin' good". Thanks for all your work. + +I'm flattered :-) + + + > On Friday, September 10, 2004 1:47 PM you wrote: + > + > > ... + > > One new request: please remove all subpages of SandBox. + > > It seems that I do not have permission to do so. + +To make it short: it's OK, leave permissions that way. The only reason to +delete a page is that the navigator doesn't look too good with all the old +links around. I simply removed the content of the "disturbing" pages. I believe +that I moved all the "good" content to the new pages, if something is lost, we +can dig it up from the diffs anyway. + + > Continuing to exchange emails such as this is a good way for me + > to write some of this down and I will do my best to move these + > sort of design and documentation issues on to MathAction itself. + > Which brings up another issue that concerns me a little - the + > use of email and the email lists versus the "subscribe" option + > on MathAction and Plone. Greater integration is possible but is + > it really desirable? + +I like it the way it is. It might happen anyway that parts of the discussions +on axiom-developer, axiom-mail and axiom-math move to mathaction. I wouldn't +force that. First priority should be the integration of pamphlets, I believe. + + > Ok, back the issues at hand... + > + > > I think we should now ask for permission to let + > > + > > http://page.axiom-developer.org/zope/mathaction/FrontPage + > > + > > replace + > > + > > http://www.nongnu.org/axiom/ + > > + > + > Do you mean the "homepage" link on Savannah? Since I have admin + > rights for Axiom there, perhaps I can make this change? + +Yes. + + > > Most of the content is already in MathAction, I think that only + > > obsolete things are missing, like the tutorial, which can be + > > accessed only every second day, if at all. + > + > I don't understand what you mean. Which tutorial? What problems + > do you have accessing it? + +The tutorial of Martin N. Dunstan. I had a bad link, I'll add it just below the +book. + + > > Also, I did not move the screenshots. I think that the only one + > > which is still interesting is the one with TeXmacs, which would + > > fit well into a section "Axiom IDE's". I'm using (Gnu) Emacs... + > > + > I like the idea of including some helpful information for stand + > alone "Axiom Integrated Development Environments" like TeXmacs + > users and Gnu Emacs, and I suppose also just the old native + > interface. + +Well, maybe somebody reading this will volunteer... It's priority level "2" for +me. + + > Tim and I (see 'doyen' on MathAction) have also been talking + > about the possibility of setting up a single-user MathAction- + > like environment for Axiom. The idea would be to allow an easy + > transition from a private stand alone environment to and online + > collaborative one like MathAction. For example, moving from TeXmacs + > to MathAction could be quite traumatic for a user. In principle + > making MathAction into a stripped down stand alone single user + > environment is quite easy to do, but I just haven't had enough + > time yet to do any serious work on this. + +Low priority for me. + + > > I think it should really *replace* the old homepage. I think we + > > should concentrate on *one* page, and I think that the MathAction + > > wiki is the perfect tool for it. + > + > The pages on http://www.nongnu.org/axiom/ were originally + > developed by David Mentre (and/or a colleague of his). I think they + > established a "nice look" for Axiom - one that I wasn't really + > able to reproduce in the wiki environment. + +This is very true, they are *very* beautiful! In fact, I tried to imitate a +little bit, but I failed. However, I have such a strong affection to the +underlying system of mathaction, that I propose to make this move. Furthermore, +I hope that beauty will evolve, given some time. In fact, I think that the new +FrontPage is still too crowded, but I didn't want to spend more time on it +right now. http://www.nongnu.org/axiom/ is very concise (in the sense of +"uebersichtlich"), I hope FrontPage will become more like this when the layout +of the wiki becomes clearer. + + > David (more or less) suggested + > a few days ago that we do the same thing that you are suggesting + > now - consolidate what we have now into a single "reference site" + > for Axiom. But I would be happy if he first had a chance to review + > the contents of your new pages to make sure that nothing of the + > original intent gets lost before we complete this. + +Yes. No need to hurry. I think a great point to switch would be when the +pamphlets are integrated. + + > I am also a little concerned about how we can (or if we should) + > separate the purpose of MathAction itself, as a particular type + > of interface to Axiom and Reduce and possibly others in the + > future, versus it's role as the "home for Axiom". Do we really + > want this "mix" of systems to be so prominent? + +I thought about this too. No conclusion yet, sorry. + + > Are there really + > two *separate* goals here: 1) support Axiom, 2) promote the + > "Rosetta" ideal of many different systems co-existing and growing + > and working together? + +We might be very welcome in mupad-combinat circles. + + + > ... (big part skipped) ... + > + > Anyway, perhaps making the distinction between Axiom support + > and the broader Rosetta goals and support for Reduce, etc. is + > just a matter of the right web site design for MathAction and/or + > Plone? But MathAction is a wiki and kind of "fluid" by nature... + + > What do you think? + +I thinking that you are a little to afraid of this sort of freedom. I think +that axiom is too small to be a worthy target of vandalism, if we become one, +we can take measures then. I don't see any other possible problems with +fluidity. Time will tell. + + > I am thinking (out loud) that maybe there is still a role for + > http://www.nongnu.org/axiom/ ?? + +I'd suggest that we don't decide this right now. + +Thanks a lot for your work, and for your thoughts, + +\start +Date: Sat, 11 Sep 2004 14:31:29 +0000 +From: Martin Rubey +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] bug? in integrate and question about rf + +Isn't this a bug? + +integrate(x^n,x) + + n log(x) + x %e + (1) ------------ + n + 1 + + +I think that axiom should conditionalize here on n being zero or not. (Though +I'm not aware whether this is possible currently) + +Second thing: I tried to "fix" (experimentally) + +(1/x)::UP(x, FRAC POLY INT) not giving an error. + +I intended to change the coercion in UP(x, R) from R to % (which is not +instantiated currently) to test whether x occurs as a variable in r, and, if +so, spit out an error. (footnote1) + +In fact, taylor does something similar: + + if Coef has Algebra Fraction Integer then + coerce(r:RN) == r :: Coef :: % + + integrate x == integrate(0,stream x)$STT + integrate(x:%,v:Variable(var)) == integrate x + + if Coef has integrate: (Coef,Symbol) -> Coef and _ + Coef has variables: Coef -> List Symbol then + integrate(x:%,s:Symbol) == + (s = variable(x)) => integrate x + not entry?(s,variables center x) => map(integrate(#1,s),x) + error "integrate: center is a function of variable of integration" + +However, there is a tiny inaccuracy here, since + +FRAC POLY INT does not have variables: Coef -> List Symbol. + +Hence: + +integrate((1/y)::UTS(FRAC POLY INT, x, 0),z) + +does not work, although it should. + +For fractions, the function variables is in the packages POLYCATQ and RF, who +need to know over which domain the ring of fractions is build. As we know, the +compiler is not able to find out which domain this is. For example, suppose F +is a Field, although it is possible to define + +Test(F:Field, R: IntegralDomain): Exports == Implementation where + + Exports ==> with + if F has QFCAT R then + variables : F -> List Symbol + + +but you cannot use this function, if you are given only the Field, but not the +Integraldoman. + +An obvious solution is to move the function variables into QFCAT. Does anybody +know whether there is a (profound) reason not to do so? + +Martin + +(footnote1) This is not quite correct, but nearly. The right thing would be to +make the coercion only possible, if r is free of x. I don't know whether this +would be possible. + +\start +Date: Sat, 11 Sep 2004 07:32:07 -0700 (PDT) +From: C Y +To: Martin Rubey , +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +For whatever it's worth, I think the nice look of +http://www.nongnu.org/axiom/ should remain the homepage for now. +Remember, new users of Axiom will be the ones the webpage will be +trying to reach - experienced folk will migrate to the more interesting +and dynamic MathAction environment. I'd say the homepage isn't the +time to hit them with a lot of extra new concepts - the "default" +newbie starting point should always be as straight forward as possible. + Again, just my own opinion. + +Congrats on the really impressive work you guys are doing! + +\start +Date: Sat, 11 Sep 2004 21:31:26 -0400 +From: "Bill Page" +To: "'Martin Rubey'" +Subject: RE: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Martin, + +On Saturday, September 11, 2004 8:24 AM you wrote: +> ... +> [Bill Page wrote:] +>> Are there really two *separate* goals here: 1) support +>> Axiom, 2) promote the "Rosetta" ideal of many different +>> systems co-existing and growing and working together? +> +> We might be very welcome in mupad-combinat circles. +> + +What the mupad-combinat people are doing sounds interesting. + + http://mupad-combinat.sourceforge.net/ + +They even have a wiki! + + http://mupad-combinat.sourceforge.net/Wiki/HomePage.html + +The last time I looked at MuPad I was very impressed + + http://research.mupad.de/ + +And they seem to have continued to develop as a potentially +serious competitor to Maple while moving to a more "Axiom-like" +approach to mathematical content. + +But I was rather turned off by their apparent move towards +commercialization rather than an open source philosophy. + +Does anyone here have a direct contact with the MuPad Research +Group at Paderborn? If so, I would very much like to seek their +opinion on the possibility of being included in MathAction. I +would be quite willing to invest some time in implementing +the wiki interface for MuPad. + +For that matter I am also strongly motivated to implement an +interface for Maple, but currently poorly conceived (in my +opinion) licensing restrictions prevent me from doing this. +Perhaps the situation with MuPad is different? + + http://research.mupad.de/licenses.html + +However as far as I can tell from the above, their current +license would not allow us to setup open access over-the-web +to MuPad the way we have now for Axiom and Reduce. + +> +>> ... (big part skipped) ... +>> +>> Anyway, perhaps making the distinction between Axiom support +>> and the broader Rosetta goals and support for Reduce, etc. +>> is just a matter of the right web site design for MathAction +>> and/or Plone? But MathAction is a wiki and kind of "fluid" by +>> nature... +> +> > What do you think? +> +> I thinking that you are a little to afraid of this sort of +> freedom. I think that axiom is too small to be a worthy target +> of vandalism, if we become one, we can take measures then. +> I don't see any other possible problems with fluidity. Time +> will tell. + +I agree with your views. I wasn't worried about vandalism but +rather about maintaining a productive collaborative spirit +between all of the potential contributors. To me, the content +of this sort of web site is secondary to the main goal of +fostering collaboration. Perhaps there is some (small) risk +of loosing significant content or of malicious use etc. But +if at least three people are willing to run with this open +door policy (you, me and Tim) then that's ok with me. + +\start +Date: Sun, 12 Sep 2004 18:45:04 +0000 +From: Martin Rubey +To: "Bill Page" +Subject: RE: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Bill Page writes: + > Martin, + > + > On Saturday, September 11, 2004 8:24 AM you wrote: + > > ... + > > [Bill Page wrote:] + > >> Are there really two *separate* goals here: 1) support + > >> Axiom, 2) promote the "Rosetta" ideal of many different + > >> systems co-existing and growing and working together? + > > + > > We might be very welcome in mupad-combinat circles. + > > + > + > What the mupad-combinat people are doing sounds interesting. + > + > http://mupad-combinat.sourceforge.net/ + > + > They even have a wiki! + > + > http://mupad-combinat.sourceforge.net/Wiki/HomePage.html + > + > The last time I looked at MuPad I was very impressed + > + > http://research.mupad.de/ + > + > And they seem to have continued to develop as a potentially + > serious competitor to Maple while moving to a more "Axiom-like" + > approach to mathematical content. + +Yes, they are *very* strong. One reason for this is that MuPad is free for +scientists in France, as far as I know. In fact, if MuPad became free, I think +there would be little to no space left for axiom. + + > Does anyone here have a direct contact with the MuPad Research + > Group at Paderborn? If so, I would very much like to seek their + > opinion on the possibility of being included in MathAction. I + > would be quite willing to invest some time in implementing + > the wiki interface for MuPad. + +I know Nicolas Thiery. I'm pretty sure he would love to help you. + + > For that matter I am also strongly motivated to implement an + > interface for Maple, but currently poorly conceived (in my + > opinion) licensing restrictions prevent me from doing this. + > Perhaps the situation with MuPad is different? + > + > http://research.mupad.de/licenses.html + > + > However as far as I can tell from the above, their current + > license would not allow us to setup open access over-the-web + > to MuPad the way we have now for Axiom and Reduce. + +It might well be, that Nicolas can negotiate this for you. + +\start +Date: Fri, 17 Sep 2004 11:30:01 +0000 +From: Martin Rubey +To: Manuel.Bronstein@sophia.inria.fr, Ralf@Hemmecke.de, wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: conditionally defined functions + +Dear Manuel, Ralf, Tim, William, *, + +I'm struggling with something, maybe you are able to help. If not please tell +me so. + +As you might know, I'm experimenting with fixes of the following, superficially +strange behaviour: + + +(1) -> (1/x)::UP(x, FRAC POLY INT) + + 1 + (1) - + x + Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + + +Well, I think that this is calling for trouble. So, one way to fix this is to +make coerce(coef:R)-> % of UP, MPOLY and the like (in fact, are there others?) +check whether or not coef contains one of the variables -- in this case x. In +fact, I believe this is the "right" approach. + +In principle, this is not too difficult. However, there is a slight subtlety: +Currently not all domains that contain variables provide such a function, in +particular, FRAC does not. Instead, there is a package RF that provides this +functionality. Well, no problem: + +* move the operation variables from RF and POLYCATQ to QFCAT : + + if S has variables: S -> List Symbol then + variables: % -> List Symbol + variables f == + mymerge(variables(numer(f)), variables(denom(f))) + +and add the following to UP and MPOLY : + + if R has variables: R -> List Symbol then + coerce(r:R):% == + if member?(x, variables(r)) then + error "coefficient contains variable" + else coerce(r)$Rep + +This works, it seems. However, there are two things I don't like about this +"fix": + +* the function "variables" thus (conditionally) provided in QFCAT is only one + of many. I don't know of an example, but POLYCAT (which defines variables + originally) defines variables : % -> VarSet (which is a member of the + Category OrderedSet). So, for example, since SUP specialises VarSet to be + SingletonAsOrderedSet, FRAC UP won't have a function variables. + +* philosophically, this is not very beautiful. But I don't see another way to + overcome the problem. + +Now a mail of William comes in. He wrote, quite some time ago: + > Actually, there is a more general request for ages: that is, each + > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This + > would have to be built like OutputForm form the bottom up because of nesting. + > Lots of editing and a total rebuilt. Currently, when writing a constructor, + > there is no way one can "descend" inside its parameters other than finding their + > categorical property or attributes. + +However, I don't really see how this could be used. I modified POLYCAT to +contain a function + +varset: () -> OrderedSet +varset () == VarSet + +but I was not able to do anything useful with this. Of course, what I'd like to +say in QFCAT would be + +I'd like to be able to say in QFCAT something like: + + if S has varset: () -> OrderedSet then + variables: % -> List varset() + variables f == + mymerge(variables(numer(f)), variables(denom(f))) + +But this looks fishy. + +So, in more general terms, here's my question: + +Suppose you have a category A, taking as parameter a domain P and providing an +operation f: % -> P. Furthermore, you have a category (or a domain, a package) +B, taking as parameter a domain Q. Now you want to achieve the following: + +If Q is a domain in A, provide a function g: % -> P, using f. + +Of course, it is not possible to provide P as a parameter of B, since B should +also be defined for Q's that are not domains in A... + +I suspect that this is the reason for making RationalFunction a +package. However, this does not provide the full functionality, as you can see +from the problem above. + +Did I get something backwards, is there another solution? + +\start +Date: Fri, 17 Sep 2004 12:52:42 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions + +Hi Martin, + +> Suppose you have a category A, taking as parameter a domain P and providing an +> operation f: % -> P. Furthermore, you have a category (or a domain, a package) +> B, taking as parameter a domain Q. Now you want to achieve the following: +> +> If Q is a domain in A, provide a function g: % -> P, using f. + +Let me translate this into some code... + +define A(P: Cat1): Category == with { + f: % -> P; +} + +-- Assume B should be a domain. +B(Q: Cat2): Cat3 with { + if Q has A(???) then {g: % -> ???} +} + +To me it seems that in order to state that "Q is a domain in A" one +would have to know the parameter of A. Note that A is a function +returning a category. The ??? should be something of type Cat1. And I +don't see this information somewhere available inside the definition of B. + +I guess that is not your point. Can you be more precise here? + +\start +Date: Fri, 17 Sep 2004 15:14:49 +0000 +From: Martin Rubey +To: Ralf HEMMECKE +Subject: [Axiom-developer] Re: conditionally defined functions + +Ralf HEMMECKE writes: + > Hi Martin, + > + > > Suppose you have a category A, taking as parameter a domain P and providing an + > > operation f: % -> P. Furthermore, you have a category (or a domain, a package) + > > B, taking as parameter a domain Q. Now you want to achieve the following: + > > + > > If Q is a domain in A, provide a function g: % -> P, using f. + > + > Let me translate this into some code... + > + > define A(P: Cat1): Category == with { + > f: % -> P; + > } + > + > -- Assume B should be a domain. + > B(Q: Cat2): Cat3 with { + > if Q has A(???) then {g: % -> ???} + > } + > + > To me it seems that in order to state that "Q is a domain in A" one + > would have to know the parameter of A. Note that A is a function + > returning a category. The ??? should be something of type Cat1. And I + > don't see this information somewhere available inside the definition of B. + > + > I guess that is not your point. Can you be more precise here? + +Hmm, I think it is my point indeed. I don't know Aldor syntax, but my idea was +roughly + + define A(P: Cat1): Category == with { + arg: () -> Cat1 + f: % -> P; + -- the operation arg returns a domain... + arg () == P + } + + + + -- Assume B should be a domain. + B(Q: Cat2): Cat3 with { + if Q has arg: () -> Cat1 then {g: % -> arg()} + } + +Thanks for replying that fast, + +\start +Date: Fri, 17 Sep 2004 15:38:06 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions + +Hi Martin, + +> As you might know, I'm experimenting with fixes of the following, superficially +> strange behaviour: +> +> +> (1) -> (1/x)::UP(x, FRAC POLY INT) +> +> 1 +> (1) - +> x +> Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + +Hmm, when I simply type 1/x, I get: + + 1 + (4) - + x + Type: Fraction Polynomial Integer + +So coercing this into UP(x, FRAC POLY INT) is OK. It only looks a bit +strange, because you might want to get an error message telling you that +you cannot have x in the denominator. + +I made the following experiment: + +(5) -> X := monomial(1,1)$UP(x, FRAC POLY INT) + (5) x + Type: UnivariatePolynomial(x,Fraction Polynomial Integer) +(8) -> inv X + + 1 + (8) - + x + Type: Fraction UnivariatePolynomial(x,Fraction Polynomial Integer) +(9) -> 1/X + + 1 + (9) - + x + Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + +That the types are different is really a bit strange. + + +If I posed the question: + +Is UP(x, FRAC POLY INT) = FRAC POLY INT ? + +What would you answer? I am not asking for equality of the domains in +AXIOM, but rather what FRAC POLY INT is mathematically. + +\start +Date: Fri, 17 Sep 2004 15:56:55 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions + +Hi Martin, + +> Hmm, I think it is my point indeed. I don't know Aldor syntax, but my idea was +> roughly +> +> define A(P: Cat1): Category == with { +> arg: () -> Cat1 +> f: % -> P; +> -- the operation arg returns a domain... +> arg () == P +> } +> +> +> +> -- Assume B should be a domain. +> B(Q: Cat2): Cat3 with { +> if Q has arg: () -> Cat1 then {g: % -> arg()} +> } + +Oje, I guess that is too much to hope for. I am not one of the language +designers, but since everything in Aldor/Axiom is first class in +principle it should work. + +There is, however, a little problem which is not so obvious in your +"argument code arg()". What if I say the following? + +DomA(P1: Cat1, P2: Cat1): A(P1) == add { + b: Boolean := false; + arg(): Cat1 := { + free b; + b := not b; + if b then P1 else P2; + } + ... +} + +Now, what is the type of B(DomA(P1,P2))? Does + B(DomA(P1,P2)) +have the same type as + B(DomA(P1,P2))? + +\start +Date: 17 Sep 2004 10:43:02 -0400 +From: Camm Maguire +To: "Bill Page" +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Greetings, all! The site looks great! I just have one request -- it +should be made clear early on that reduce is not open source software. +It appears from their site that they are selling the source under some +circumstances however (cannot see where though). It would be helpful +if someone could report on whether their conditions would allow +inspection of the source for use in spotting bugs in axiom. Am also +wondering if standard lisp, as a 'subset', will run on gcl much as the +'applicative common lisp' subset does in acl2. + +\start +Date: Fri, 17 Sep 2004 16:12:05 +0100 (GMT Daylight Time) +From: Arthur Norman +To: Camm Maguire +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org, Bill Page + +On Fri, 17 Sep 2004, Camm Maguire wrote: +> Greetings, all! The site looks great! I just have one request -- it +> should be made clear early on that reduce is not open source software. +> It appears from their site that they are selling the source under some +> circumstances however (cannot see where though). It would be helpful +> if someone could report on whether their conditions would allow +> inspection of the source for use in spotting bugs in axiom. Am also +> wondering if standard lisp, as a 'subset', will run on gcl much as the +> 'applicative common lisp' subset does in acl2. +> +> Take care, +> -- +If you follow www.reduce-algebra.com you will find that a "personal" +version of Reduce is available (for perhaps a limited range of platforms) +and that comes without source, and there is a "professional" version that +comes with source (and in some cases full source of the Lisp use dto +build it). And of course multiple-installation and site licenses are also +available. +Reduce has two distributors who use different Lisp systems, both +conforming to "standard lisp". At one stage a mapping of that onto Common +Lisp was available but that is no longer supported or available. One of +the versions of Reduce is built on and comes with my "CSL" Lisp system and +when NAG distributed Axiom I had adjustments to that that supported enough +of the common lisp-isms that Axiom built on it. To my mind the key +featuures of what was done there were that (a) one compiled image file +could then be run on almost any platform (windows, linux, lots of sorts of +Unix) so the need for per-platform compilation of all that Lisp was +removed. And platform-specific glitches and incompatibilities would be +minimised. (b) at the time Axiom was notably a resource hog by the +standard of workstations available and "CCL" (thing S=standard, C=common, +L=lisp, c=Codemist) allowed it to run with a relatively modest footprint. + +Note that some in the new Axiom world have declared use of CCL to be one +of the worst mistakes anybody ever made wrt Axiom and that my Lisp is thus +to be abhored.. so do not get too enthusiastic. + +\start +Date: 17 Sep 2004 11:17:57 -0400 +From: Camm Maguire +To: Martin Rubey +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org, Bill Page + +Greetings! + +Martin Rubey writes: + +> Bill Page writes: +> > The last time I looked at MuPad I was very impressed +> > +> > http://research.mupad.de/ +> > +> > And they seem to have continued to develop as a potentially +> > serious competitor to Maple while moving to a more "Axiom-like" +> > approach to mathematical content. +> +> Yes, they are *very* strong. One reason for this is that MuPad is free for +> scientists in France, as far as I know. In fact, if MuPad became free, I think +> there would be little to no space left for axiom. +> + +This is our challenge. Do the mathematicians of the world have enough +spare brain cycles to move beyond the position of a mere consumer +choosing among whatever best black box happens to be available for the +task at hand, to the position of a part-time contributor to a system +permanently owned by the public, and in which the knowledge of *how* +something is done is available at any time to anyone who desires to +read? To look at the immense complexity of the Linux kernel, gcc, +etc., the challenge is not impossible. But it is critical that we +prioritize, organize, and gain a community of minds *very* familiar +with the details of the system. I am the worst offender as the only +thing in which I'm any kind of expert at present is gcl. + +If someone can suggest a good, high priority, somewhat manageable +task, I'm willing to do my part. + +\start +Date: Fri, 17 Sep 2004 18:03:24 +0000 +From: Martin Rubey +To: Ralf HEMMECKE +Subject: [Axiom-developer] Re: conditionally defined functions + +Hi Ralf, + +Ralf HEMMECKE writes: + > Hi Martin, + > + > > As you might know, I'm experimenting with fixes of the following, superficially + > > strange behaviour: + > > + > > + > > (1) -> (1/x)::UP(x, FRAC POLY INT) + > > + > > 1 + > > (1) - + > > x + > > Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + > + > Hmm, when I simply type 1/x, I get: + > + > 1 + > (4) - + > x + > Type: Fraction Polynomial Integer + > + > So coercing this into UP(x, FRAC POLY INT) is OK. + +Well, I think it shouldn't. But maybe I'm wrong. But in the latter case, I'd +argue that UP(x, FRAC POLY INT) should be a forbidden type. + + > It only looks a bit strange, because you might want to get an error message + > telling you that you cannot have x in the denominator. + > + > I made the following experiment: + > + > (5) -> X := monomial(1,1)$UP(x, FRAC POLY INT) + > (5) x + > Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + > (8) -> inv X + > + > 1 + > (8) - + > x + > Type: Fraction UnivariatePolynomial(x,Fraction Polynomial Integer) + > (9) -> 1/X + > + > 1 + > (9) - + > x + > Type: UnivariatePolynomial(x,Fraction Polynomial Integer) + > + +that's interesting. I like (8), but I dislike (9). + + > That the types are different is really a bit strange. + > + > + > If I posed the question: + > + > Is UP(x, FRAC POLY INT) = FRAC POLY INT ? + > + > What would you answer? I am not asking for equality of the domains in + > AXIOM, but rather what FRAC POLY INT is mathematically. + + +I'd answer: well...no + +FRAC POLY INT is the domain of fractions of polynomials with integer coeffs. + +UP(x, FRAC POLY INT) is the domain of univariate polynomials in x, having +fractions of polynomials with integer coeffs as coeffs. + +But the latter type makes sense only if you don't allow x to "appear" in the +coefficients. + +Note that + +(1) -> x::UP(x, FRAC MPOLY([x], INT)) + + UnivariatePolynomial(x,Fraction MultivariatePolynomial([x],Integer)) + is not a valid type. + +(1) -> x::UP(x, FRAC MPOLY([y], INT)) + (1) x + Type: UnivariatePolynomial(x,Fraction MultivariatePolynomial([y],Integer)) + +\start +Date: Fri, 17 Sep 2004 12:33:52 -0400 +From: "Bill Page" +To: "'Arthur Norman'" +Subject: RE: [Axiom-developer] RE: mathaction +Cc: 'Camm Maguire' , dmentre@linux-france.org + +On Friday, September 17, 2004 11:12 AM Arthur Norman +acn1@cam.ac.uk +> ... +> Note that some in the new Axiom world have declared use of +> CCL to be one of the worst mistakes anybody ever made wrt +> Axiom and that my Lisp is thus to be abhored.. so do not +> get too enthusiastic. +> + +I may not hear everything that get said about "the new +Axiom world" but I have certainly never heard anyone make +such a statement about CCL and axiom! In fact the full source +of CCL including the Axiom specific parts is still included +in the Axiom CVS with the expectation that someone somewhere +would go to the trouble of re-integrating CCL and Axiom as +a buildable platform. I tried this myself almost two years +ago in the hopes of getting quickly to a running Windows +version of open source Axiom but my lack of experience and +lack of sufficient time got in the way. + +It seems to me that the current emphasis on GCL and Axiom +is only a result of personal choices and limited resources. + +We are apparently close to having a running version of +Axiom using GCL on Windows but still some problems well +beyond my skill level in GCL and Windows remains. + +\start +Date: Fri, 17 Sep 2004 13:27:58 -0400 +From: "Bill Page" +To: "'Camm Maguire'" +Subject: RE: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +On Friday, September 17, 2004 11:18 AM Camm Maguire +camm@enhanced.com +> +> Martin Rubey writes: +> ... +> > Yes, they [Mupad] are *very* strong. One reason for this is +> > that MuPad is free for scientists in France, as far as I know. +> > In fact, if MuPad became free, I think there would be little +> > to no space left for axiom. +> +> This is our challenge. Do the mathematicians of the world have +> enough spare brain cycles to move beyond the position of a mere +> consumer choosing among whatever best black box happens to be +> available for the task at hand, to the position of a part-time +> contributor to a system permanently owned by the public, and in +> which the knowledge of *how* something is done is available at +> any time to anyone who desires to read? + +Well, one of the goals of MathAction could be to make this +possible with a minimum of concern about programming and +configuring operating systems etc. Certainly in the past +mathematicians have been major contributors to Axiom and Reduce +but the learning curve and the investment in appropriate +infrastructure (including local guru's etc.) is rather +prohibitive. I doubt though, that most people who have used +either of these two systems successfully have really taken +a "black box" view. In general, I don't think computer algebra +is anywhere near mature enough to take such a view - even +among the most developed and commercially funded such as Maple +and Mathematica. In almost all cases I would be quite sure +that sooner or later there was a need to look at the actual +code and often to make improvements in the underlying code +in order to address other specific end results. + +The idea to extend this beyond Axiom to include Reduce, Maxima, +Mupad, etc. is a separate but related goal. It seems to me that +because of the very large time and intellectual investments +involved, it has been difficult for many people to take a wider +view and thereby make it possible to better share the critically +limited resources. Maybe having at least a common user interface +(e.g. the collaborative wiki environment such as MathAction) +between the diverse systems will remove one of the barriers to +the pooling of expertise. For example web browser based user +interfaces seem to be quickly growing in popularity among new +Linux users (e.g. Gnome and KDE) and also among large computer +systems administrators (e.g. Webmin for system administration). + +> To look at the immense complexity of the Linux kernel, gcc, +> etc., the challenge is not impossible. But it is critical +> that we prioritize, organize, and gain a community of minds +> *very* familiar with the details of the system. + +I hope that becoming a contributor to Axiom (or any other +computer algebra system) does not really require the same +kind of effort as the Linux kernel! If so, then I think the +project is doomed from the start. There just aren't enough +people available to make such a commitment. + +>From my point of view, the most promising approach is to +attempt to reduce the *apparent complexity" of these systems +through the use of much improved user interface tools (such +as in the current MathAction experiment ... :) If we assume +that one of the reasons work on these systems has (more or +less) stalled is because they have reached some sort of +human limit in the ability to deal with the complexity, then +it seems reasonable to expect that even a modest reduction +in the apparently complexity would enable many of the +potential contributors to continue the job. Though this is +probably a "too optimistic" scenario. + +> I am the worst offender as the only thing in which I'm any +> kind of expert at present is gcl. +> + +I don't consider that an "offence"... at least we have you +as an expert! :) + +> If someone can suggest a good, high priority, somewhat +> manageable task, I'm willing to do my part. +> + +I am not sure what you have in mind but just to get started, +since you did raise the issue of Reduce licensing in a +previous message, may be you would like to try making a +modification to one or more pages on MathAction to reflect +this situation with Reduce? If you have questions about how +to proceed with using the MathAction wiki interface, then +I would be very glad to help - or perhaps Martin also. + +\start +Date: Fri, 17 Sep 2004 23:56:12 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions +Cc: Ralf@Hemmecke.de, axiom-developer@nongnu.org, Manuel.Bronstein@sophia.inria.fr + +Martin Rubey wrote: +> +> Dear Manuel, Ralf, Tim, William, *, +> +> I'm struggling with something, maybe you are able to help. If not please tell +> me so. +Ok, can't help :-). + +> As you might know, I'm experimenting with fixes of the following, superficially +> strange behaviour: +> +> (1) -> (1/x)::UP(x, FRAC POLY INT) +> +> 1 +> (1) - +> x +> Type: UnivariatePolynomial(x,Fraction Polynomial Integer) +> +> Well, I think that this is calling for trouble. So, one way to fix this is to +> make coerce(coef:R)-> % of UP, MPOLY and the like (in fact, are there others?) +> check whether or not coef contains one of the variables -- in this case x. In +> fact, I believe this is the "right" approach. + +Axiom was designed to accommodate this, that is, some polynomial domains (like +POLY, ODPOLY) are constructed with Symbol as the set of indeterminates while +others like UP, MPOLY, DMP, HDMP, GDMP, SMP, DSMP, etc specify a particular set +of named indeterminates. If you want to construct towers of polynomial rings, +then you should be using the second kind. Any time you mix one kind with the +other in a tower, you are calling for trouble (your words). If indeed a domain +of the first kind has to mixed with one of the other kind in a tower, it is +imperative that the first kind domain be converted (coerced, lifted, whatever) +to the second kind by finding the set of indeterminates involved IN THE +COMPUTATION (that is, "locally" for a finite set of polynomials involved only, +not the entire domain) using the spad function [variables] ([ ] just to say +this is a spad function, not used as an English mathematical word). This is +routinely done in radical ideal membership testing using grobner basis, where +the user supplies polynomials from POLY INT and an auxilliary indeterminate is +needed. The computation is done in for example a tower of DMP's. The auxilliary +indeterminate can be generated by the compiler which does not conflict of any +existing names. The result is then converted back to POLY, if needed. + +Note that the suggestion you made above, when carried out locally, amounts to +the same thing. The "local" solution works, though it is not very efficient +because of all the coercions. For example, see source for qalgsetp.spad (see +construction of newPoly. The "global" solution, on the other hand, does not make +sense because Symbol includes everything. + +In previous messages, we already discussed and agreed that the x in UP(x, FRAC +POLY INT) will be internally different than the x in FRAC POLY INT. The compiler +keeps track of them as different. However, to use the same output symbol for two +different indeterminates is simply wrong from the user interface viewpoint. + +> +> In principle, this is not too difficult. However, there is a slight subtlety: +> Currently not all domains that contain variables provide such a function, in +> particular, FRAC does not. Instead, there is a package RF that provides this +> functionality. Well, no problem: +> +> * move the operation variables from RF and POLYCATQ to QFCAT : +> +> if S has variables: S -> List Symbol then +> variables: % -> List Symbol +> variables f == +> mymerge(variables(numer(f)), variables(denom(f))) +> +> and add the following to UP and MPOLY : +> +> if R has variables: R -> List Symbol then +> coerce(r:R):% == +> if member?(x, variables(r)) then +> error "coefficient contains variable" +> else coerce(r)$Rep +> +> This works, it seems. However, there are two things I don't like about this +> "fix": + +If this works, it works wrongly, because this confuses the x in the inner domain +of a tower with the x in the outer domain of the tower. Remember that the +compiler distinguishes these already. So the condition + member?(x, variables(r)) +would always return false. The identifier x (NOT a symbol) is bound to an +internal symbol, which would NOT appear in variables(r) (a "local" +construct).Unless you change UP fundamentally to consider the parameter x in its +call to bind to an existing identifier x. But this would probably break a lot of +code and defeat the r'aison d'ete of UP. + + +> * the function "variables" thus (conditionally) provided in QFCAT is only one +> of many. I don't know of an example, but POLYCAT (which defines variables +> originally) defines variables : % -> VarSet (which is a member of the +> Category OrderedSet). So, for example, since SUP specialises VarSet to be +> SingletonAsOrderedSet, FRAC UP won't have a function variables. +> +> * philosophically, this is not very beautiful. But I don't see another way to +> overcome the problem. + +If you are only dealing with a finite set of polynomials or fraction of these +and want to find its variables, you can always write such a routine even if the +domain does not have one (as in FRAC). + +> Now a mail of William comes in. He wrote, quite some time ago: +> > Actually, there is a more general request for ages: that is, each +> > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This +> > would have to be built like OutputForm form the bottom up because of nesting. +> > Lots of editing and a total rebuilt. Currently, when writing a constructor, +> > there is no way one can "descend" inside its parameters other than finding their +> > categorical property or attributes. +> +> However, I don't really see how this could be used. I modified POLYCAT to +> contain a function +> +> varset: () -> OrderedSet +> varset () == VarSet +> +> but I was not able to do anything useful with this. Of course, what I'd like to +> say in QFCAT would be +> +> I'd like to be able to say in QFCAT something like: +> +> if S has varset: () -> OrderedSet then +> variables: % -> List varset() +> variables f == +> mymerge(variables(numer(f)), variables(denom(f))) +> +> But this looks fishy. + +I don't know what you meant by "fishy". The code would not work at present +because I don't think you can consider a function as an attribute. You have to +register it in the AttributeRegistry first. However, since the signature is not +"constant", I wonder if this can be done at all. Note also you must package +call varset(), which thus requires you to know the parameters, a catch-22 +situation. + +The problem you raised is one of what might be called dynamic signature, that is +the codomain depends on the input value. The Axiom compiler can handle this +partly, in a category/domain constructor's signature, but not on the function +level. For an example, see the signature of domain constructor DMP, where #vl is +used in the codomain. +> +> So, in more general terms, here's my question: +> +> Suppose you have a category A, taking as parameter a domain P and providing an +> operation f: % -> P. Furthermore, you have a category (or a domain, a package) +> B, taking as parameter a domain Q. Now you want to achieve the following: +> +> If Q is a domain in A, provide a function g: % -> P, using f. +> +> Of course, it is not possible to provide P as a parameter of B, since B should +> also be defined for Q's that are not domains in A... + +The way to handle this is to create a special version of B, which takes a domain +in A as parameter, together with parameters needed for A and construct the +special version using the general one. This is ok because the compiler can +handle dynamic signature on the category/domain constructor level. + +BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P } + +You can then add the function g without a problem. The moral is: Don't Ask, Just +Tell. + +\start +Date: Sun, 19 Sep 2004 21:09:12 +0200 (CEST) +From: Waldek Hebisch +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Build on AMD64 + +I have build Axiom (CVS from 17.09.2004) on AMD64 (Mandrake) and +on i386 (Debian Woody). Some remarks: + +- on AMD64 64-bit X libraries are in '/usr/X11R6/lib64' ('/usr/X11R6/lib' + contains 32-bit versions). Such approach seem to be standard for + having both 64-bit and 32-bit binaries on Linux. So I had to change + 'Makefile.pamphlet' accordingly + +- to complile with Debian gcc-2.95.4 I had to apply the following + patch to gcl (otherwise gcc-2.95.4 choked on semicolon before + declarations): + +--- gmp_wrappers.h.bb Fri Sep 17 13:38:59 2004 ++++ gmp_wrappers.h Fri Sep 17 13:39:35 2004 +@@ -96,8 +96,8 @@ + + #define MEM_GMP_CALL(n_,rt_,a_,s_,b_...) \ + GMP_EXTERN_INLINE Join(RF_,rt_) Join(m,a_)(Join(P,n_)(b_)) { \ +- Join(RD_,rt_);\ + int j;\ ++ Join(RD_,rt_);\ + jmp_gmp=0;\ + if ((j=setjmp(gmp_jmp)))\ + GBC(j);\ + +- many files (especially in 'zips' subdirectory) have executable + permissions for no good reason. This is a problem when viewing + them using Midnight Commander as mc tries to run them + +- I suggest to '\usepackage[hypertex]{hyperref}' (or just plain + hyperref if generating pdf-s) in Latex files. It makes the + Axiom book much nicer for navigation in xdvi. For on-screen + viewing it wold be nice to reduce margins. + +- CVS seem to contain many 'junk' files. I understand that it + will take some work to automatically generate databases and + other files may contain some usefull info. But for example + 'gcl-2.6.3.tgz' just is pure bloat (since 2.6.5 is used for + build) + +\start +Date: Mon, 20 Sep 2004 13:38:09 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: conditionally defined functions +Cc: Ralf@Hemmecke.de, Manuel.Bronstein@sophia.inria.fr + +William Sit writes: + > > In principle, this is not too difficult. However, there is a slight subtlety: + > > Currently not all domains that contain variables provide such a function, in + > > particular, FRAC does not. Instead, there is a package RF that provides this + > > functionality. Well, no problem: + > > + > > * move the operation variables from RF and POLYCATQ to QFCAT : + > > + > > if S has variables: S -> List Symbol then + > > variables: % -> List Symbol + > > variables f == + > > mymerge(variables(numer(f)), variables(denom(f))) + > > + > > and add the following to UP and MPOLY : + > > + > > if R has variables: R -> List Symbol then + > > coerce(r:R):% == + > > if member?(x, variables(r)) then + > > error "coefficient contains variable" + > > else coerce(r)$Rep + > > + > + > If this works, it works wrongly, because this confuses the x in the inner + > domain of a tower with the x in the outer domain of the tower. + +I don't understand what you mean with "wrongly". I'm aiming at the following: I +want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function +(or expression) that is a polynomial in x. I tested the code above and it does +indeed "work" (in this sense). + + > Remember that the compiler distinguishes these already. So the condition + + > member?(x, variables(r)) + + > would always return false. + +No, it does not. (at least not in the tests I ran) + + > I don't know what you meant by "fishy". The code would not work at present + > because I don't think you can consider a function as an attribute. + +Hmm, I think you can. The code above does so. + + > The problem you raised is one of what might be called dynamic signature, that is + > the codomain depends on the input value. The Axiom compiler can handle this + > partly, in a category/domain constructor's signature, but not on the function + > level. + +Yes, that's what I think, too. + + > > So, in more general terms, here's my question: + > > + > > Suppose you have a category A, taking as parameter a domain P and providing an + > > operation f: % -> P. Furthermore, you have a category (or a domain, a package) + > > B, taking as parameter a domain Q. Now you want to achieve the following: + > > + > > If Q is a domain in A, provide a function g: % -> P, using f. + > > + > > Of course, it is not possible to provide P as a parameter of B, since B should + > > also be defined for Q's that are not domains in A... + > + > The way to handle this is to create a special version of B, which takes a domain + > in A as parameter, together with parameters needed for A and construct the + > special version using the general one. This is ok because the compiler can + > handle dynamic signature on the category/domain constructor level. + > + > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P } + > + > You can then add the function g without a problem. The moral is: Don't Ask, Just + > Tell. + +\start +Date: Mon, 20 Sep 2004 10:08:53 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions +Cc: Ralf@Hemmecke.de, axiom-developer@nongnu.org, Manuel.Bronstein@sophia.inria.fr + +Martin Rubey wrote: +> +> William Sit writes: +> > > In principle, this is not too difficult. However, there is a slight subtlety: +> > > Currently not all domains that contain variables provide such a function, in +> > > particular, FRAC does not. Instead, there is a package RF that provides this +> > > functionality. Well, no problem: +> > > +> > > * move the operation variables from RF and POLYCATQ to QFCAT : +> > > +> > > if S has variables: S -> List Symbol then +> > > variables: % -> List Symbol +> > > variables f == +> > > mymerge(variables(numer(f)), variables(denom(f))) +> > > +> > > and add the following to UP and MPOLY : +> > > +> > > if R has variables: R -> List Symbol then +> > > coerce(r:R):% == +> > > if member?(x, variables(r)) then +> > > error "coefficient contains variable" +> > > else coerce(r)$Rep +> > > +> > +> > If this works, it works wrongly, because this confuses the x in the inner +> > domain of a tower with the x in the outer domain of the tower. +> +> I don't understand what you mean with "wrongly". I'm aiming at the following: I +> want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function +> (or expression) that is a polynomial in x. I tested the code above and it does +> indeed "work" (in this sense). +> +> > Remember that the compiler distinguishes these already. So the condition +> +> > member?(x, variables(r)) +> +> > would always return false. +> +> No, it does not. (at least not in the tests I ran) +> +> > I don't know what you meant by "fishy". The code would not work at present +> > because I don't think you can consider a function as an attribute. +> +> Hmm, I think you can. The code above does so. + +One can never argue with code that works! I am surprised that a function can be +treated as an attribute -- I tried that in the interpreter: + +INT has min: (INT, INT)->Boolean + false + +Of course, it has. I think the reason why the answer is false is because this +property is not in the AttributeRegistry. Another difference between interpreter +and compiler? + +Martin, I did not test your code (lack of time, but probably also I do not have +the setup as well. I might even have misunderstood your question: Perhaps you +are just trying to "lift" a polynomial (or rational function) with integer +coefficient that may or may not involve x (and if it does, only polynomially) +and just want to separate the variable x and rewrite it as a polynomial in x +with all the rest as coefficients? In other words, there is never two different +x's and you just want to rewrite something like Q[a,b,...w,x] as +Q[a,b,...,w][x]? Have you tried using POLYLIFT? + +As to why I think if it works, it works wrongly: +Try this: + +(1) -> )clear all +(1) -> y:=3*x + 1 + (1) 3x+1 Type: Polynomial Integer +(2) -> z: UP(x, POLY INT) + Type: Void +(3) -> z:=3*x + 1 + (3) 3x+1 Type: UnivariatePolynomial(x,Polynomial Integer) +(4) -> t:=variables(y) + (4) [x] Type: List Symbol +(5) -> s:=variables(z) + (5) ["?"] Type: List SingletonAsOrderedSet +(6) sx:=s.1 + (6) "?" Type: SingletonAsOrderedSet +(7) member?(sx,t) + (7) true Type: Boolean + +Is this correct? How? + +(8) sxx:=convert(sx) + (8) ? Type: Symbol +(9) tx := t.1 + (9) x Type: Symbol +(10) g:Boolean:= sxx=tx + (10) false Type: Boolean +(11) g:= sx = tx + (11) true Type: Boolean + +How do you explain (11) that two items of different type can be equal, and (10), +after conversion to the same type, are not? + +William +--- + +PS: +> > Remember that the compiler distinguishes these already. So the condition +> +> > member?(x, variables(r)) +> +> > would always return false. +> +> No, it does not. (at least not in the tests I ran) + +I was writing based on a similar situation we discussed on June 12: + +---quote from June 12 +So is this a bug? I am not sure, it may be good that the interpreter caught the +ambiguity and it may be bad that the compiler does not. The compiler actually +knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is +used, but we (human) will get all confused. Try: + +)abb package TEST Test + +Test():Target==Implementation where + EXPR ==> Expression + POLY ==> Polynomial + INT ==> Integer + Target ==> with + f1: () -> EXPR POLY INT + f2: () -> POLY INT + f3: () -> EXPR POLY INT + f4: () -> EXPR POLY INT + Implementation ==> add + a:=new()$Symbol + b:=a ::EXPR POLY INT + c:=a :: POLY INT + f1()==b + f2()==c + f3()== (c*b)/b + f4()== f3()/b + +Note that if you check the signature of /, the compiler "knows" it is legally +used and the answer for f4() is c/b, not 1 (which should be the case +mathematically). +---end of quote + +I have not tried to replace EXPR by UP(x, ...) in Test(). Perhaps they behave +differently + +\start +Date: 22 Sep 2004 10:20:35 -0400 +From: Camm Maguire +To: Waldek Hebisch +Subject: Re: [Axiom-developer] Build on AMD64 + +Greetings! + +Waldek Hebisch writes: + +> - to complile with Debian gcc-2.95.4 I had to apply the following +> patch to gcl (otherwise gcc-2.95.4 choked on semicolon before +> declarations): +> +> --- gmp_wrappers.h.bb Fri Sep 17 13:38:59 2004 +> +++ gmp_wrappers.h Fri Sep 17 13:39:35 2004 +> @@ -96,8 +96,8 @@ +> +> #define MEM_GMP_CALL(n_,rt_,a_,s_,b_...) \ +> GMP_EXTERN_INLINE Join(RF_,rt_) Join(m,a_)(Join(P,n_)(b_)) { \ +> - Join(RD_,rt_);\ +> int j;\ +> + Join(RD_,rt_);\ +> jmp_gmp=0;\ +> if ((j=setjmp(gmp_jmp)))\ +> GBC(j);\ +> + +Just a note -- this is in CVS head. It is only required for gcc-2.95 +and below (presumably). + +Take care, + + +> - many files (especially in 'zips' subdirectory) have executable +> permissions for no good reason. This is a problem when viewing +> them using Midnight Commander as mc tries to run them +> +> - I suggest to '\usepackage[hypertex]{hyperref}' (or just plain +> hyperref if generating pdf-s) in Latex files. It makes the +> Axiom book much nicer for navigation in xdvi. For on-screen +> viewing it wold be nice to reduce margins. +> +> - CVS seem to contain many 'junk' files. I understand that it +> will take some work to automatically generate databases and +> other files may contain some usefull info. But for example +> 'gcl-2.6.3.tgz' just is pure bloat (since 2.6.5 is used for +> build) + +\start +Date: 22 Sep 2004 10:31:09 -0400 +From: Camm Maguire +To: Arthur Norman +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org, Bill Page + +Greetings! + +Arthur Norman writes: + +> On Fri, 17 Sep 2004, Camm Maguire wrote: +> > Greetings, all! The site looks great! I just have one request -- it +> > should be made clear early on that reduce is not open source software. +> > It appears from their site that they are selling the source under some +> > circumstances however (cannot see where though). It would be helpful +> > if someone could report on whether their conditions would allow +> > inspection of the source for use in spotting bugs in axiom. Am also +> > wondering if standard lisp, as a 'subset', will run on gcl much as the +> > 'applicative common lisp' subset does in acl2. +> > +> > Take care, +> > -- +> If you follow www.reduce-algebra.com you will find that a "personal" +> version of Reduce is available (for perhaps a limited range of +> platforms) and that comes without source, and there is a +> "professional" version that comes with source (and in some cases full +> source of the Lisp use dto build it). And of course +> multiple-installation and site licenses are also available. +> Reduce has two distributors who use different Lisp systems, both +> conforming to "standard lisp". At one stage a mapping of that onto +> Common Lisp was available but that is no longer supported or +> available. One of the versions of Reduce is built on and comes with my + +Thanks for the information! Reduce does look nice and I wish it well +in the marketplace. If and when it is ever judged that Reduce's +lifecycle as a commercial product has come to an end, I do hope that +the authors will consider following the example NAG has set with +axiom, and that hopefully sufficient advance notice will be given to +allow people to organize open support as seemlessly as possible. + +> "CSL" Lisp system and when NAG distributed Axiom I had adjustments to +> that that supported enough of the common lisp-isms that Axiom built on +> it. To my mind the key featuures of what was done there were that (a) +> one compiled image file could then be run on almost any platform +> (windows, linux, lots of sorts of Unix) so the need for per-platform +> compilation of all that Lisp was removed. And platform-specific +> glitches and incompatibilities would be minimised. (b) at the time +> Axiom was notably a resource hog by the standard of workstations +> available and "CCL" (thing S=standard, C=common, L=lisp, c=Codemist) +> allowed it to run with a relatively modest footprint. +> +> Note that some in the new Axiom world have declared use of CCL to be +> one of the worst mistakes anybody ever made wrt Axiom and that my Lisp +> is thus to be abhored.. so do not get too enthusiastic. +> + +Your lisp is great, and even more, your helpfulness and support. +IMHO, there are too many lisps for the good of the language -- I wish +I knew of a way we could all combine forces. + +\start +Date: 22 Sep 2004 10:44:53 -0400 +From: Camm Maguire +To: "Bill Page" +Subject: Re: [Axiom-developer] RE: mathaction +Cc: dmentre@linux-france.org + +Greetings! + +"Bill Page" writes: + +> On Friday, September 17, 2004 11:18 AM Camm Maguire +> camm@enhanced.com +> > +> > Martin Rubey writes: +> > ... +> > > Yes, they [Mupad] are *very* strong. One reason for this is +> > > that MuPad is free for scientists in France, as far as I know. +> > > In fact, if MuPad became free, I think there would be little +> > > to no space left for axiom. +> > +> > This is our challenge. Do the mathematicians of the world have +> > enough spare brain cycles to move beyond the position of a mere +> > consumer choosing among whatever best black box happens to be +> > available for the task at hand, to the position of a part-time +> > contributor to a system permanently owned by the public, and in +> > which the knowledge of *how* something is done is available at +> > any time to anyone who desires to read? +> +> Well, one of the goals of MathAction could be to make this +> possible with a minimum of concern about programming and +> configuring operating systems etc. Certainly in the past + +Great! Hopefully a robust packaging system containing axiom, a la +Debian/FreeBSD/... can achieve a similar goal. + +... + +> The idea to extend this beyond Axiom to include Reduce, Maxima, +> Mupad, etc. is a separate but related goal. It seems to me that +> because of the very large time and intellectual investments +> involved, it has been difficult for many people to take a wider +> view and thereby make it possible to better share the critically +> limited resources. Maybe having at least a common user interface +> (e.g. the collaborative wiki environment such as MathAction) +> between the diverse systems will remove one of the barriers to +> the pooling of expertise. For example web browser based user +> interfaces seem to be quickly growing in popularity among new +> Linux users (e.g. Gnome and KDE) and also among large computer +> systems administrators (e.g. Webmin for system administration). +> + +A great initiative -- go Bill go! + +> > To look at the immense complexity of the Linux kernel, gcc, +> > etc., the challenge is not impossible. But it is critical +> > that we prioritize, organize, and gain a community of minds +> > *very* familiar with the details of the system. +> +> I hope that becoming a contributor to Axiom (or any other +> computer algebra system) does not really require the same +> kind of effort as the Linux kernel! If so, then I think the +> project is doomed from the start. There just aren't enough +> people available to make such a commitment. +> + +I have a somewhat different opinion here. There are no magic bullets. +If we supply something of great value to people, it is bound to to +reflect the acquisition of a relatively rare expertise, which will in +turn require the investment of time. Quick items performed at the +surface level can be done by anybody, and hence are of a lesser value. +I agree with you of course correct in your statement that it will be a +challenge to find people to make this commitment. I think we +nonetheless have to keep this goal in our sights if we hope anyone to +take open axiom seriously. And once they do, finding the people will +be a lot easier. + +> > If someone can suggest a good, high priority, somewhat +> > manageable task, I'm willing to do my part. +> > +> +> I am not sure what you have in mind but just to get started, +> since you did raise the issue of Reduce licensing in a +> previous message, may be you would like to try making a +> modification to one or more pages on MathAction to reflect +> this situation with Reduce? If you have questions about how +> to proceed with using the MathAction wiki interface, then +> I would be very glad to help - or perhaps Martin also. +> + +Thanks! I'm going to try to fix the symbol issue first if that is +ok. I would like to help with the site time permitting thereafter. + +\start +Date: Wed, 22 Sep 2004 09:47:33 -0400 +From: Tim Daly +To: camm@enhanced.com +Subject: Re: [Axiom-developer] RE: mathaction +Cc: bill.page1@sympatico.ca, dmentre@linux-france.org + +Camm, + +You should check out the Doyen effort. We've been discussing the +problem of building a scientific (more than math) platform based +on a collection of technologies (open source science, live CDs, +mathaction, etc). The initial discussion is at: + +http://page.axiom-developer.org/zope/mathaction/doyen + +\start +Date: Wed, 22 Sep 2004 17:08:07 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: conditionally defined functions + +Dear William, + +(I stopped copying to Bronstein and Hemmecke, since I suspect that the +following is too Axiom specific) + + > As to why I think if it works, it works wrongly: + > Try this: + > + > (1) -> )clear all + > (1) -> y:=3*x + 1 + > (1) 3x+1 Type: Polynomial Integer + > (2) -> z: UP(x, POLY INT) + > Type: Void + > (3) -> z:=3*x + 1 + > (3) 3x+1 Type: UnivariatePolynomial(x,Polynomial Integer) + > (4) -> t:=variables(y) + > (4) [x] Type: List Symbol + > (5) -> s:=variables(z) + > (5) ["?"] Type: List SingletonAsOrderedSet + > (6) sx:=s.1 + > (6) "?" Type: SingletonAsOrderedSet + > (7) member?(sx,t) + > (7) true Type: Boolean + > + > Is this correct? How? + > + > (8) sxx:=convert(sx) + > (8) ? Type: Symbol + > (9) tx := t.1 + > (9) x Type: Symbol + > (10) g:Boolean:= sxx=tx + > (10) false Type: Boolean + > (11) g:= sx = tx + > (11) true Type: Boolean + > + > How do you explain (11) that two items of different type can be equal, and (10), + > after conversion to the same type, are not? + +(6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1 + + (6) x= x + Type: Equation UnivariatePolynomial(x,Integer) + +The reason is that the interpreter thinks (quite rightly) that + +sx = tx has Type: Equation UnivariatePolynomial(x,Integer) + +and (create()$SAOS)::UP(x,INT) returns x. + +Thus the only thing which I'd object to is the output of (6) and (8). + +I started a discussion of (6) in + +http://page.axiom-developer.org/zope/mathaction/DesignIssues + + > William + > --- + > + > PS: + > > > Remember that the compiler distinguishes these already. So the condition + > > + > > > member?(x, variables(r)) + > > + > > > would always return false. + > > + > > No, it does not. (at least not in the tests I ran) + > + > I was writing based on a similar situation we discussed on June 12: + > + > ---quote from June 12 + > So is this a bug? I am not sure, it may be good that the interpreter caught the + > ambiguity and it may be bad that the compiler does not. The compiler actually + > knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is + > used, but we (human) will get all confused. Try: + > + > )abb package TEST Test + > + > Test():Target==Implementation where + > EXPR ==> Expression + > POLY ==> Polynomial + > INT ==> Integer + > Target ==> with + > f1: () -> EXPR POLY INT + > f2: () -> POLY INT + > f3: () -> EXPR POLY INT + > f4: () -> EXPR POLY INT + > Implementation ==> add + > a:=new()$Symbol + > b:=a ::EXPR POLY INT + > c:=a :: POLY INT + > f1()==b + > f2()==c + > f3()== (c*b)/b + > f4()== f3()/b + > + > Note that if you check the signature of /, the compiler "knows" it is legally + > used and the answer for f4() is c/b, not 1 (which should be the case + > mathematically). + > ---end of quote + > + > I have not tried to replace EXPR by UP(x, ...) in Test(). Perhaps they behave + > differently + +Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be +forbidden, since it is not clear where the variables belong. + +On the other hand, it is easy to clarify the semantics of types like +UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this +domain. I don't think that there is another way to make sense of such a +domain. That's the reason for the question I started with, in fact. + +So, let's return there: + +> > > So, in more general terms, here's my question: +> > > +> > > Suppose you have a category A, taking as parameter a domain P and providing an +> > > operation f: % -> P. Furthermore, you have a category (or a domain, a package) +> > > B, taking as parameter a domain Q. Now you want to achieve the following: +> > > +> > > If Q is a domain in A, provide a function g: % -> P, using f. +> > > +> > > Of course, it is not possible to provide P as a parameter of B, since B should +> > > also be defined for Q's that are not domains in A... +> > +> > The way to handle this is to create a special version of B, which takes a domain +> > in A as parameter, together with parameters needed for A and construct the +> > special version using the general one. This is ok because the compiler can +> > handle dynamic signature on the category/domain constructor level. +> > +> > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P } +> > +> > You can then add the function g without a problem. The moral is: Don't Ask, Just +> > Tell. +> +> Great! gonna try this! + +Well, I thought a little about this, but it seems that I cannot apply it to the +problem at hand. + +I'll note my thoughts on mathaction. + +\start +Date: Wed, 22 Sep 2004 15:20:14 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: conditionally defined functions + +Martin Rubey wrote: +> +> Dear William, +> > As to why I think if it works, it works wrongly: +> > Try this: +> > +> > (1) -> )clear all +> > (1) -> y:=3*x + 1 +> > (1) 3x+1 Type: Polynomial Integer +> > (2) -> z: UP(x, POLY INT) +> > Type: Void +> > (3) -> z:=3*x + 1 +> > (3) 3x+1 Type: UnivariatePolynomial(x,Polynomial Integer) +> > (4) -> t:=variables(y) +> > (4) [x] Type: List Symbol +> > (5) -> s:=variables(z) +> > (5) ["?"] Type: List SingletonAsOrderedSet +> > (6) sx:=s.1 +> > (6) "?" Type: SingletonAsOrderedSet +> > (7) member?(sx,t) +> > (7) true Type: Boolean +> > +> > Is this correct? How? +> > +> > (8) sxx:=convert(sx) +> > (8) ? Type: Symbol +> > (9) tx := t.1 +> > (9) x Type: Symbol +> > (10) g:Boolean:= sxx=tx +> > (10) false Type: Boolean +> > (11) g:= sx = tx +> > (11) true Type: Boolean +> > +> > How do you explain (11) that two items of different type can be equal, and (10), +> > after conversion to the same type, are not? +> +> (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1 +> +> (6) x= x +> Type: Equation UnivariatePolynomial(x,Integer) +> +> The reason is that the interpreter thinks (quite rightly) that + +?? + +> sx = tx has Type: Equation UnivariatePolynomial(x,Integer) +> +> and (create()$SAOS)::UP(x,INT) returns x. + +I know that! You should note in (10) I had declared g to be Boolean! In your +(6), yes, that is an Equation. Unfortunately, a Boolean MUST be declared before +assigning it a value. So your (6) should begin with test:Boolean = (variables +...). If what you think is that Axiom coerced (sx = tx) from Equation to +Boolean, then there is something very wrong since no one will know how to test +equality of two expressions. Perhaps the "=" operator should not be overloaded +this way. + +Moreover, Equation (and equality) should only be formed (called) if both sides +come from the same domain. ANY needed coercion should be done by the user. The +interpreter should NEVER automatically coerce the two sides to a common domain +-- I know this is difficult to fix, but an automatic coercion means mistakes on +types will not be caught. I realize that this automatic coercion is done for +common arithmetic operators like + in the interpreter but somehow I think +equality testing should be handled differently. + +Although I have not yet tried the above in the compiler, I believe that (10) +should give false, and (11) should be flagged because of type error. + +In (11), sx has type SingletonAsOrderedSet and tx has type Symbol. If sx=tx is +to be considered as an Equation, then an intuitive common domain should be +Symbol (using [convert] as in (8). To use [create] and not [convert] to lift an +SAOS to UP(x,INT) AND do the same for tx is way too imaginative for my intuition +if indeed that is what the interpreter does. + +> +> Thus the only thing which I'd object to is the output of (6) and (8). + +I have no objection to either (6) or (8). They are what I expected (from the +compiler viewpoint). I don't think UP was designed for the kind of rearrangement +you have in mind. + +> +> I started a discussion of (6) in +> +> http://page.axiom-developer.org/zope/mathaction/DesignIssues + +Will take a look later. Pressed for time to prepare class (I do have to teach!) + +> Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be +> forbidden, since it is not clear where the variables belong. + +AGREED! + +> On the other hand, it is easy to clarify the semantics of types like +> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this +> domain. I don't think that there is another way to make sense of such a +> domain. That's the reason for the question I started with, in fact. + +But so should UP(x, EXPR INT). You are inconsistent in the application of your +logic: according to the above, POLY EXPR INT is equally fine (just that there +may be more variables). But back to UP. EXPR INT can also contain polynomials in +x in addition to 1/x, 2^x, sin x. In fact: + +(15) sin(x)*x + sin(x)*x^2 + (x^2 + x)sin(x) Type Expression Integer + +This regrouping is automatic. If you rather prefer the input form, which +separates the powers of x, I think you should use a package to provide the +conversion WITHIN EXPR INT and where you also change the outputform. In Axiom, +the domains correspond to mathematical objects, and to have x in BOTH EXPR INT +and UP(x, EXPR INT) is not right since mathematically, the two are the same, as +underlying set and all operations on it. Indeed, any operation in UP(x, EXPR +INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need +to reconvert UP(x, EXPR INT) back to EXPR INT --- a difficult dilemma because +you now have to consider UP(x,EXPR INT) elements as ground elements (ground? may +fail, in general, though not here), perform the operation, and reformating back +to UP(x, EXPR INT). This really shows that the only thing you can achieve is +reformatting output and so it should be done that way. + +If you are not mixing x in both places, then something like UP(y, +EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is +constructed. + +There is a general philosophy, I think, in developing Axiom algebra code: if +some previously established domain lacks certain functionality, you create a new +domain or package to add them, not modify the original (except for bugs). I +think this is a well-thought out strategy to let Axiom grow without breaking old +code. + +\start +Date: Thu, 23 Sep 2004 03:34:03 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Mixing up variables: (was Re: conditionally defined functions) + +Hi Martin: + +You wrote (referring to my axiom code (10) to (11) below): +> > As to why I think if it works, it works wrongly: +> > Try this: +> > +> > (1) -> )clear all +> > (1) -> y:=3*x + 1 +> > (1) 3x+1 Type: Polynomial Integer +> > (2) -> z: UP(x, POLY INT) +> > Type: Void +> > (3) -> z:=3*x + 1 +> > (3) 3x+1 Type: UnivariatePolynomial(x,Polynomial Integer) +> > (4) -> t:=variables(y) +> > (4) [x] Type: List Symbol +> > (5) -> s:=variables(z) +> > (5) ["?"] Type: List SingletonAsOrderedSet +> > (6) sx:=s.1 +> > (6) "?" Type: SingletonAsOrderedSet +> > (7) member?(sx,t) +> > (7) true Type: Boolean +> > +> > Is this correct? How? +> > +> > (8) sxx:=convert(sx) +> > (8) ? Type: Symbol +> > (9) tx := t.1 +> > (9) x Type: Symbol +> > (10) g:Boolean:= sxx=tx +> > (10) false Type: Boolean +> > (11) g:= sx = tx +> > (11) true Type: Boolean +> > +> > How do you explain (11) that two items of different type can be equal, and (10), +> > after conversion to the same type, are not? +> +> (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1 +> +> (6) x= x +> Type: Equation UnivariatePolynomial(x,Integer) +> + +> The reason is that the interpreter thinks (quite rightly) that +> +> sx = tx has Type: Equation UnivariatePolynomial(x,Integer) +> +> and (create()$SAOS)::UP(x,INT) returns x. +> + +Unfortunately, this does not correspond to what I find. I set )set mess bot on +and found that this is not how the interpreter works. Rather it goes this way: + +sx which is in SAOS, is first coerced into POLY INT then to UP(x, POLY INT), +then "lifted" to UP(x, INT). tx (in Symbol) is also lifted to UP(x, INT) and +then the two are equality tested, returning true. At no time is Equation +involved. + +I then tested this (see attachment at end) and as you can see, it gives a +contradiction to transitivity! (Unfortunately, the contradiction is the only +correct answer!) + +So I think this is a bug in the interpreter. Instead of trying to be helpful to +search for an "=" that returns Boolean for the types given on the lhs and rhs, +it should simply first check whether the two sides have the same type and then +whether equality testing "=" exist for that type. No automatic coercion should +be done. + +> I started a discussion of (6) in +> +> http://page.axiom-developer.org/zope/mathaction/DesignIssues + +I am not familiar with using this resource, so I have not posted my reply there. +Please feel free to post this if you like. + +On that page, you wrote: +> Maybe it would be possible to somehow query functions provided by packages: after all there is a function +> variables:FRAC POLY INT->LIST SYMBOL, only, it is not provided by FRAC POLY INT but by RF INT... + +This is correct. As you have pointed out, the reason is very simple. FRAC is a +general constructor for quotient field of an integral domain, which need not +have [variables]. Perhaps ideally, this should be included with something like: + + if R has POLYCAT(...) or any other similar categories then + variables: FRAC R -> List Symbol + +but unfortunately, this is not easy since the ... in POLYCAT varies with the way +R is constructed. This is the reason why it is put in RF. This may fall under +the "Don't ask, just tell" policy :-). Note that indeed, FRAC UP(x, INT) also +has no [variables] because no one has implemented a UnivariateRationalFunction +package or domain. Similarly for FRAC DMP(...) and others. Because of the +generality that Axiom constructors have, it is very difficult to ask about the +constructors --- unless, for each domain constructor, we provide the functions +that return the parameters and the constructor --- but even that is no simple +thing to do ... lots of catch-22 situations. The safest way is to implement this +in an auxilliary package where one has more control over the parameters of the +polynomial domain. I believe this is the correct design. + +You suggested: + +> to move the +> operation variables from RF and POLYCATQ to QFCAT : +> +> if S has variables: S -> List Symbol then +> variables: % -> List Symbol +> variables f == +> mymerge(variables(numer(f)), variables(denom(f))) + +As you pointed out, this is not general enough, because there are other domains +with [variables] with the more general codomain LV: List OrderedSet. Ideally, +perhaps we can try: + + if S has variables: S -> List V where V:OrderedSet then + variables: % -> List V + variables f == + mymerge(variables(numer(f)), variables(denom(f))) + +However, I am a bit worried with other integral domains that satisfy the +condition but has nothing to do with indeterminates. Fortunately, there are no +such domains in Axiom at present. So this may be better than the + + if R has POLYCAT(...) then + +construct, testing for existence of a function is ok. + +> and add the following to UP and MPOLY : +> +> if R has variables: R -> List Symbol then +> coerce(r:R):% == +> if member?(x, variables(r)) then +> error "coefficient contains variable" +> else coerce(r)$Rep + +If this coercion is done for UP, MPOLY, then it should also be done for any of +the domains in POLYCAT, since there is now no reason not to have say DMP([x,y], +POLY INT). Any tower construction would be allowed. + +There is one problem with the + + member?(x, variables(r)) + +condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I +would think that variables(r) would have x as a member, and so you would receive +the error message when coerce is called. But according to your intention, you +may still want to coerce r (that is, in my terminology, reformat r) to look like +UP(x, EXPR INT). + +BTW, I also just found that you can simply [pun intended] coerce without any new +code to do what you want: + +)clear all +q:EXPR INT:=x*sin(x) +p:=q::UP(x, EXPR INT) +degree p +coefficient(p,1) + +However, this is not fullproof: +q:=q^2+q+cos(x) +p:=q::UP(x, EXPR INT) -- works fine degree p is 2 +q:= p/x +p:=q::UP(x, EXPR INT) +degree p -- no good degree p is 0 + +This suggests that the success to such reformatting depends very much on the +data representation. + +pn:=numer p +pd:=denom p +p:= (pn::UP(x,EXPR INT))/(pd::UP(x,EXPR INT)) +degree p -- no good, degree is 2 + +More trouble. This is all because the x wears two hats and Axiom does not know +how to simplify them or identify them. Here they were wrongly distinguished. In +the session below, they were wrongly identified. + + +William +--- Transcript from Axiom session +Starts dribbling to martin2 (Fri Sept 22 22:24:28 2004) + +G82322 (4) -> )clear all + All user variables and function definitions have been cleared. +G82322 (1) -> z:UP(x, POLY INT):=3*x+1 + + (1) 3x + 1 + Type: UnivariatePolynomial(x,Polynomial Integer) +G82322 (2) -> y:POLY INT:=3*x+1 + + (2) 3x + 1 + Type: Polynomial Integer +G82322 (3) -> upx:=variables(z).1 + + (3) "?" + Type: SingletonAsOrderedSet +G82322 (4) -> px:=variables(y).1 + + (4) x + Type: Symbol +G82322 (5) -> )set mess bot on +G82322 (5) -> g:Boolean:=(upx = px) + + Function Selection for = + Arguments: (SAOS,SYMBOL) + Target type: BOOLEAN + -> no function = found for arguments (SAOS,SYMBOL) + + Function Selection for = + Arguments: (SAOS,OVAR [x]) + Target type: BOOLEAN + -> no function = found for arguments (SAOS,OVAR [x]) + + Function Selection for = + Arguments: (SAOS,POLY INT) + Target type: BOOLEAN + -> no function = found for arguments (SAOS,POLY INT) + + Function Selection for map by coercion facility (map) + Arguments: ((POLY INT -> INT),UP(x,POLY INT)) + Target type: UP(x,INT) + + [1] signature: ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT) + implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) ( + +Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from + +UPOLYC2(POLY INT,UP(x,POLY INT),INT,UP(x,INT)) + [2] signature: ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT) + implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) ( + +Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UP2( + +x,POLY INT,x,INT) + + + Function Selection for = + Arguments: (SAOS,UP(x,INT)) + Target type: BOOLEAN + + [1] signature: (UP(x,INT),UP(x,INT)) -> BOOLEAN + implemented: slot (Boolean)$$ from UP(x,INT) + + + (5) true + Type: Boolean + +G82322 (6) -> --So Symbol was coerced first to POLY INT then to UP(x, POLY INT), +then polylifted to UP(x, INT), and SAOS was also lifted to UP(x, INT) and then +the equality test from UP(x,INT) is used. Never in here ever was Equation +involved. This result is wrong since I can change x to another symbol and the +result would be the same: + +G82322 (6) -> )set mess bot off +G82322 (6) -> w:POLY INT:= 3*t+1 + + (6) 3t + 1 + Type: Polynomial Integer + +G82322 (7) -> pt:=variables(w).1 + + (7) t + Type: Symbol +G82322 (8) -> )set mess bot on + + +G82322 (8) -> g:=upx = pt + + Function Selection for = + Arguments: (SAOS,SYMBOL) + Target type: BOOLEAN + -> no function = found for arguments (SAOS,SYMBOL) + + Function Selection for = + Arguments: (SAOS,OVAR [t]) + Target type: BOOLEAN + -> no appropriate = found in SingletonAsOrderedSet + -> no appropriate = found in OrderedVariableList [t] + -> no appropriate = found in Symbol + -> no appropriate = found in Boolean + -> no appropriate = found in SingletonAsOrderedSet + -> no appropriate = found in OrderedVariableList [t] + -> no appropriate = found in Symbol + -> no appropriate = found in Boolean + + Modemaps from Associated Packages + no modemaps + + Remaining General Modemaps + [1] (FortranScalarType,FortranScalarType) -> Boolean from + FortranScalarType + [2] (D1,D1) -> Equation D1 from Equation D1 if D1 has TYPE + [3] (D,D) -> Boolean from D if D has BASTYPE + -> no function = found for arguments (SAOS,OVAR [t]) + + Function Selection for = + Arguments: (SAOS,POLY INT) + Target type: BOOLEAN + -> no function = found for arguments (SAOS,POLY INT) + + Function Selection for map by coercion facility (map) + Arguments: ((POLY INT -> INT),UP(t,POLY INT)) + Target type: UP(t,INT) + -> no appropriate map found in UnivariatePolynomial(t,Polynomial Integer) + -> no appropriate map found in UnivariatePolynomial(t,Integer) + -> no appropriate map found in Integer + -> no appropriate map found in Polynomial Integer + -> no appropriate map found in Integer + + Modemaps from Associated Packages + [1] ((D4 -> D5),D3) -> D1 + from UnivariatePolynomialCategoryFunctions2(D4,D3,D5,D1) + if D4 has RING and D5 has RING and D1 has UPOLYC D5 and D3 + has UPOLYC D4 + [2] ((D5 -> D7),UnivariatePolynomial(D4,D5)) -> UnivariatePolynomial + (D6,D7) + from UnivariatePolynomialFunctions2(D4,D5,D6,D7) + if D4: SYMBOL and D5 has RING and D7 has RING and D6: + SYMBOL + [3] ((D4 -> D5),SparseUnivariatePolynomial D4) -> + SparseUnivariatePolynomial D5 + from SparseUnivariatePolynomialFunctions2(D4,D5) + if D4 has RING and D5 has RING + + [1] signature: ((POLY INT -> INT),UP(t,POLY INT)) -> UP(t,INT) + implemented: slot (UnivariatePolynomial t (Integer))(Mapping (Integer) +(Polynomial (Integer)))(UnivariatePolynomial t (Polynomial (Integer))) from +UPOLYC2(POLY INT,UP(t,POLY INT,INT,UP(t,INT)) + [2] signature: ((POLY INT -> INT),UP(t,POLY INT)) -> UP(t,INT) + implemented: slot (UnivariatePolynomial t (Integer))(Mapping (Integer) +(Polynomial (Integer)))(UnivariatePolynomial t (Polynomial (Integer))) from +UP2(t,POLY INT,t,INT) + + + Function Selection for = + Arguments: (SAOS,UP(t,INT)) + Target type: BOOLEAN + -> no appropriate = found in SingletonAsOrderedSet + -> no appropriate = found in UnivariatePolynomial(t,Integer) + -> no appropriate = found in Boolean + -> no appropriate = found in SingletonAsOrderedSet + -> no appropriate = found in Boolean + + [1] signature: (UP(t,INT),UP(t,INT)) -> BOOLEAN + implemented: slot (Boolean)$$ from UP(t,INT) + + + (8) true + Type: Boolean + +G82322 (9) -> -- this is also wrong. + +G82322 (9) -> )set mess bot off + +G82322 (9) -> g:= (px = pt) + + (9) false + Type: Boolean + +G82322 (10) -> -- This is correct. If (5) and (8) were correct, it should follow +that (9) returns true by transivity: upx = px, upx = pt, hence px = pt. + +G82322 (10) -> g:= (px::UP(x,INT) = pt::UP(t, INT)) + + (10) false + Type: Boolean +G82322 (11) -> -- This is correct; the interpreter puts everything into UP(x, +UP(t, INT)). + +G82322 (11) -> )spool + +Finished dribbling to martin2. + +\start +Date: Thu, 23 Sep 2004 10:59:17 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: conditionally defined functions + +Dear William, + +William Sit writes: + > > > (1) -> )clear all + > > > (1) -> y:=3*x + 1 + > > > (1) 3x+1 Type: Polynomial Integer + > > > (2) -> z: UP(x, POLY INT) + > > > Type: Void + > > > (3) -> z:=3*x + 1 + > > > (3) 3x+1 Type: UnivariatePolynomial(x,Polynomial Integer) + > > > (4) -> t:=variables(y) + > > > (4) [x] Type: List Symbol + > > > (5) -> s:=variables(z) + > > > (5) ["?"] Type: List SingletonAsOrderedSet + > > > (6) sx:=s.1 + > > > (6) "?" Type: SingletonAsOrderedSet + > > > (7) member?(sx,t) + > > > (7) true Type: Boolean + > > > + > > > Is this correct? How? + > > > + > > > (8) sxx:=convert(sx) + > > > (8) ? Type: Symbol + > > > (9) tx := t.1 + > > > (9) x Type: Symbol + > > > (10) g:Boolean:= sxx=tx + > > > (10) false Type: Boolean + > > > (11) g:= sx = tx + > > > (11) true Type: Boolean + > > > + > > > How do you explain (11) that two items of different type can be equal, and (10), + > > > after conversion to the same type, are not? + > > + > > (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1 + > > + > > (6) x= x + > > Type: Equation UnivariatePolynomial(x,Integer) + > > + > > The reason is that the interpreter thinks (quite rightly) that + > + > ?? + +What do you mean with ?? ? + + > > sx = tx has Type: Equation UnivariatePolynomial(x,Integer) + > > + > > and (create()$SAOS)::UP(x,INT) returns x. + > + > I know that! + +Sorry, I didn't know it. I didn't mean to be "belehrend". (don't know the +English equivalent. "instructive" doesn't catch the true meaning. It is +something between "instructive" and "squareheadish") + + > You should note in (10) I had declared g to be Boolean! In your + > (6), yes, that is an Equation. Unfortunately, a Boolean MUST be declared before + > assigning it a value. So your (6) should begin with test:Boolean = (variables + > ...). If what you think is that Axiom coerced (sx = tx) from Equation to + > Boolean, + +I think that Axiom coerced (sx = tx) from EQ UP(x, INT) to Boolean, yes. + +Here is the relevant part where axiom looks for the right types for the equation: + + Function Selection for equation + Arguments: (SAOS,SYMBOL) + -> no function equation found for arguments (SAOS,SYMBOL) + + Function Selection for equation + Arguments: (SAOS,OVAR [x]) + -> no function equation found for arguments (SAOS,OVAR [x]) + + Function Selection for equation + Arguments: (SAOS,POLY INT) + -> no function equation found for arguments (SAOS,POLY INT) + + Function Selection for map by coercion facility (map) + Arguments: ((POLY INT -> INT),UP(x,POLY INT)) + Target type: UP(x,INT) + + [1] signature: ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT) + implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UPOLYC2(POLY INT,UP(x,POLY INT),INT,UP(x,INT)) + [2] signature: ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT) + implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UP2(x,POLY INT,x,INT) + + + Function Selection for equation + Arguments: (SAOS,UP(x,INT)) + + [1] signature: (UP(x,INT),UP(x,INT)) -> EQ UP(x,INT) + implemented: slot $(UnivariatePolynomial x (Integer))(UnivariatePolynomial x (Integer)) from EQ UP(x,INT) + + > then there is something very wrong since no one will know how to test + > equality of two expressions. + +Well, in some cases it can be done, in particular for UP(x, INT). That is, +whenever there is a normalized form. I'm pretty sure I misunderstood you. Do +you mean the following: + +(25) -> (2^(2*x)=4^x)::Boolean + + (25) false + Type: Boolean + +I'm not too sure what to think of it. Probably there should be an attribute +telling whether a particular domain has such a normalized form. On the other +hand, we do want to have (x=x)::(EQ EXPR INT)::Boolean giving true, don't we? +Well, maybe not. I'm mainly thinking from the perspective of packages, and +there we don't. + + > Perhaps the "=" operator should not be overloaded this way. + > + > Moreover, Equation (and equality) should only be formed (called) if both sides + > come from the same domain. + +But in this case they do, don't they? + + > [...] + + > > Thus the only thing which I'd object to is the output of (6) and (8). + > + > I have no objection to either (6) or (8). They are what I expected (from the + > compiler viewpoint). I don't think UP was designed for the kind of rearrangement + > you have in mind. + +I think that create()$SAOS should not be coercible to Symbol. Again, this is +calling for trouble. Look: + +(1) -> r:=create()$SAOS + + (1) "?" + Type: SingletonAsOrderedSet +(2) -> s:=r::Symbol + + (2) ? + Type: Symbol +(3) -> s::SAOS + Loading /home/rubey/axiom/mnt/linux/algebra/UPMP.o for package + UnivariatePolynomialMultiplicationPackage + Loading /home/rubey/axiom/mnt/linux/algebra/UP.o for domain + UnivariatePolynomial + + (3) "?" + Type: SingletonAsOrderedSet +(4) -> t:=?::Symbol + + (4) ? + Type: Symbol +(5) -> t::SAOS + + >> System error: + Bind stack overflow. + +protected-symbol-warn called with (NIL) + +This should probably also go on + + > > http://page.axiom-developer.org/zope/mathaction/DesignIssues + +don't you think? + + > Will take a look later. Pressed for time to prepare class (I do have to teach!) + +Me too. Just starting in fact... + + > > Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be + > > forbidden, since it is not clear where the variables belong. + > + > AGREED! + > + > > On the other hand, it is easy to clarify the semantics of types like + > > UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this + > > domain. I don't think that there is another way to make sense of such a + > > domain. That's the reason for the question I started with, in fact. + > + > But so should UP(x, EXPR INT). You are inconsistent in the application of your + > logic: according to the above, POLY EXPR INT is equally fine (just that there + > may be more variables). + +In this sense, POLY EXPR INT would be the domain of Polynomials with +coefficients in EXPR INT that do not contain any variables. You are quite +right. In fact, thinking about it, this could be quite useful. At the moment, +there is no other way to accomodate coefficients like sin(2), is there? Also, +some time in the future, it may be possible to say +product(1/n^2,n=1..%infinity), which would also be an EXPR INT, I suspect. + + > [...] and to have x in BOTH EXPR INT and UP(x, EXPR INT) is not right since + > mathematically, the two are the same, as underlying set and all operations + > on it. + +Whether they are mathematically the same obviously depends on the meaning we +give them. Currently, I think, UP(x, EXPR INT) has no good meaning. + + > Indeed, any operation in UP(x, EXPR + > INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need + > to reconvert UP(x, EXPR INT) back to EXPR INT + +I don't follow. If you are talking about the current semantics - I'd say they +are broken. If you are talking about the semantics I propose(d), [past tense +means, that I'm not sure anymore whether the idea is a good one] +then multiplication by sin(x) would be forbidden, division would create a FRAC +UP(x, EXPR INT) and multiplication by x is OK. + + > If you are not mixing x in both places, then something like UP(y, + > EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is + > constructed. + +Yes. I'm inclined to think that this is the best way to go: create a domain +EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY +?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on... + + > There is a general philosophy, I think, in developing Axiom algebra code: if + > some previously established domain lacks certain functionality, you create a new + > domain or package to add them, not modify the original (except for bugs). I + > think this is a well-thought out strategy to let Axiom grow without breaking old + > code. + +I agree, if there remains a clear design. For example, I find the wealth of +polynomial domains and packages a little confusing: + +polycat.spad +poly.spad +newpoly.spad +rf.spad + +\start +Date: Thu, 23 Sep 2004 22:58:46 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Dear William, + +hope I'm not annoying you... + +William Sit writes: + + > I am again pressed for time, but many of your questions were answered in my + > previous email, which probably crossed with yours. + +yes indeed... + + > Unfortunately, this does not correspond to what I find. I set )set mess bot + > on and found that this is not how the interpreter works. Rather it goes this + > way: + +[...] + + > So Symbol was coerced first to POLY INT then to UP(x, POLY INT), then + > polylifted to UP(x, INT), and SAOS was also lifted to UP(x, INT) and then + > the equality test from UP(x,INT) is used. Never in here ever was +[the domain] + > Equation involved. + +You are quite right. My fault. + + > This result is wrong since I can change x to another symbol and the result + > would be the same: + +I'm not so sure about "wrong". One (not me...) could argue that the two +univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I (!) +would say that this behaviour should be reserved for SUPs. And indeed, axiom +does say that + +((x::UP(x, INT))=(t::UP(t, INT)))::Boolean + +is false. + + > I then tested this (see attachment at end) and as you can see, it gives a + > contradiction to transitivity! (Unfortunately, the contradiction is the only + > correct answer!) + + > So I think this is a bug in the interpreter. Instead of trying to be helpful + > to search for an "=" that returns Boolean for the types given on the lhs and + > rhs, it should simply first check whether the two sides have the same type + > and then whether equality testing "=" exist for that type. No automatic + > coercion should be done. + +I'm very unsure about this. Note that when you look at the corresponding EQ +types (if you do not coerce to Boolean), everything looks sane. I do understand +that the domain EQ is not involved when you do ask for a boolean immediately, +but I wouldn't hurry here. + + > > I started a discussion of (6) in + > > + > > http://page.axiom-developer.org/zope/mathaction/DesignIssues + > + > I am not familiar with using this resource, so I have not posted my reply + > there. Please feel free to post this if you like. + +I will update the page from time to time. I think that discussing all this via +mathaction would produce to much noise... + +------------------------------------------------------------------------------ + +It seems that there is a fundamental misunderstanding concerning my intention +with regards to the semantics of UP(x, POLY INT). You wrote + + > There is one problem with the + > + > member?(x, variables(r)) + > + > condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I + > would think that variables(r) would have x as a member, and so you would receive + > the error message when coerce is called. But according to your intention, you + > may still want to coerce r (that is, in my terminology, reformat r) to look like + > UP(x, EXPR INT). + +In fact, an error message is exactly what I'd like to see for +(1/x)::UP(x, EXPR INT). + +I try to get it right now: (It may be that my current position differs from +that I had some months ago, but it was constant in the last few weeks. Save I +made a mistake) + +For any polynomial (or series) domain that has a specified list of variables, I +want that axiom ensures that any coefficient of a member does not contain one +of these variables. Examples: + +(1/x)::UP(x, EXPR INT) produces an error +x*2^x::UP(x, EXPR INT) produces an error +(1/x)::UP(x, FRAC POLY INT) produces an error +(1/x)::UTS(FRAC POLY INT,x,0) produces an error + +however, for example + +x*2^y::UP(x, EXPR INT) is ok. + +More generally, the "outermost" domain "takes" all the variables: + +POLY EXPR INT would be the domain of polynomials with coefficients that do not +contain any variables. For example, + +(x*sin(2))::POLY EXPR INT would be ok +(x*sin(y))::POLY EXPR INT would produce an error. + +The domain EXPR POLY INT would be strictly the same as EXPR INT, I think. + +------------------------------------------------------------------------ + +However, currently this seems unachievable. At least I don't know how to do +it. Your suggestion to extend axiom to allow + + > Ideally, perhaps we can try: + > + > if S has variables: S -> List V where V:OrderedSet then + > variables: % -> List V + > variables f == + > mymerge(variables(numer(f)), variables(denom(f))) + +seems most appealing to me, although I don't think this could be done in the +near future. I read a bit about the "post-facto" extensions provided by aldor, +maybe they adress this problem too. I'm not sure that I've understood them well +enough, though. + +PS: In fact, I can think of a way to do it: provide a function +variables2: % -> List Any in POLYCAT that simply wraps up the function +variables:% -> List VarSet. + +Then I can provide a function variables2 in QFCAT. The only tricky part is that +I need the operation "<" from VarSet in QFCAT (for mymerge) and I don't know of +a *good* way to get it. I do know an ugly way: provide a function +(Any, Any)->Boolean in POLYCAT that wraps "<" from VarSet. + +Maybe there is a better way, but I'm tired now. + +------------------------------------------------------------------------ + +On the other hand, there is a completely different solution to the original +problem, i.e., providing a domain like UP(x, EXPR INT) with good semantics: + +> > Yes. I'm inclined to think that this is the best way to go: create a domain +> > EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY +> > ?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on... +> +> Good. I am glad we are beginning to agree. However, your point of creating +> something like sin(2) x somewhere should be considered carefully. + +sin(2)*x would be in UP(x, EXPR([], INT)). Did you mean that? + +------------------------------------------------------------------------- + +just for the record: + +> > I agree, if there remains a clear design. For example, I find the wealth of +> > polynomial domains and packages a little confusing: +> > +> > polycat.spad +> > poly.spad +> > newpoly.spad +> > rf.spad + gdpoly.spad + multpoly.spad + prtition.spad + xlpoly.spad + xpoly.spad + wtpol.spad + ... + +-------------------------------------------------------------------------- + +> I am more confused than you are. You have taught me to look into things I never +> knew. See what I mean that 70% of time in Axiom is in coercion? If I weren't +> conservative, I'll say 90%. That is the curse of strong typing. + +You are flattering me... + +\start +Date: Thu, 23 Sep 2004 22:26:45 -0400 +From: "Bill Page" +To: +Subject: RE: [Axiom-developer] Re: Mixing up variables: (was Re: conditionallydefined functions) + +On Thursday, September 23, 2004 6:59 PM Martin Rubey wrote: +> +> > > I started a discussion of (6) in +> > > +> > > http://page.axiom-developer.org/zope/mathaction/DesignIssues +> > +> > [William Sit wrote:] +> > I am not familiar with using this resource, so I have not +> > posted my reply there. Please feel free to post this if you +> > like. +> +> I will update the page from time to time. I think that discussing +> all this via mathaction would produce to much noise... +> + + :( + +While I am enjoying reading (and trying to understand) this +exchange between Martin and William, I do think that it would +be useful if some of the examples being discussed were included +in MathAction, linked to the [DesignIssues] page that Martin +created. I don't understand, Martin, when you say that discussing +this via MathAction would "produce too much noise". I think it +would be less "noise". Perhaps the best reason for carrying on +the discussion here by email where a large number of people are +already subscribed is that one can be sure that most people are +actually reading it. If you did this via MathAction - which you +*can* do just as easily as you are doing here, since MathAction +also functions like a mailing list - the only people who would +receive emails are those who specifically subscribed to that +page (or to MathAction as a whole), but a record of the discuss +including your example calculations would be accessible to +everyone via the web. Yes, of course there is the mailing +list archive which is accessible via the web anyway, so perhaps +that is not really an issue. + +The volume of discussion here on the Axiom mailing lists is +not really that high, so I wonder if it might not be best to +simply subscribe mathaction@axiom-developer.org (the MathAction +mail-in email address) to axiom-developer mailing list. Then +postings to the axiom-developer mailing list would automatically +be archived on the [Axiom-developer] page on MathAction. As time +permits we could then "weed" and reorganize it for longer term + +\start +Date: Fri, 24 Sep 2004 10:13:54 +0000 +From: Martin Rubey +To: "Bill Page" +Subject: RE: [Axiom-developer] Re: Mixing up variables: (was Re: + +Dear Bill, + +although I really (really, really) like mathaction and I'm impatiently awaiting +the point were the documentation effort gets started there, I do believe that +it cannot serve as a replacement for the mailing list. On the other hand, you +do have a point regarding "keeping a record of the discussion". Thus, I promise +to try the following in the future: + +As soon as I realize that I can somehow "classify" a discussion, I'll create a +page and continue the discussion there. (The prerequisite is that the +discussion gets its "own" page. I will detail this below.) + +On the other hand, I do *not* like the idea of having *all* of axiom-developer +copied to mathaction. I cannot really say why, it is a (probably completely +irrational) feeling. Maybe it does have to do with some sort of privacy. + +By the way, there is one big difference in style regarding email exchange and +mathaction exchange: When I reply to an email, I *always* quote the text I +comment on. Since this produces a lot of text, I anticipate that the mathaction +page will rapidly become difficult to read. Thus, it will be necessary, that +the discussion topic has its own page. Then all the replies will be at the +bottom of the page and won't disturb the "expository" part too much. + +There is another important detail: I think it is *very* important to summarize +the discussion from time to time, and for a "clean" look, I'd like to remove +the exchange then. So, unless the discussion is copied (CC'd) to one of the +mailing lists, it will be lost. + +It remains to say thank you once more for MathAction, + +Martin + +PS: How're pamphlets going? + +\start +Date: Fri, 24 Sep 2004 10:27:43 +0000 +From: Martin Rubey +To: Martin Rubey +Subject: [Axiom-developer] speakerscorner +Cc: Bill Page + +Hmmm, another detail: + +Martin Rubey writes: + > + > There is another important detail: I think it is *very* important to summarize + > the discussion from time to time, and for a "clean" look, I'd like to remove + > the exchange then. So, unless the discussion is copied (CC'd) to one of the + > mailing lists, it will be lost. + +If we do this, I'll get each message roughly four times: + +once because I regularly forget to erase my name from the CC list, +twice because it goes to axiom-developer or the like +thrice because the page axiom-developer on mathaction is changed +four times because the specific discussion page is changed. + +(But I do want to subscribe to mathaction as a whole...) + +\start +Date: Fri, 24 Sep 2004 11:51:37 -0400 +From: "Bill Page" +To: "'Martin Rubey'" +Subject: RE: [Axiom-developer] Re: Mixing up variables: (was Re: conditionallydefined functions) + +On Friday, September 24, 2004 6:14 AM Martin Rubey wrote: +> +> although I really (really, really) like mathaction and I'm +> impatiently awaiting the point were the documentation effort +> gets started there, + +I hear you. + +> I do believe that it cannot serve as a replacement for the +> mailing list. + +But it does function (in principle) in exactly the same way, +don't you agree? + +In any case, since you and I seem to be the only ones who +really care about this right now and there are some technical +limitations that make it less than ideal, I think I will take +your advice and not link MathAction and the axiom-developer +mailing list at this time. In the mean time, provided that one +is also subscribed to MathAction, then simply including + + mathaction@axiom-developer.org + +in the Cc list will send a copy to the [Axiom-developer] page +on MathAction. If the sender is not subscribed, then currently +the ZWiki mailin procedure will ignore the incoming mail. This +is configurable security policy. If we wanted we could relax this +restriction so that any email sent by anyone to the above address +would be automatically archived somewhere on MathAction (attached +to wiki page [xxx] based on [xxx] in the subject line if present). + +> On the other hand, you do have a point regarding "keeping a +> record of the discussion". Thus, I promise to try the following +> in the future: +> +> As soon as I realize that I can somehow "classify" a discussion, +> I'll create a page and continue the discussion there. (The +> prerequisite is that the discussion gets its "own" page. +> I will detail this below.) + +I didn't see quite enough details below, but I think this might +be hard to achieve. Right now it is only possible for MathAction +to direct a message to a specific page in the wiki based on the +occurrence of [xxxxx] in the subject line. Messages distributed +via the axiom-developer mailing list automatically have +[Axiom-developer] added to the subject line and so if mathaction +is included in the mailing list (either by subscription or via +Cc, as in the case of this and a few previous messages), it will +only attach the email as a comment to the page [Axiom-developer]. +It is only a coincidence that [xxxx] is used in both systems, +albeit for different purposes. + +> +> On the other hand, I do *not* like the idea of having *all* +> of axiom-developer copied to mathaction. I cannot really say why, +> it is a (probably completely irrational) feeling. Maybe it does +> have to do with some sort of privacy. +> + +Well, as a physicist it seems that I am often in the position of +having to remind myself that it is user *perceptions* and not +facts that determine how users behave. :) You realize, of course +that email via the axiom-developer mailing list is also archived +and (quite) easily accessible via the web even for people who are +not subscribed to axiom-developer? In MathAction the situation +does seem to emphasize the web interface first with the ability to +subscribe and act like a mailing list as a secondary feature. But +really they are essential the same. + +Lately I seem to be dealing more and more with the fact that +people view interaction via the web (as in the case of a wiki) +quite differently than they view material that is delivered and +distributed via email. This currently seems to be a major +obstacle to implementing active collaboration via the web. :( + +> By the way, there is one big difference in style regarding +> email exchange and mathaction exchange: When I reply to an +> email, I *always* quote the text I comment on. Since this +> produces a lot of text, I anticipate that the mathaction +> page will rapidly become difficult to read. Thus, it will be +> necessary, that the discussion topic has its own page. Then +> all the replies will be at the bottom of the page and won't +> disturb the "expository" part too much. + +As I mentioned above I don't yet know how to achieve this +technically. Perhaps a change to the way ZWiki directs incoming +email would be required. In the mean time to achieve what you +want would require the active attention of someone to edit +the [Axiom-developer] wiki page. + +> +> There is another important detail: I think it is *very* +> important to summarize the discussion from time to time, +> and for a "clean" look, I'd like to remove the exchange then. +> So, unless the discussion is copied (CC'd) to one of the +> mailing lists, it will be lost. +> + +Well, the general idea would be that the axiom-developer +mail list *also* be subscribed to the MathAction wiki. But +without some careful changes to the ZWiki mailin procedure, +this would create a disastrous email loop! Right now we can +have mathaction subscribed to axiom-developer *or* axiom- +developer subscribed to MathAction but not both. + +> It remains to say thank you once more for MathAction, +> +> Martin +> +> PS: How're pamphlets going? +> + +Maybe later this weekend on test.axiom-developer.org + +Later on Friday, September 24, 2004 6:28 AM Martin Rubey +wrote: +> +> Hmmm, another detail: +> +> Martin Rubey writes: +> > +> > There is another important detail: I think it is *very* +> > important to summarize the discussion from time to time, +> > and for a "clean" look, I'd like to remove the exchange +> > then. So, unless the discussion is copied (CC'd) to one +> > of the mailing lists, it will be lost. +> +> If we do this, I'll get each message roughly four times: +> +> once because I regularly forget to erase my name from the +> CC list, twice because it goes to axiom-developer or the like +> thrice because the page axiom-developer on mathaction is changed +> four times because the specific discussion page is changed. +> +> (But I do want to subscribe to mathaction as a whole...) +> + +I see this same problem. + +I suppose that *if* we did link MathAction directly to +axiom-developer mailing list, then it would make sense to +subscribe to only MathAction, and for most users specifically +the [Axiom-developer] page, since everything would be directed +there. Ideally there would be a way for topics to automatically +branch off to their own wiki pages and some way to manage the +subscriptions. + +But my summary would be this: "If it ain't broke, let's try +to avoid fixing it ..." :) We will leave things as they are +now for the time being. + +\start +Date: Fri, 24 Sep 2004 18:30:49 +0000 +From: Martin Rubey +To: "Bill Page" +Subject: RE: [Axiom-developer] Re: Mixing up variables: (was Re: conditionallydefined functions) + +Bill Page writes: + + > Well, as a physicist it seems that I am often in the position of having to + > remind myself that it is user *perceptions* and not facts that determine how + > users behave. :) + +Yes indeed. And experience tells me that mathematicians in general and me in +particular are especially irrational beings... + + > Lately I seem to be dealing more and more with the fact that people view + > interaction via the web (as in the case of a wiki) quite differently than + > they view material that is delivered and distributed via email. This + > currently seems to be a major obstacle to implementing active collaboration + > via the web. :( + +I would regard email exchange as part of the web. Email and MathAction however +differ (for me) in one important point: I read email using emacs, and I browse +MathAction using Konqueror. Very different feeling! + +It seems that we both think that MathAction should get a little more attention. +Probably it would be good indeed to notify the axiom mailing lists when major +changes have been done to MathAction. I think I'll volonteer. + + > > PS: How're pamphlets going? + > + > Maybe later this weekend on test.axiom-developer.org + +Yeah, yeah, yeah! If you weren't that far away physically I'd bring you some +chocolate... + +\start +Date: Fri, 24 Sep 2004 10:05:51 -0700 +From: Bob McElrath +To: Bill Page +Subject: Re: [Axiom-developer] Re: Mixing up variables: (was Re: conditionallydefined functions) + +Bill Page [bill.page1@sympatico.ca] wrote: +> Well, as a physicist it seems that I am often in the position of +> having to remind myself that it is user *perceptions* and not +> facts that determine how users behave. :) You realize, of course +> that email via the axiom-developer mailing list is also archived +> and (quite) easily accessible via the web even for people who are +> not subscribed to axiom-developer? In MathAction the situation +> does seem to emphasize the web interface first with the ability to +> subscribe and act like a mailing list as a secondary feature. But +> really they are essential the same. +> +> Lately I seem to be dealing more and more with the fact that +> people view interaction via the web (as in the case of a wiki) +> quite differently than they view material that is delivered and +> distributed via email. This currently seems to be a major +> obstacle to implementing active collaboration via the web. :( + +There is a second problem here. Adding latex or axiom commands to your +email is easy and convenient, but generally requires one to then go look +at the web page to see if you made any typos. It's the whole +edit-compile-test cycle that people don't normally associate with email, +but is inherent in work with both latex and math software axiom/reduce. + +I have thought about this quite a bit wrt latexwiki and don't really +have a good solution. I have thought about bouncing emails back to +users when it contains a latex syntax error, so they can correct and +resubmit. But this does not help with syntax-correct logic errors that +need to be edited like $x^23$ or unexpected output from axiom commands. + +The situation suggests an integrated email/web/axiom interface that does +all this without the intermediate submit-to-webpage step. But now I'm +getting waaaay beyond the modest goals that this group has collectively +tackled so far. + +Ideas welcome here... + +Who has played significantly with texmacs? + +\start +Date: 24 Sep 2004 13:11:27 -0400 +From: Camm Maguire +To: Martin Rubey +Subject: [Axiom-developer] Quick question on the symbol issue: +Cc: Manuel Bronstein + +Greetings! + +OK, the issue does not appear to be with the underlying lisp as far as +I can tell. Please correct me if I am in error (with verifiable +details if possible). Rather the new() functions in SYMBOL.spad do +not check that the user might have referred previously to a symbol +with the 'special' % prefix. Alternatively, perhaps it was intended +that % act somewhat like the #: lisp reader macro in designating a +symbol that is to be uninterned. If this is the case, please point me +to the code that is intended to establish this behavior and I'll look +at it. + +Assuming the rather more likely scenario that the design simply did +not intend for users to set by hand symbols beginning with % (as it +does appear to be used as some sort of escape), the following patch +will increment the counter as necessary to step over symbols already +so interned: + +(sid)camm@intech66:/fix/g/camm/axiom/axiom-0.20040831/src/algebra$ diff -u symbol.spad.pamphlet.ori symbol.spad.pamphlet +--- symbol.spad.pamphlet.ori 2004-05-24 22:53:45.000000000 +0000 ++++ symbol.spad.pamphlet 2004-09-24 16:51:41.000000000 +0000 +@@ -252,27 +252,32 @@ + if zero?(n) then return ns + + new() == +- sym := anyRadix(count()::Integer,ALPHAS) +- count() := count() + 1 +- concat("%",sym)::% ++ repeat ++ sym := anyRadix(count()::Integer,ALPHAS) ++ count() := count() + 1 ++ ns := concat("%",sym) ++ if not FIND_-SYMBOL(ns)$Lisp then return ns::% + + new x == +- n:Integer := +- (u := search(x, xcount)) case "failed" => 0 +- inc(u::Integer) +- xcount(x) := n +- xx := +- not scripted? x => string x +- string name x +- xx := concat("%",xx) +- xx := +- (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => +- concat(xx, anyRadix(n,alphas)) +- concat(xx, anyRadix(n,nums)) +- not scripted? x => xx::% +- script(xx::%,scripts x) ++ repeat ++ n:Integer := ++ (u := search(x, xcount)) case "failed" => 0 ++ inc(u::Integer) ++ xcount(x) := n ++ xx := ++ not scripted? x => string x ++ string name x ++ xx := concat("%",xx) ++ xx := ++ (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => ++ concat(xx, anyRadix(n,alphas)) ++ concat(xx, anyRadix(n,nums)) ++ if not FIND_-SYMBOL(xx)$Lisp then ++ if not scripted? x then return xx::% ++ return script(xx::%,scripts x) + + resetNew() == ++-- Do we want to unintern the symbols previously interned here? + count() := 0 + for k in keys xcount repeat remove_!(k, xcount) + void + + +As noted in the comment, regardless of resetNew(), subsequent +invocations of new() will start where the counter left off, unless one +adds code to unintern the specified symbols, which in this case might +wipe out a symbol explicitly specified by the user. Don't know what +is best here, though I suspect the latter. + +As for gensym, it returns a fresh *uninterned* symbol at all times. +(eq '#:g '#:g) ==> nil. Axiom is printing the symbol without this +special syntax which might alert one to what is going on. In short, +G1419::Symbol *is in fact distinct* from the return value of +symbol(GENSYM()$Lisp) even when the print value is the same. The +former is interned and can be retrieved again by the same user input. +The latter is lost forever unless saved as the value of some other +variable. You will never be able to write code trying to refer to +gensymmed output by the printed symbol name. This is also the case in +lisp as the example above shows. So not sure if any changes are +warranted here. + +Please let me know if this is all off base. And yes, in answer to +your previous question, though not a mathematician, I have a Ph.D. in +theoretical physics, and so could work on math bugs in axiom providing +they are not too specialized. As time is short, I'd really prefer not +working on things which are not *important*, which I'm defining here +as increasing the utility of as many people as possible by as much as +possible. + +Take care, + +> (1) -> %A::Symbol +> +> (1) %A +> Type: Symbol +> (2) -> new()$Symbol +> +> (2) %A +> Type: Symbol +> (3) -> G1419::SYMBOL +> +> +> (3) G1419 +> Type: Symbol +> (4) -> symbol(GENSYM()$Lisp) +> Loading /home/rubey/axiom/mnt/linux/algebra/SEX.o for domain +> SExpression +> Loading /home/rubey/axiom/mnt/linux/algebra/DFLOAT.o for domain +> DoubleFloat +> Loading /home/rubey/axiom/mnt/linux/algebra/SEXOF.o for domain +> SExpressionOf +> +> (4) G1419 +> Type: Symbol +> +> (5) -> b:=%B +> +> (5) %B +> Type: Variable %B +> (6) -> new()$Symbol +> +> (6) %B + +\start +Date: Fri, 24 Sep 2004 19:11:22 +0000 +From: Martin Rubey +To: Bob McElrath +Subject: Re: [Axiom-developer] speakerscorner +Cc: Bill Page + +Bob McElrath writes: + > The situation suggests an integrated email/web/axiom interface that does + > all this without the intermediate submit-to-webpage step. + +I'm unwilling to exchange MY (:-) emacs against any such tool. BTW: Bill, could you set +up support for external editor? + +http://zwiki.org/HowToSetUpExternalEditor + +\start +Date: 24 Sep 2004 13:16:45 -0400 +From: Camm Maguire +To: daly@idsi.net +Subject: Re: [Axiom-developer] solving polynomial equations +Cc: James Amundson , Maxima List + +Greetings! Just wanted to pass on that popcon is slowly gaining usage +within Debian, which gives an idea of how many people are using axiom, +maxima and other packages via the Debian distribution. Readers might +be interested in the links below. + +http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&beenhere=1 + +http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&beenhere=1 + +\start +Date: Fri, 24 Sep 2004 20:11:20 +0000 +From: Martin Rubey +To: Camm Maguire +Subject: [Axiom-developer] Re: Quick question on the symbol issue: + +Hi Camm! + +Camm Maguire writes: + > OK, the issue does not appear to be with the underlying lisp as far as I can + > tell. Please correct me if I am in error (with verifiable details if + > possible). + +This is very strange: in +http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00081.html William +Sit reports that the problem does not occur in the NAG version. He writes: + +> I have started verifying your bug on the NAG Axiom 2.3 version, which +> presumably have the same algebra sources. There are some places where I cannot +> duplicate your error messages. (I am also handicapped as far as Linux goes and +> so my Axiom set up is on a separate computer (in fact a virtual computer) that +> makes it clumsy to transfer text. I am using the NAG version because it helps +> to identify whether the bug is from the algebra or the open source "meddling" +> :-) +> +> On my system, which is not the open source one, I have this (transcribing ;-( +> nonessential things omitted) +> +> )clear all +> (1) -> %A:SYMBOL +> %A +> +> (2) -> new()$SYMBOL +> %D + +On the other hand, your explanations make a lot of sense. + + > Rather the new() functions in SYMBOL.spad do not check that the user might + > have referred previously to a symbol with the 'special' % prefix. + +Yes, that was my first thought too. + + > Alternatively, perhaps it was intended that % act somewhat like the #: lisp + > reader macro in designating a symbol that is to be uninterned. If this is + > the case, please point me to the code that is intended to establish this + > behavior and I'll look at it. + +No idea. However, I'd be interested whether the bug *really* does not occur in +the NAG version. It could well be the case that new()$Symbol always starts with +%D in NAG. Could you check, William? + + > (sid)camm@intech66:/fix/g/camm/axiom/axiom-0.20040831/src/algebra$ diff -u symbol.spad.pamphlet.ori symbol.spad.pamphlet + > --- symbol.spad.pamphlet.ori 2004-05-24 22:53:45.000000000 +0000 + > +++ symbol.spad.pamphlet 2004-09-24 16:51:41.000000000 +0000 + > @@ -252,27 +252,32 @@ + > if zero?(n) then return ns + > + > new() == + > - sym := anyRadix(count()::Integer,ALPHAS) + > - count() := count() + 1 + > - concat("%",sym)::% + > + repeat + > + sym := anyRadix(count()::Integer,ALPHAS) + > + count() := count() + 1 + > + ns := concat("%",sym) + > + if not FIND_-SYMBOL(ns)$Lisp then return ns::% + > + > new x == + > - n:Integer := + > - (u := search(x, xcount)) case "failed" => 0 + > - inc(u::Integer) + > - xcount(x) := n + > - xx := + > - not scripted? x => string x + > - string name x + > - xx := concat("%",xx) + > - xx := + > - (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => + > - concat(xx, anyRadix(n,alphas)) + > - concat(xx, anyRadix(n,nums)) + > - not scripted? x => xx::% + > - script(xx::%,scripts x) + > + repeat + > + n:Integer := + > + (u := search(x, xcount)) case "failed" => 0 + > + inc(u::Integer) + > + xcount(x) := n + > + xx := + > + not scripted? x => string x + > + string name x + > + xx := concat("%",xx) + > + xx := + > + (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => + > + concat(xx, anyRadix(n,alphas)) + > + concat(xx, anyRadix(n,nums)) + > + if not FIND_-SYMBOL(xx)$Lisp then + > + if not scripted? x then return xx::% + > + return script(xx::%,scripts x) + +great. Even better: it would have been impossible for me to fix that! (don't +know find-symbol...) + + > + > resetNew() == + > +-- Do we want to unintern the symbols previously interned here? + > count() := 0 + > for k in keys xcount repeat remove_!(k, xcount) + > void + + > As noted in the comment, regardless of resetNew(), subsequent invocations of + > new() will start where the counter left off, unless one adds code to + > unintern the specified symbols, which in this case might wipe out a symbol + > explicitly specified by the user. Don't know what is best here, though I + > suspect the latter. + +I don't understand what you explain here. What symbols do you mean with +"specified symbols"? + +----------------------------------------------------------------------------- + + > As for gensym, it returns a fresh *uninterned* symbol at all times. (eq + > '#:g '#:g) ==> nil. Axiom is printing the symbol without this special + > syntax which might alert one to what is going on. In short, G1419::Symbol + > *is in fact distinct* from the return value of symbol(GENSYM()$Lisp) even + > when the print value is the same. + +Well observed! I had to try it out :-) : + +(1) -> a:=G1418::Symbol + + (1) G1418 + Type: Symbol +(2) -> b:=symbol(GENSYM()$Lisp) + (2) G1418 + Type: Symbol +(4) -> (a=b)::Boolean + + (4) false + Type: Boolean +(5) -> a:=%A::Symbol + + (5) %A + Type: Symbol +(6) -> b:=new()$Symbol + + (6) %A + Type: Symbol +(8) -> (a=b)::Boolean + + (8) true + +Shame on me... + + > And yes, in answer to your previous question, though not a mathematician, I + > have a Ph.D. in theoretical physics, and so could work on math bugs in axiom + > providing they are not too specialized. + +Great! + + > As time is short, I'd really prefer not working on things which are not + > *important*, which I'm defining here as increasing the utility of as many + > people as possible by as much as possible. + +Yes. BTW, it seems that Bill Page made progress on integrating pamphlets into +MathAction. Very good week! + +If you can spare time I suggest that you look at + +http://page.axiom-developer.org/zope/mathaction/WishList + +The TodoList currently seems a bit outdated to me. I will update it when I get +to it. However, I'm not that good at rating what's important and what's not +that urgent. I find that there are not that many severe unfixed bugs known at +the moment (on the other hand: a (mathematical) bug is one bug too many), so +maybe a windows port and more functionality (mathswise) has higher priority. + +Maybe you could also add to the WishList what would be a real goody for a +physicist? + +\start +Date: Sat, 25 Sep 2004 17:08:12 +0200 +From: Hans Peter Wuermli +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Axiom crashing in Zope-Plone + +Hi + +I wonder if someone with the new Zope-Plone-LatexWiki experience can help me. + +Having been enthusiastic about MathAction I tried to set it up locally on my +local computer, too, using the ZWiki and LatexWiki files on +http://page.axiom-developer.org/repository. Strangely enough Axiom is not +rendered, as the method runCommand() in axiomWrapper.py fails when run from +inside Zope. Testing the method externally either within a zope.app() or as a +standalone method, does not produce errors and works as expected. + +I checked with a lot of analoguous situations, first suspecting missing access +rights, but "wrapping", for example, an executable, a segfaulting executable +or a psql script run fine, standalone or within zope as external methods. + +I can boil down the error to the external method "demo.py" at the end of the +mail, which is similar to the runCommand() in axiomWrapper.py. + +Zope is version 2.6.4; python used is version 2.2 and it all runs on a Debian +sarge system. + +The exit codes for Popen3 when run from Zope are: + +WEXITSTATUS:139 +WIFEXITED: 1 + +Thank you for any help. + +Cheers, H.P. + + +demo.py: + +import os +from popen2 import Popen3 + + +axiomTemplate = r""")set output algebra off +)set output tex on +)set message autoload off +)set quit unprotected +integrate(x**2,x) +)quit +""" + +LatexWikiHome = '/usr/lib/zope/lib/python\ +/Products/LatexWiki/Extensions/' + +axTinput = open ( LatexWikiHome + 'axT.input', 'w' ) +axTinput.write(axiomTemplate) +axTinput.close() + +cmdLine = r'export AXIOM=/usr/lib/axiom-0.20040831;\ +export PATH=$AXIOM/bin:$PATH;\ +AXIOMsys < %s ' %(LatexWikiHome + 'axT.input') + +def echoWorld(): + """ external method calling Popen3 """ + p = Popen3 (cmdLine, 1, 4096) + status = p.wait() + p.tochild.close() + out = p.fromchild.read() + p.fromchild.close() + err = '' + if p.childerr: err = p.childerr.read(); p.childerr.close() + error = os.WEXITSTATUS(status) or \ + not os.WIFEXITED(status) + if not error: return\ + 'Output: ' + out +\ + '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\ + '\nWIFEXITED: ' + str(os.WIFEXITED(status)) + else: return\ + 'Error: ' + err +\ + '\nOut: ' + out +\ + '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\ + '\nWIFEXITED: ' + str(os.WIFEXITED(status)) + +# For Zope external testing +print echoWorld() + +\start +Date: Sat, 25 Sep 2004 10:33:07 -0700 +From: Bob McElrath +To: Hans Peter Wuermli +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone + +The original version of runCommand (and your example below) fails if +your program creates a large amount of output. I only discovered the +bug recently when re-rendering one of my pages with a lot of latex. + +You should grab latexwiki from my repository:: + + http://bob.mcelrath.org/darcs/latexwiki + +which is the official source for that, then 'darcs pull' from:: + + http://page.axiom-developer.org/repository + +which has the axiom patches. These will be integrated to latexwiki +eventually -- right now the axiom patches duplicate a lot of code +(including runCommand). If someone wants to clean this up, I will +accept patches! ;) I've just been busy lately. Physics comes first... + +The fixed runCommand is:: + + # Make our file descriptors nonblocking so that reading doesn't hang. + def makeNonBlocking(f): + fl = fcntl.fcntl(f.fileno(), FCNTL.F_GETFL) + fcntl.fcntl(f.fileno(), FCNTL.F_SETFL, fl | os.O_NONBLOCK) + + def runCommand(cmdLine): + program = popen2.Popen3('cd %s; '%(workingDir) + cmdLine, 1) + program.tochild.close() + makeNonBlocking(program.fromchild) + makeNonBlocking(program.childerr) + stderr = [] + stdout = [] + erreof = False + outeof = False + while(not (erreof and outeof)): + readme, writme, xme = select.select([program.fromchild, program.childerr], [], []) + for output in readme: + if(output == program.fromchild): + text = program.fromchild.read() + if(text == ''): outeof = True + else: stdout.append(text) + elif(output == program.childerr): + text = program.childerr.read() + if(text == ''): erreof = True + else: stderr.append(text) + status = program.wait() + error = os.WEXITSTATUS(status) or not os.WIFEXITED(status) + return error, string.join(stdout, ''), string.join(stderr, '') + +Hans Peter Wuermli [wurmli@hispeed.ch] wrote: +> +> Hi +> +> I wonder if someone with the new Zope-Plone-LatexWiki experience can help me. +> +> Having been enthusiastic about MathAction I tried to set it up locally on my +> local computer, too, using the ZWiki and LatexWiki files on +> http://page.axiom-developer.org/repository. Strangely enough Axiom is not +> rendered, as the method runCommand() in axiomWrapper.py fails when run from +> inside Zope. Testing the method externally either within a zope.app() or as a +> standalone method, does not produce errors and works as expected. +> +> I checked with a lot of analoguous situations, first suspecting missing access +> rights, but "wrapping", for example, an executable, a segfaulting executable +> or a psql script run fine, standalone or within zope as external methods. +> +> I can boil down the error to the external method "demo.py" at the end of the +> mail, which is similar to the runCommand() in axiomWrapper.py. +> +> Zope is version 2.6.4; python used is version 2.2 and it all runs on a Debian +> sarge system. +> +> The exit codes for Popen3 when run from Zope are: +> +> WEXITSTATUS:139 +> WIFEXITED: 1 +> +> Thank you for any help. +> +> Cheers, H.P. +> +> +> demo.py: +> +> import os +> from popen2 import Popen3 +> +> +> axiomTemplate = r""")set output algebra off +> )set output tex on +> )set message autoload off +> )set quit unprotected +> integrate(x**2,x) +> )quit +> """ +> +> LatexWikiHome = '/usr/lib/zope/lib/python\ +> /Products/LatexWiki/Extensions/' +> +> axTinput = open ( LatexWikiHome + 'axT.input', 'w' ) +> axTinput.write(axiomTemplate) +> axTinput.close() +> +> cmdLine = r'export AXIOM=/usr/lib/axiom-0.20040831;\ +> export PATH=$AXIOM/bin:$PATH;\ +> AXIOMsys < %s ' %(LatexWikiHome + 'axT.input') +> +> def echoWorld(): +> """ external method calling Popen3 """ +> p = Popen3 (cmdLine, 1, 4096) +> status = p.wait() +> p.tochild.close() +> out = p.fromchild.read() +> p.fromchild.close() +> err = '' +> if p.childerr: err = p.childerr.read(); p.childerr.close() +> error = os.WEXITSTATUS(status) or \ +> not os.WIFEXITED(status) +> if not error: return\ +> 'Output: ' + out +\ +> '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\ +> '\nWIFEXITED: ' + str(os.WIFEXITED(status)) +> else: return\ +> 'Error: ' + err +\ +> '\nOut: ' + out +\ +> '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\ +> '\nWIFEXITED: ' + str(os.WIFEXITED(status)) +> +> # For Zope external testing +> print echoWorld() + +\start +Date: Sat, 25 Sep 2004 16:22:45 -0400 +From: "Bill Page" +To: "'Hans Peter Wuermli'" +Subject: RE: [Axiom-developer] Axiom crashing in Zope-Plone + +Hans, + +I am VERY HAPPY that you are motivated to do this! I would +like to provide you with as much help as I can. + +I tried your demo.py program on the axiom-developer.org system +and it works fine. The program and outout is attached below. +As you can see, I only made a simple change to accommodate the +default location of AXIOMsys and the input file. + +Although Bob McElrath has written separately about the issue of +programs that produce a large output, I don't think that this is +the problem since the MathAction axiom code already uses the +"fixed runCommand" (makeNonBlocking etc.) that Bob mentions. + +Therefore I think the best approach would be to find the +meaning of the EXITSTATUS 139. I will let you know if I find +anything. + +Regards, +Bill Page. + +-------- +[page@axiom-developer page]$ cat demo.py +import os +from popen2 import Popen3 + + +axiomTemplate =3D r""")set output algebra off +)set output tex on +)set message autoload off +)set quit unprotected +integrate(x**2,x) +)quit +""" + +LatexWikiHome =3D '' + +axTinput =3D open ( LatexWikiHome + 'axT.input', 'w' ) +axTinput.write(axiomTemplate) +axTinput.close() + +cmdLine =3D r'AXIOMsys < %s ' %(LatexWikiHome + 'axT.input') + +def echoWorld(): + """ external method calling Popen3 """ + p =3D Popen3 (cmdLine, 1, 4096) + status =3D p.wait() + p.tochild.close() + out =3D p.fromchild.read() + p.fromchild.close() + err =3D '' + if p.childerr: err =3D p.childerr.read(); p.childerr.close() + error =3D os.WEXITSTATUS(status) or \ + not os.WIFEXITED(status) + if not error: return\ + 'Output: ' + out +\ + '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\ + '\nWIFEXITED: ' + str(os.WIFEXITED(status)) + else: return\ + 'Error: ' + err +\ + '\nOut: ' + out +\ + '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\ + '\nWIFEXITED: ' + str(os.WIFEXITED(status)) + +# For Zope external testing +print echoWorld() + +[page@axiom-developer page]$ python demo.py +Output: AXIOM Computer Algebra System + Version of Monday June 21, 2004 at 08:34:09 +-------------------------------------------------------------------------= +--- +- + Issue )copyright to view copyright notices. + Issue )summary for a summary of useful system commands. + Issue )quit to leave AXIOM and return to shell. +-------------------------------------------------------------------------= +--- +- + + Re-reading compress.daase Re-reading interp.daase + Re-reading operation.daase + Re-reading category.daase + Re-reading browse.daase +(1) -> (1) -> (1) -> (1) -> (1) -> +$$ +{1 \over 3} \ {x \sp 3} +\leqno(1) +$$ + + Type: Polynomial Fraction +Integer +(2) -> +WEXITSTATUS: 0 +WIFEXITED: 1 +[page@axiom-developer page]$ + +\start +Date: Sat, 25 Sep 2004 13:46:53 -0700 +From: Bob McElrath +To: Bill Page +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: 'Hans Peter Wuermli' + + +--WlEyl6ow+jlIgNUh + +Bill Page [bill.page1@sympatico.ca] wrote: +> Hans, +> +> I am VERY HAPPY that you are motivated to do this! I would +> like to provide you with as much help as I can. +> +> I tried your demo.py program on the axiom-developer.org system +> and it works fine. The program and outout is attached below. +> As you can see, I only made a simple change to accommodate the +> default location of AXIOMsys and the input file. + +Actually, I did not try to run your program. Now that I do I find the +same as Bill...it works fine...on my Intel office computer. + +> Although Bob McElrath has written separately about the issue of +> programs that produce a large output, I don't think that this is +> the problem since the MathAction axiom code already uses the +> "fixed runCommand" (makeNonBlocking etc.) that Bob mentions. +> +> Therefore I think the best approach would be to find the +> meaning of the EXITSTATUS 139. I will let you know if I find +> anything. + +It is a segmentation fault. I also see this on my alpha server. (note +same axiom version in both places -- 0831) + +In fact, now I can't run axiom at all on that computer -- it always +segfaults. + +Program received signal SIGSEGV, Segmentation fault. +0x0000020000288158 in memmove () from /lib/libc.so.6.1 +(gdb) where +#0 0x0000020000288158 in memmove () from /lib/libc.so.6.1 +#1 0x000000012046a4b0 in gcl_init_GBC () +#2 0x0000000120468f3c in memprotect_test_reset () +#3 0x000000012047d284 in main () + +\start +Date: Sat, 25 Sep 2004 20:45:08 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Hi Martin: + +Martin Rubey wrote: +> +> Dear William, +> +> hope I'm not annoying you... +Not at all. When I said "I am pressed for time", I simply meant that at that +time, I would not be able to answer or test code as thoroughly as I would like +and it was an apologetic remark. + +> > This result is wrong since I can change x to another symbol and the result +> > would be the same: +> +> I'm not so sure about "wrong". One (not me...) could argue that the two +> univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I (!) +> would say that this behaviour should be reserved for SUPs. + +Yes, when univariate polynomials are interpreted as functions in the +mathematical sense, 3*x+1 and 3*t+1 are the same (x, t are dummy variables or +placeholders for the functions). But this is seldom the interpretation in +symbolic computation. Here, we are getting closer to a discussion on what +"equality" means, a well-understood problem with many possibilities but no clear +choice that would work for all situations. I am not sure what "this behaviour" +refers to, or why SUPs are more appropriate. + +> And indeed, axiom +> does say that +> +> ((x::UP(x, INT))=(t::UP(t, INT)))::Boolean +> +> is false. + +Again, at the risk of being repetitve, be careful here. Your axiom line above +means first defining an equation x=t (in the domain Equation UP(x, UP(t, INT)) +after automatic coercion) and then coercing to Boolean in that same domain, +which then gives false. The action Axiom takes is NOT the same as in the case + + g:Boolean:= ((x::UP(x, INT))=(t::UP(t, INT))) + +even though the results are the same. The subtle difference lies in side-effects +while getting to the result. In the first instance, it looks for a domain T: +Type and a signature for [equation:(T,T)->Equation(T)], while in the latter, a +domain S:SetCategory and a signature for ["=": (S,S)-> Boolean]. + +> > So I think this is a bug in the interpreter. Instead of trying to be helpful +> > to search for an "=" that returns Boolean for the types given on the lhs and +> > rhs, it should simply first check whether the two sides have the same type +> > and then whether equality testing "=" exist for that type. No automatic +> > coercion should be done. +> +> I'm very unsure about this. Note that when you look at the corresponding EQ +> types (if you do not coerce to Boolean), everything looks sane. I do understand +> that the domain EQ is not involved when you do ask for a boolean immediately, +> but I wouldn't hurry here. + +Equation(T) only needs T:Type. Equation(T) has CoercibleTo(Boolean) if +T:SetCategory. I wish Axiom had not overloaded the operator "=" but say used +"=?" for boolean (indeed, I like it to always use an identifier ending with ? +for all functions with codomain Boolean). There is really no good reason to +coerce lhs and rhs to a common S:SetCategory if lhs and rhs are not already in +the same domain, then they are not equal, period, even if a test for equality +has not been implemented. Note that lhs and rhs are always evaluated (and +presumably simplified to $Rep form) before the test. If they do not belong to +the same domain, why should they be equal in a super-domain? Of course, if they +do not belong to the same domain (without coercion), no ["="] will be found and +so no result will be output; but in that case, an error message is the correct +response (and the error should be trapped via a throw/catch mechanism) -- it is +like someone writes an *equality* where the lhs and rhs does not have the same +fundamental dimensions of time, length, mass -- it is an error that should be +caught. Note that to coerce the lhs and rhs to a common domain T to use +[equation] would make sense in some cases, because after all, we could have +written the equation as lhs-rhs=0 if the domain T has AbelianGroup and we may +want to solve the equation. + + +> It seems that there is a fundamental misunderstanding concerning my intention +> with regards to the semantics of UP(x, POLY INT). You wrote +> +> > There is one problem with the +> > +> > member?(x, variables(r)) +> > +> > condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I +> > would think that variables(r) would have x as a member, and so you would receive +> > the error message when coerce is called. But according to your intention, you +> > may still want to coerce r (that is, in my terminology, reformat r) to look like +> > UP(x, EXPR INT). +> +> In fact, an error message is exactly what I'd like to see for +> (1/x)::UP(x, EXPR INT). + +Sorry, Martin, I probably misunderstood it when you wrote on +Wed, 22 Sep 2004 17:08:07 +0000: + +> On the other hand, it is easy to clarify the semantics of types like +> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this +> domain. + +I took that to mean it is easy to view (reformat) an expression such as +x^2 sin(x) - cos(x)/x as a polynomial in x and so UP(x, EXPR INT) makes sense +even when x wears two hats. + +> I try to get it right now: (It may be that my current position differs from +> that I had some months ago, but it was constant in the last few weeks. Save I +> made a mistake) +> +> For any polynomial (or series) domain that has a specified list of variables, I +> want that axiom ensures that any coefficient of a member does not contain one +> of these variables. Examples: +> +> (1/x)::UP(x, EXPR INT) produces an error +> x*2^x::UP(x, EXPR INT) produces an error +> (1/x)::UP(x, FRAC POLY INT) produces an error +> (1/x)::UTS(FRAC POLY INT,x,0) produces an error + +I am not sure. If UP(x, EXPR INT) is a valid domain (which it is at present), +then all the above can be regarded as in the ground ring EXPR INT. +> +> however, for example +> +> x*2^y::UP(x, EXPR INT) is ok. +> +> More generally, the "outermost" domain "takes" all the variables: + +In that case, you would forbid expressions like x^2 sin(x) - cos(x)/x in UP(x, +EXPR INT), where the expression can either be considered as in the ground ring +EXPR INT, or as a polynomial of degree 2. I don't think the second view is +necessarily "wrong," just that Axiom at present does not do this conversion +consistently. I gave some examples where the built-in coercions led to +inconsistencies in [degree]. + +> POLY EXPR INT would be the domain of polynomials with coefficients that do not +> contain any variables. For example, +> +> (x*sin(2))::POLY EXPR INT would be ok +> (x*sin(y))::POLY EXPR INT would produce an error. + +Again, I am not sure why the second one should be an error and the first is not, +if POLY EXPR INT is allowed at all. In both cases, the element may be +interpreted either as in EXPR INT, or a linear polynomial with coefficient in +EXPR INT. Neither is mathematically wrong and each is useful. The problem is +each element may have two different data representations, and the[:: POLY EXPR +INT] does not say specifically what data representation should be used. We need +a clearer way to make the choice. Using a hidden and probably unjustified +convention that the "outer domain takes all the variables" is questionable. + +> The domain EXPR POLY INT would be strictly the same as EXPR INT, I think. + +No, we are not talking about mathematics, but data structure. I think we agree +that the current semantics allowed is ambiguous and for this reason, any +reformating should be done with specific variables. + +> +> On the other hand, there is a completely different solution to the original +> problem, i.e., providing a domain like UP(x, EXPR INT) with good semantics: +> +> > > Yes. I'm inclined to think that this is the best way to go: create a domain +> > > EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY +> > > ?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on... +> > +> > Good. I am glad we are beginning to agree. However, your point of creating +> > something like sin(2) x somewhere should be considered carefully. +> +> sin(2)*x would be in UP(x, EXPR([], INT)). Did you mean that? + +Yes. For the sake of completeness, let me quote what I wrote on +Wed, 22 Sep 2004 15:20:14 -0400: +before further comments. +------- quote +> Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be +> forbidden, since it is not clear where the variables belong. + +AGREED! + +> On the other hand, it is easy to clarify the semantics of types like +> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this +> domain. I don't think that there is another way to make sense of such a +> domain. That's the reason for the question I started with, in fact. + +But so should UP(x, EXPR INT). You are inconsistent in the application of your +logic: according to the above, POLY EXPR INT is equally fine (just that there +may be more variables). But back to UP. EXPR INT can also contain polynomials in +x in addition to 1/x, 2^x, sin x. In fact: + +(15) sin(x)*x + sin(x)*x^2 + (x^2 + x)sin(x) Type Expression Integer + +This regrouping is automatic. If you rather prefer the input form, which +separates the powers of x, I think you should use a package to provide the +conversion WITHIN EXPR INT and where you also change the outputform. In Axiom, +the domains correspond to mathematical objects, and to have x in BOTH EXPR INT +and UP(x, EXPR INT) is not right since mathematically, the two are the same, as +underlying set and all operations on it. Indeed, any operation in UP(x, EXPR +INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need +to reconvert UP(x, EXPR INT) back to EXPR INT --- a difficult dilemma because +you now have to consider UP(x,EXPR INT) elements as ground elements (ground? may +fail, in general, though not here), perform the operation, and reformating back +to UP(x, EXPR INT). This really shows that the only thing you can achieve is +reformatting output and so it should be done that way. + +If you are not mixing x in both places, then something like UP(y, +EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is +constructed. +----- end quote + +Actually, I think it is possible to implement something like EXPR([a,b], INT). +The current discussion arose all because EXPR (and by dependencies, also FS and +perhaps more like ES) uses Symbol as default variable set (same as POLY). +Whereas POLYCAT is parametrically constructed with good control for the +variables set AND its ordering, EXPR and FS do not provide such control. So we +need to study how to add such control without breaking any established code. + +As a preliminary suggestion, I propose to generalize the FS category +constructors analogous to POLYCAT: + FunctionSpaceCategory(V:OrderedSet, R: OrderedSet):Category +with abbreviation FSCAT. + +This will be done by suitably modifying the existing FunctionSpace(R) code. Then +we can "capture" back FunctionSpace(R) by: + FunctionSpace(R:OrderedSet):Category == FSCAT(Symbol, R) + +In a similar way, we can generalize Expression. (I was thinking about a category +constructor ExpressionCategory, but I think this would be the same as +FunctionSpaceCategory). + + MultivariateExpression(V:OrderedSet, R: OrderedSet):FSCAT(V,R) + +to be abbreviated as MEXPR, and recapture Expression as: + + Expression(R:OrderedSet):FS(R)== MEXPR(Symbol, R) + +We can also have SparseMultivariateExpression if someone can think of a suitable +data structure. + +The next thing would be to put in controls to disallow towers to ensure that no +intermediate extensions involve Symbol as the variable set. + +> ------------------------------------------------------------------------ +> +> However, currently this seems unachievable. At least I don't know how to do +> it. Your suggestion to extend axiom to allow +> +> > Ideally, perhaps we can try: +> > +> > if S has variables: S -> List V where V:OrderedSet then +> > variables: % -> List V +> > variables f == +> > mymerge(variables(numer(f)), variables(denom(f))) +> +> seems most appealing to me, although I don't think this could be done in the +> near future. I read a bit about the "post-facto" extensions provided by aldor, +> maybe they adress this problem too. I'm not sure that I've understood them well +> enough, though. +> +> PS: In fact, I can think of a way to do it: provide a function +> variables2: % -> List Any in POLYCAT that simply wraps up the function +> variables:% -> List VarSet. +> +> Then I can provide a function variables2 in QFCAT. The only tricky part is that +> I need the operation "<" from VarSet in QFCAT (for mymerge) and I don't know of +> a *good* way to get it. I do know an ugly way: provide a function +> (Any, Any)->Boolean in POLYCAT that wraps "<" from VarSet. +> +> Maybe there is a better way, but I'm tired now. + +Take a rest! Yes, someone who is experienced with Aldor may tell us whether to +move there or it is still possible to patch Axiom. However, I think using Any +should be a last resort, even though this may be the only way under Axiom to +treat functions as first class. The trouble with this type of construct is that +the interpreter cannot handle dynamic signature as nicely as the compiler, but +the interpreter can step through code whereas the compiler cannot. + +> ------------------------------------------------------------------------- +> +> just for the record: +> +> > > I agree, if there remains a clear design. For example, I find the wealth of +> > > polynomial domains and packages a little confusing: +> > > +> > > polycat.spad +> > > poly.spad +> > > newpoly.spad +> > > rf.spad +> gdpoly.spad +> multpoly.spad +> prtition.spad +> xlpoly.spad +> xpoly.spad +> wtpol.spad +> ... +> +Wait till we get all the varieties of EXPR (and dare I mention DPOLYCAT or +DEXPR?) + +\start +Date: Sun, 26 Sep 2004 19:55:46 +0200 +From: Hans Peter Wuermli +To: "Bill Page" , "'Bob McElrath'" +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone + +Dear Bob, Bill + +Thank you both for the help. Even though most of the times I am rather +interested in understanding how something works, this time I was just as +interested in getting it to run. And thanks to your help, it did. + +As Bob mentioned that it could be a problem with the build I used, I +downloaded the source and for the last 6 1/2 hours my computer was compiling +(it still is but just the documentation). (By the way: the only compile +problem I had were scripts in scr/scripts without the exe bit set.) + +I had looked a long time what a WEXITSTATUS of 139 meant. Even though some +mail I found expressed 139 as 128 + 11 with 11 the termination signal for a +segmentation faulting process, I still have not found (or understood) in the +linux source the line it says so. Some Posix text said: status for signal +should be higher than 128 (but without a hint for a standard). So I have no +doubt that the 139 expresses that Axiom had caused a segmentation fault, easy +to find and to understand documentation seems rare. + +\start +Date: Sun, 26 Sep 2004 14:43:14 -0400 +From: "Bill Page" +To: "'Hans Peter Wuermli'" +Subject: RE: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: 'Camm Maguire' + +Hans, + +Do I understand correctly that after re-compiling Axiom that +you now have a fully operational LatexWiki system under debian +that can run Axiom? If so, congratulations! I think there are +a number of other people (including Tim Daly :) who would very +much like to setup a similar stand alone LatexWiki/Axiom system. + +I promised Tim that I would set something up for this, but I +have not yet had the time. If you have some time to write up a +short description of how you did it, I think it would be most +appreciated. + +Did you download the binary version of Axiom that failed from +debian unstable? If so, we should be sure to let Camm Maguire +know since he is the architect of the debian version. What +version of GCL are you using for the re-compile? What is the +hardware platform that you are using? + +Regards, +Bill Page. + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Hans Peter Wuermli +> Sent: Sunday, September 26, 2004 1:56 PM +> To: Bill Page; 'Bob McElrath' +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +> +> +> +> Dear Bob, Bill +> +> Thank you both for the help. Even though most of the times I +> am rather interested in understanding how something works, +> this time I was just as interested in getting it to run. And +> thanks to your help, it did. +> +> As Bob mentioned that it could be a problem with the build I +> used, I downloaded the source and for the last 6 1/2 hours my +> computer was compiling (it still is but just the documentation). +> (By the way: the only compile problem I had were scripts in +> scr/scripts without the exe bit set.) +> +> I had looked a long time what a WEXITSTATUS of 139 meant. Even +> though some mail I found expressed 139 as 128 + 11 with 11 the +> termination signal for a segmentation faulting process, I still +> have not found (or understood) in the linux source the line it +> says so. Some Posix text said: status for signal should be higher +> than 128 (but without a hint for a standard). So I have no doubt +> that the 139 expresses that Axiom had caused a segmentation fault, +> easy to find and to understand documentation seems rare. + +\start +Date: Sun, 26 Sep 2004 21:27:53 +0200 +From: Hans Peter Wuermli +To: "Bill Page" +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone + +Dear Bill + +On Sunday 26 September 2004 20.43, you wrote: + +> Do I understand correctly that after re-compiling Axiom that +> you now have a fully operational LatexWiki system under debian +> that can run Axiom? + +Yes. There is some small alignment problem (on the axiom bar, 'axiom' is too +far to the right and 'axiom''s font is too small, i.e. it looks slightly +different that on your server), but otherwise everything looks nice and seems +to work just great. + +> I think there are +> a number of other people (including Tim Daly :) who would very +> much like to setup a similar stand alone LatexWiki/Axiom system. +> I promised Tim that I would set something up for this, but I +> have not yet had the time. If you have some time to write up a +> short description of how you did it, I think it would be most +> appreciated. + +Promised, I will do that, but it might take one or two weeks. I would like to +repeat the procedure myself and do it "cleanly". I messed around, because I +didn't know where the error stemmed from. Unfortunately, my bread job will +keep me quite busy the next week, so I ask for some patience. + +> Did you download the binary version of Axiom that failed from +> debian unstable? + +Yes, but in the meantime it seems to have become "testing". + +> If so, we should be sure to let Camm Maguire +> know since he is the architect of the debian version. What +> version of GCL are you using for the re-compile? + +2.6.3, the one that comes with the sources. The Debian version used 2.6.4 as +far as I remember. + +> What is the +> hardware platform that you are using? + +i386. Debian is based on the Net Installation, which installs Sarge. The +kernel I run is 2.6.7-1, but there are so many ways to describe the +particularities of a system that I wait and answer questions about it, when I +get them. + +Thanks again for your great help and interest. + +\start +Date: Sun, 26 Sep 2004 12:48:18 -0700 +From: Bob McElrath +To: Bill Page +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: 'Camm Maguire' , 'Hans Peter Wuermli' + + +Bill Page [bill.page1@sympatico.ca] wrote: +> Hans, +> +> Do I understand correctly that after re-compiling Axiom that +> you now have a fully operational LatexWiki system under debian +> that can run Axiom? If so, congratulations! I think there are +> a number of other people (including Tim Daly :) who would very +> much like to setup a similar stand alone LatexWiki/Axiom system. + +And me! + +But we really need to have people setting this up in a chroot jail. I +have been reading up on this...we need a script to create the jail. + +> I promised Tim that I would set something up for this, but I +> have not yet had the time. If you have some time to write up a +> short description of how you did it, I think it would be most +> appreciated. + +I would like to distribute axiom support with LatexWiki. I have tied my +version numbers to ZWiki, and they will release 0.35 on 10/1. Do you +think we could add this by then? (or maybe a bit after to ensure 0.35 +compatability) + +Bill our darcs repos have diverged, your patches no longer apply cleanly +to latexwiki. I have moved the functions 'runCommand' and 'log' into +util.py so that they can be used by axiom/reduce. There are a couple +other conflicts too (I improved plone/stylesheet in latexwiki.css). Why +do you have a font-size +2 in your latexwiki.css? Will you have time to +merge this in the next week or two? + +FYI, I have gotten MathML/LatexWiki working in Plone:: + + http://mcelrath.org/Plone/ITeXTest + +You will need my zwiki patches to do that:: + + http://bob.mcelrath.org/darcs/zwiki + +Hopefully I will get those into ZWiki 0.35 but I haven't been able to +get Simon's attention in the last couple of days. ;) As a reminder my +latexwiki repo is here:: + + http://bob.mcelrath.org/darcs/latexwiki + +> Did you download the binary version of Axiom that failed from +> debian unstable? If so, we should be sure to let Camm Maguire +> know since he is the architect of the debian version. What +> version of GCL are you using for the re-compile? What is the +> hardware platform that you are using? + +Mine is a debian binary:: + + (0) dpkg -l axiom + Desired=Unknown/Install/Remove/Purge/Hold + | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed + |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) + ||/ Name Version Description + +++-=================-=================-================================================== + ii axiom 0.20040831-1 A general purpose computer algebra system: main bi + (0) axiom + Segmentation fault + +This is the alpha architecture. + +If I understand correctly, GCL is compiled-in? I do not have gcl itself +installed on this machine. + +\start +Date: Sun, 26 Sep 2004 17:30:15 -0400 +From: root +To: bob+debian-user@mcelrath.org +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: camm@enhanced.com, bill.page1@sympatico.ca, wurmli@hispeed.ch + +Bill, + +Yes, I'd like to have instructions to get a stand-alone version working. +I'm planning to put a modified stand-alone version on the Doyen live CD. +Currently I can almost build the Doyen CD except that the instructions +don't quite match so I'm still struggling with it. Once I get it fully +bootable the next task will be to install Axiom followed almost immediately +with installing MathAction. + +\start +Date: 26 Sep 2004 21:15:29 -0400 +From: Camm Maguire +To: Bob McElrath +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: Bill Page , 'Hans Peter Wuermli' + +Greetings! My apologies, but I've lost the head of this thread. I'm +assuming that there is a segfault problem with debian alpha axiom +(unstable). (GCL is built in btw). I'm also assuming the problem +shows up on startup. In this case, I cannot reproduce -- just +downloaded the binaries and installed on escher.debian.org's unstable +dchroot. Of course you can only run these on Debian testing or +unstable due to the libc et.al dynamic dependencies. Is that the +problem? If any of this is close, please fill in a detailed way I can +reproduce the crash, or better yet, send a copy both to me and to the +Debian BTS. 'reportbug' is good for this. + +For the package to build, btw, the compiled axiom must successfully +run the full input test suite, so the very existence of the alpha +package means that this was done. You can find a log on +buildd.debian.org if interested. + +Take care, + +Bob McElrath writes: + +> Bill Page [bill.page1@sympatico.ca] wrote: +> > Hans, +> > +> > Do I understand correctly that after re-compiling Axiom that +> > you now have a fully operational LatexWiki system under debian +> > that can run Axiom? If so, congratulations! I think there are +> > a number of other people (including Tim Daly :) who would very +> > much like to setup a similar stand alone LatexWiki/Axiom system. +> +> And me! +> +> But we really need to have people setting this up in a chroot jail. I +> have been reading up on this...we need a script to create the jail. +> +> > I promised Tim that I would set something up for this, but I +> > have not yet had the time. If you have some time to write up a +> > short description of how you did it, I think it would be most +> > appreciated. +> +> I would like to distribute axiom support with LatexWiki. I have tied my +> version numbers to ZWiki, and they will release 0.35 on 10/1. Do you +> think we could add this by then? (or maybe a bit after to ensure 0.35 +> compatability) +> +> Bill our darcs repos have diverged, your patches no longer apply cleanly +> to latexwiki. I have moved the functions 'runCommand' and 'log' into +> util.py so that they can be used by axiom/reduce. There are a couple +> other conflicts too (I improved plone/stylesheet in latexwiki.css). Why +> do you have a font-size +2 in your latexwiki.css? Will you have time to +> merge this in the next week or two? +> +> FYI, I have gotten MathML/LatexWiki working in Plone:: +> +> http://mcelrath.org/Plone/ITeXTest +> +> You will need my zwiki patches to do that:: +> +> http://bob.mcelrath.org/darcs/zwiki +> +> Hopefully I will get those into ZWiki 0.35 but I haven't been able to +> get Simon's attention in the last couple of days. ;) As a reminder my +> latexwiki repo is here:: +> +> http://bob.mcelrath.org/darcs/latexwiki +> +> > Did you download the binary version of Axiom that failed from +> > debian unstable? If so, we should be sure to let Camm Maguire +> > know since he is the architect of the debian version. What +> > version of GCL are you using for the re-compile? What is the +> > hardware platform that you are using? +> +> Mine is a debian binary:: +> +> (0) dpkg -l axiom +> Desired=Unknown/Install/Remove/Purge/Hold +> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed +> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) +> ||/ Name Version Description +> +++-=================-=================-================================================== +> ii axiom 0.20040831-1 A general purpose computer algebra system: main bi +> (0) axiom +> Segmentation fault +> +> This is the alpha architecture. +> +> If I understand correctly, GCL is compiled-in? I do not have gcl itself +> installed on this machine. + +\start +Date: Sun, 26 Sep 2004 23:22:49 -0400 +From: "Bill Page" +To: "'Bob McElrath'" +Subject: [Axiom-developer] Axiom support with LatexWiki + +On Sunday, September 26, 2004 3:48 PM Bob McElrath +bob+debian-user@mcelrath.org wrote: +> ... +> But we really need to have people setting this up in a chroot +> jail. I have been reading up on this...we need a script to +> create the jail. + +This would certainly be desirable for Internet use (such as on +MathAction), but for stand alone (localhost only) access it is +not so relevant. + +The concept of the "Doyen" that Tim is pursuing is that people +will install a local copy of LatexWiki and use it as an Axiom +front-end. Some of the local pages would later be uploaded to +an Internet accessible system like MathAction. The idea is that +(most) people prefer to make mistakes and learn in private in +an environment that they trust (their own machine). If the +uploading and downloading of pages can be made reasonably +seamless, then this model might go at least part way to solving +the collaboration problem - it helps people avoid the perception +of loss of control and lack of privacy that some people associate +with using web-based systems. + +> +> > I promised Tim that I would set something up for this, but I +> > have not yet had the time. If you have some time to write up +> > a short description of how you did it, I think it would be +> > most appreciated. +> +> I would like to distribute axiom support with LatexWiki. I +> have tied my version numbers to ZWiki, and they will release +> 0.35 on 10/1. Do you think we could add this by then? (or +> maybe a bit after to ensure 0.35 compatibility) +> + +I am willing to help but I still don't know enough to make this +happen. I would say that it depends on your own availability. + +> Bill our darcs repos have diverged, your patches no longer +> apply cleanly to latexwiki. I have moved the functions +> 'runCommand' and 'log' into util.py so that they can be used +> by axiom/reduce. There are a couple other conflicts too +> (I improved plone/stylesheet in latexwiki.css). Why do you +> have a font-size +2 in your latexwiki.css? + +Honestly, I forget. I think it must have had something to do +with trying to get proper image-text alignment - which is still +not quite right and I don't know why. The alignment is fine +on your site but has never been quite right on MathAction. As I +recall there are some differences in the versions of ghostscript +and PIL between your setup and the one on MathAction. But I +don't know enough to say whether that is the cause or even if +it is, what would be the fix (other than backing out to +previous versions ): + +> Will you have time to merge this in the next week or two? + +Do you mean: upgrade MathAction to the newest LatexWiki and ZWiki +and record compatible changes in the MathAction repository? +Answer: Maybe, but don't count on it. If I can, it will be +before Thursday this week. After that I am tied up for nearly +a month and I want to get this "pamphlet" thing working before +that. + +> +> FYI, I have gotten MathML/LatexWiki working in Plone:: +> + http://mcelrath.org/Plone/ITeXTest + +I like the way you have configured Plone! Simpler. I think +I might try to make the Axiom Portal look more like that. + +> You will need my zwiki patches to do that:: + + http://bob.mcelrath.org/darcs/zwiki + +> Hopefully I will get those into ZWiki 0.35 but I haven't +> been able to get Simon's attention in the last couple of +> days. ;) + +MathML is not a priority for me right now but the new version +of Reduce (not yet on MathAction) is supposed to be able to +generate MathML directly. It might be interesting to compare +the results of directly generated MathML versus LaTeX to MathML +via ITeX. + +\start +Date: Mon, 27 Sep 2004 13:51:05 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +William Sit writes: + +> Martin Rubey wrote: + +> > I'm not so sure about "wrong". One (not me...) could argue that the two +> > univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I +> > (!) would say that this behaviour should be reserved for SUPs. + +> Yes, when univariate polynomials are interpreted as functions in the +> mathematical sense, 3*x+1 and 3*t+1 are the same (x, t are dummy variables or +> placeholders for the functions). But this is seldom the interpretation in +> symbolic computation. Here, we are getting closer to a discussion on what +> "equality" means, a well-understood problem with many possibilities but no +> clear choice that would work for all situations. I am not sure what "this +> behaviour" refers to, or why SUPs are more appropriate. + +I mean (using your terminology): + +"interpreting polynomials as functions" -> "use SUPs, please!" + +> > And indeed, axiom does say that +> > ((x::UP(x, INT))=(t::UP(t, INT)))::Boolean +> > is false. + +> Again, at the risk of being repetitve, be careful here. + +Oops, thank you. I did not really understand. This made it clear to me: + +> In the first instance, it looks for a domain T: Type and a signature for +> [equation:(T,T)->Equation(T)], while in the latter, a domain S:SetCategory +> and a signature for ["=": (S,S)-> Boolean]. + +----------------------------------------------------------------------- + +> Equation(T) only needs T:Type. Equation(T) has CoercibleTo(Boolean) if +> T:SetCategory. I wish Axiom had not overloaded the operator "=" but say used +> "=?" for boolean (indeed, I like it to always use an identifier ending with ? +> for all functions with codomain Boolean). There is really no good reason to +> coerce lhs and rhs to a common S:SetCategory if lhs and rhs are not already +> in the same domain, then they are not equal, period, even if a test for +> equality has not been implemented. Note that lhs and rhs are always evaluated +> (and presumably simplified to $Rep form) before the test. If they do not +> belong to the same domain, why should they be equal in a super-domain? Of +> course, if they do not belong to the same domain (without coercion), no ["="] +> will be found and so no result will be output; but in that case, an error +> message is the correct response (and the error should be trapped via a +> throw/catch mechanism) -- it is like someone writes an *equality* where the +> lhs and rhs does not have the same fundamental dimensions of time, length, +> mass -- it is an error that should be caught. Note that to coerce the lhs and +> rhs to a common domain T to use [equation] would make sense in some cases, +> because after all, we could have written the equation as lhs-rhs=0 if the +> domain T has AbelianGroup and we may want to solve the equation. + +I think you are right. When I get to it, I'll set up a MathAction page +summarizing all this. + +------------------------------------------------------------------------------- + +The following is all under the hypothesis that we want to find valid and clear +semantics for domains like UP(x, EXPR INT). (I believe we do) + +> > For any polynomial (or series) domain that has a specified list of +> > variables, I want that axiom ensures that any coefficient of a member does +> > not contain one of these variables. Examples: + +> > (1/x)::UP(x, EXPR INT) produces an error +> > x*2^x::UP(x, EXPR INT) produces an error +> > (1/x)::UP(x, FRAC POLY INT) produces an error +> > (1/x)::UTS(FRAC POLY INT,x,0) produces an error + +> I am not sure. If UP(x, EXPR INT) is a valid domain (which it is at present), +> then all the above can be regarded as in the ground ring EXPR INT. + +Well, this depends on the semantics we want for a domain like UP(x, EXPR +INT). I argue that, *if* we want that something like UP(x, EXPR INT) makes +sense, then the only sane choice is, that the "outermost" domain "takes" all +the variables. Otherwise we will run into trouble sooner or later. Moreover, +I don't see any need for a domain UP(x, EXPR INT) as it is interpreted +currently, i.e., that allows members like 1/x or x*sin(x). + +> > More generally, the "outermost" domain "takes" all the variables. + +> In that case, you would forbid expressions like x^2 sin(x) - cos(x)/x in +> UP(x, EXPR INT), where the expression can either be considered as in the +> ground ring EXPR INT, or as a polynomial of degree 2. + +Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this +could be viewed as a polynomial. Of course, this argument is based on the idea +that x=x, i.e, there shouldn't be different x's in one expression. + +> I don't think the second view is necessarily "wrong," just that Axiom at +> present does not do this conversion consistently. I gave some examples where +> the built-in coercions led to inconsistencies in [degree]. + +I'm pretty sure that it is next to impossible to do this conversion +consistently. For example: + +(14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT) + + (14) 1 + Type: Fraction UnivariatePolynomial(x,Expression Integer) +(15) -> x::UP(x, EXPR INT)/x::EXPR INT + + 1 + (15) - x + x + Type: UnivariatePolynomial(x,Expression Integer) + +are both completely correct, given the strange semantics of UP(x, EXPR INT). + +> > POLY EXPR INT would be the domain of polynomials with coefficients that do not +> > contain any variables. For example, +> > +> > (x*sin(2))::POLY EXPR INT would be ok +> > (x*sin(y))::POLY EXPR INT would produce an error. +> +> Again, I am not sure why the second one should be an error and the first is not, +> if POLY EXPR INT is allowed at all. In both cases, the element may be +> interpreted either as in EXPR INT, or a linear polynomial with coefficient in +> EXPR INT. Neither is mathematically wrong and each is useful. + +I agree that the second example is on the borderline. However, if we were to +allow it, the description of the new semantics of POLY EXPR INT would be +considerably more complicated. (I even doubt that we could find a good description) + +> The problem is each element may have two different data representations, and +> the[:: POLY EXPR INT] does not say specifically what data representation +> should be used. + +I wouldn't think in terms of data representations yet. My credo: First +determine good semantics, then worry about how to implement/represent them. + +> We need a clearer way to make the choice. Using a hidden and probably +> unjustified convention that the "outer domain takes all the variables" is +> questionable. + +I disagree: I am convinced that this convention is clear. The only other choice +for me would be to depreciate these domains. + +> > The domain EXPR POLY INT would be strictly the same as EXPR INT, I think. + +> No, we are not talking about mathematics, but data structure. I think we +> agree that the current semantics allowed is ambiguous and for this reason, +> any reformating should be done with specific variables. + +I would like to have a mapping from maths to axiom as clear as possible. And +given the convention that the "outermost" domain "takes" all the variables (it +can), EXPR POLY INT and EXPR INT would be the same mathematically, since any +polynomial is an EXPR. Of course, the representations could be different in the +two domains. + +------------------------------------------------------------------------------- + +I agree on everything you say about expressions with specified variables. + + +> > --------------------------------------------------------------------------- + +I don't have anything clever to say right now about defining a wrapper of +"variables" that has values in Any. + +If we want to follow the convention "outermost domain takes all variables it +can" we can simply add a function "variables: % -> List Symbol" to QFCAT (or +wherever it should go), since we only want to test for symbols right now. + +Note that only the interpreter catches bogus like UP(x, UP(x, INT)) right +now. It may be an option to change the interpreter rather than the library, but +I think this is the wrong direction to go. BTW: Do you (or anybody else reading +this) know how the interpreter catches this? In fact, it is broken anyway: + +(12) -> x::UP(x,UP(x,INT)) + + UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) is not a + valid type. +(12) -> monomial(1,1)$UP(x,UP(x,INT)) + + (12) x + Type: UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) + +Thus I think the direction to go is to put these checks into the compiler. + +> > ------------------------------------------------------------------------- +> > +> > just for the record: +> > +> > > > I agree, if there remains a clear design. For example, I find the wealth of +> > > > polynomial domains and packages a little confusing: +> > > > +> > > > polycat.spad +> > > > poly.spad +> > > > newpoly.spad +> > > > rf.spad +> > gdpoly.spad +> > multpoly.spad +> > prtition.spad +> > xlpoly.spad +> > xpoly.spad +> > wtpol.spad +> > ... +> > +> Wait till we get all the varieties of EXPR (and dare I mention DPOLYCAT or +> DEXPR?) + +What would DPOLYCAT or DEXPR be? + +\start +Date: Tue, 28 Sep 2004 10:29:57 -0400 +From: Tim Daly +To: martin.rubey@univie.ac.at +Subject: [Axiom-developer] axiom and aldor cooperation (resend) + +Amusingly enough, it appears that my post to axiom-legal was +automatically discarded as spam mail. Thus I'll violate my +own rule and post this thru axiom-developer. I do, however, +appreciate your attempt to keep the license-related discussions +in axiom-legal. + +======================================================================= + +Martin, + +Axiom and Aldor still work together as far as I know. And from discussions +with Stephen they will continue to do so. + +I'm not exactly sure that I'm allowed to distribute the Aldor sources +although I do have permission to access those sources. If I were +allowed to distribute the source tarball I'd treat it the same way I +treat other packages I use, namely, verbatim track the latest changes +and guarantee that Axiom correctly builds and runs with those changes. + +The current binary requires the user to visit aldor.org and to +agree to the license. This makes it impossible to integrate into +the Axiom build. + +Thus I've done very little in the way of actively pushing Aldor +in the current Axiom distribution. I'd like to do more as I have a +huge pile of C++ code I'm maintaining, most of which would simply +disappear if I could use Aldor. But the feedback about lack of sources +and licensing issues are just beyond my ability to bear at the moment. + +Stephen Watt is the proper person to address the issue. + +\start +Date: 28 Sep 2004 14:05:16 -0400 +From: Camm Maguire +To: perry@ux2.math.us.edu.pl +Subject: [Axiom-developer] Re: Axiom question + +Greetings! + +perry@ux2.math.us.edu.pl writes: + +> Dear Camm Maguire, +> +> Being interested in Axiom CAS, I recently downloaded and installed +> the deb packages prepared by you. Firs of all I would like to express +> that I deeply appreciate the fact that you prepared such easy-to +> install version of Axiom. However, I have a question: according to + +Glad to hear it is of use to you! + +> the docs, Axiom should have two features that I wasn't able to use. +> Namely: graphics/drawing capabilities and explorer-interface. +> I just wonder if these features are unavailable in the Debian +> package or it is something wrong with my configuration. +> + +These are features from the former commercial product which have not +yet been integrated into 'open axiom' upstream. The date on the +package is that of the cvs snapshot taken of the sources. You can +follow the progress, and contribute if you would like, at +axiom-developer@nongnu.org. + +Take care, + +> I tried it on Libranet Linux (off-spring of Debian) on Athlon+512MB +> RAM+ nVidia GeForce 5200 as well as on my ThinkPad 600 +> notebook with Mandrake 10 (after converting deb->rpm). +> +> Yours, +> P. Koprowski +> +> +> -- +> dr Przemyslaw Koprowski +> Faculty of Mathematics +> Silesian University + +\start +Date: 28 Sep 2004 14:21:02 -0400 +From: Camm Maguire +To: Bob McElrath +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: Bill Page , 'Hans Peter Wuermli' + +Greetings! Haven't heard anything here -- just wondering if this +issue is still live. + +Take care, + +Camm Maguire writes: + +> Greetings! My apologies, but I've lost the head of this thread. I'm +> assuming that there is a segfault problem with debian alpha axiom +> (unstable). (GCL is built in btw). I'm also assuming the problem +> shows up on startup. In this case, I cannot reproduce -- just +> downloaded the binaries and installed on escher.debian.org's unstable +> dchroot. Of course you can only run these on Debian testing or +> unstable due to the libc et.al dynamic dependencies. Is that the +> problem? If any of this is close, please fill in a detailed way I can +> reproduce the crash, or better yet, send a copy both to me and to the +> Debian BTS. 'reportbug' is good for this. +> +> For the package to build, btw, the compiled axiom must successfully +> run the full input test suite, so the very existence of the alpha +> package means that this was done. You can find a log on +> buildd.debian.org if interested. +> +> Take care, +> +> Bob McElrath writes: +> +> > Bill Page [bill.page1@sympatico.ca] wrote: +> > > Hans, +> > > +> > > Do I understand correctly that after re-compiling Axiom that +> > > you now have a fully operational LatexWiki system under debian +> > > that can run Axiom? If so, congratulations! I think there are +> > > a number of other people (including Tim Daly :) who would very +> > > much like to setup a similar stand alone LatexWiki/Axiom system. +> > +> > And me! +> > +> > But we really need to have people setting this up in a chroot jail. I +> > have been reading up on this...we need a script to create the jail. +> > +> > > I promised Tim that I would set something up for this, but I +> > > have not yet had the time. If you have some time to write up a +> > > short description of how you did it, I think it would be most +> > > appreciated. +> > +> > I would like to distribute axiom support with LatexWiki. I have tied my +> > version numbers to ZWiki, and they will release 0.35 on 10/1. Do you +> > think we could add this by then? (or maybe a bit after to ensure 0.35 +> > compatability) +> > +> > Bill our darcs repos have diverged, your patches no longer apply cleanly +> > to latexwiki. I have moved the functions 'runCommand' and 'log' into +> > util.py so that they can be used by axiom/reduce. There are a couple +> > other conflicts too (I improved plone/stylesheet in latexwiki.css). Why +> > do you have a font-size +2 in your latexwiki.css? Will you have time to +> > merge this in the next week or two? +> > +> > FYI, I have gotten MathML/LatexWiki working in Plone:: +> > +> > http://mcelrath.org/Plone/ITeXTest +> > +> > You will need my zwiki patches to do that:: +> > +> > http://bob.mcelrath.org/darcs/zwiki +> > +> > Hopefully I will get those into ZWiki 0.35 but I haven't been able to +> > get Simon's attention in the last couple of days. ;) As a reminder my +> > latexwiki repo is here:: +> > +> > http://bob.mcelrath.org/darcs/latexwiki +> > +> > > Did you download the binary version of Axiom that failed from +> > > debian unstable? If so, we should be sure to let Camm Maguire +> > > know since he is the architect of the debian version. What +> > > version of GCL are you using for the re-compile? What is the +> > > hardware platform that you are using? +> > +> > Mine is a debian binary:: +> > +> > (0) dpkg -l axiom +> > Desired=Unknown/Install/Remove/Purge/Hold +> > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed +> > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) +> > ||/ Name Version Description +> > +++-=================-=================-================================================== +> > ii axiom 0.20040831-1 A general purpose computer algebra system: main bi +> > (0) axiom +> > Segmentation fault +> > +> > This is the alpha architecture. +> > +> > If I understand correctly, GCL is compiled-in? I do not have gcl itself +> > installed on this machine. + +\start +Date: Tue, 28 Sep 2004 15:15:47 -0400 +From: "Page, Bill" +To: 'Camm Maguire' +Subject: RE: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: Bill Page , 'Hans Peter Wuermli' , Bob McElrath + +Cam, + +The original report from Hans: + + http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00056.html + +referred to what later was discovered to be a seg fault +(EXITSTATUS:139 from Python 2.2 popen3) generated by Axiom +when run as a sub-process (popen3). Hans later reported that +the failure occured while running a debian binary version +of Axiom on an Intel i386 box. + +In + + http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00059.html + +Bob McElrath reported that he obtained the same failure +when trying to run a debian binary version of Axiom as a +sub-process on an Alpha debian system. It also turned +out that Bob observed the seg fault even when Axiom was +not run as a sub-process. + +In the message + + http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00062.html + +and + + http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00064.html + +Hans reported success on the same hardware platform and +debian version but with Axiom re-compiled from source. + +In + + http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00065.html + +Bob McElrath supplied some details of the debian and +axiom installation on his Alpha system which was still +failing with a seg fault. + +Your suggested possible cause being "libc et.al dynamic +dependencies" in the case of Bob's system seems plausible +to me. I expect he will get back to you about this soon. + +---------- + +Since Hans' problem was solved with a re-compile of Axiom +from source (and a different, older? version of gcl) on a +debian Intel platform, I would worry that this might +indicated a memory management problem which is more severe +when Axiom is run as a sub-process - perhaps with limited +physical memory since Python + Zope + LaTeX + +Ghostscript ++ Axiom is a pretty heavy combination. + +Hans said that he would be busy with his "day job" for +the next week but that he intended to try to build the +MathAction configuration again from scratch to see he +he gets the same problem and solution. + +Thanks for looking into this! + +Regards, +Bill Page. + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Tuesday, September 28, 2004 2:21 PM +> To: Bob McElrath +> Cc: axiom-developer@nongnu.org; Bill Page; 'Hans Peter Wuermli' +> Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +> +> +> Greetings! Haven't heard anything here -- just wondering if this +> issue is still live. +> +> Take care, +> +> Camm Maguire writes: +> +> > Greetings! My apologies, but I've lost the head of this +> thread. I'm +> > assuming that there is a segfault problem with debian alpha axiom +> > (unstable). (GCL is built in btw). I'm also assuming the problem +> > shows up on startup. In this case, I cannot reproduce -- just +> > downloaded the binaries and installed on +> escher.debian.org's unstable +> > dchroot. Of course you can only run these on Debian testing or +> > unstable due to the libc et.al dynamic dependencies. Is that the +> > problem? If any of this is close, please fill in a +> detailed way I can +> > reproduce the crash, or better yet, send a copy both to me +> and to the +> > Debian BTS. 'reportbug' is good for this. +> > +> > For the package to build, btw, the compiled axiom must successfully +> > run the full input test suite, so the very existence of the alpha +> > package means that this was done. You can find a log on +> > buildd.debian.org if interested. +> > +> > Take care, +> > +> > Bob McElrath writes: +> > +> > > Bill Page [bill.page1@sympatico.ca] wrote: +> > > > Hans, +> > > > +> > > > Do I understand correctly that after re-compiling Axiom that +> > > > you now have a fully operational LatexWiki system under debian +> > > > that can run Axiom? If so, congratulations! I think there are +> > > > a number of other people (including Tim Daly :) who would very +> > > > much like to setup a similar stand alone LatexWiki/Axiom system. +> > > +> > > And me! +> > > +> > > But we really need to have people setting this up in a +> chroot jail. I +> > > have been reading up on this...we need a script to create +> the jail. +> > > +> > > > I promised Tim that I would set something up for this, but I +> > > > have not yet had the time. If you have some time to write up a +> > > > short description of how you did it, I think it would be most +> > > > appreciated. +> > > +> > > I would like to distribute axiom support with LatexWiki. +> I have tied my +> > > version numbers to ZWiki, and they will release 0.35 on +> 10/1. Do you +> > > think we could add this by then? (or maybe a bit after +> to ensure 0.35 +> > > compatability) +> > > +> > > Bill our darcs repos have diverged, your patches no +> longer apply cleanly +> > > to latexwiki. I have moved the functions 'runCommand' +> and 'log' into +> > > util.py so that they can be used by axiom/reduce. There +> are a couple +> > > other conflicts too (I improved plone/stylesheet in +> latexwiki.css). Why +> > > do you have a font-size +2 in your latexwiki.css? Will +> you have time to +> > > merge this in the next week or two? +> > > +> > > FYI, I have gotten MathML/LatexWiki working in Plone:: +> > > +> > > http://mcelrath.org/Plone/ITeXTest +> > > +> > > You will need my zwiki patches to do that:: +> > > +> > > http://bob.mcelrath.org/darcs/zwiki +> > > +> > > Hopefully I will get those into ZWiki 0.35 but I haven't +> been able to +> > > get Simon's attention in the last couple of days. ;) As +> a reminder my +> > > latexwiki repo is here:: +> > > +> > > http://bob.mcelrath.org/darcs/latexwiki +> > > +> > > > Did you download the binary version of Axiom that failed from +> > > > debian unstable? If so, we should be sure to let Camm Maguire +> > > > know since he is the architect of the debian version. What +> > > > version of GCL are you using for the re-compile? What is the +> > > > hardware platform that you are using? +> > > +> > > Mine is a debian binary:: +> > > +> > > (0) dpkg -l axiom +> > > Desired=Unknown/Install/Remove/Purge/Hold +> > > | +> Status=Not/Installed/Config-files/Unpacked/Failed-config/Half- +> installed +> > > |/ Err?=(none)/Hold/Reinst-required/X=both-problems +> (Status,Err: uppercase=bad) +> > > ||/ Name Version Description +> > > +> +++-=================-=================-====================== +> ============================ +> > > ii axiom 0.20040831-1 A general +> purpose computer algebra system: main bi +> > > (0) axiom +> > > Segmentation fault +> > > +> > > This is the alpha architecture. +> > > +> > > If I understand correctly, GCL is compiled-in? I do not +> have gcl itself +> > > installed on this machine. + +\start +Date: Tue, 28 Sep 2004 21:11:51 +0200 +From: Hans Peter Wuermli +To: Camm Maguire +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: Bill Page , Bob McElrath + +Sorry, as the origin of the email exchanges I couldn't answer to any of the +questions (as I was abroad with the priviledge of not having had access to +email). + +Apparently, others than myself are interested in a standalone AxiomWiki. I +tried a long time to get the axiomWrapper running in ZWiki suspecting missing +access right and alike to be the cause for the failure. I run Debian testing +augmented by some Zope products which the Debian distribution does not have. +Downloading the latest Axiom source, compiling and using the executable got +everything running. As soon as I'll have time I will write down the details, +but frankly there were no secrets or tricks necessary. + +Cheers, H.P. + +On Monday 27 September 2004 03.15, you wrote: +> Greetings! My apologies, but I've lost the head of this thread. I'm +> assuming that there is a segfault problem with debian alpha axiom +> (unstable). (GCL is built in btw). I'm also assuming the problem +> shows up on startup. In this case, I cannot reproduce -- just +> downloaded the binaries and installed on escher.debian.org's unstable +> dchroot. Of course you can only run these on Debian testing or +> unstable due to the libc et.al dynamic dependencies. Is that the +> problem? If any of this is close, please fill in a detailed way I can +> reproduce the crash, or better yet, send a copy both to me and to the +> Debian BTS. 'reportbug' is good for this. +> +> For the package to build, btw, the compiled axiom must successfully +> run the full input test suite, so the very existence of the alpha +> package means that this was done. You can find a log on +> buildd.debian.org if interested. +> +> Take care, +> +> Bob McElrath writes: +> > Bill Page [bill.page1@sympatico.ca] wrote: +> > > Hans, +> > > +> > > Do I understand correctly that after re-compiling Axiom that +> > > you now have a fully operational LatexWiki system under debian +> > > that can run Axiom? If so, congratulations! I think there are +> > > a number of other people (including Tim Daly :) who would very +> > > much like to setup a similar stand alone LatexWiki/Axiom system. +> > +> > And me! +> > +> > But we really need to have people setting this up in a chroot jail. I +> > have been reading up on this...we need a script to create the jail. +> > +> > > I promised Tim that I would set something up for this, but I +> > > have not yet had the time. If you have some time to write up a +> > > short description of how you did it, I think it would be most +> > > appreciated. +> > +> > I would like to distribute axiom support with LatexWiki. I have tied my +> > version numbers to ZWiki, and they will release 0.35 on 10/1. Do you +> > think we could add this by then? (or maybe a bit after to ensure 0.35 +> > compatability) +> > +> > Bill our darcs repos have diverged, your patches no longer apply cleanly +> > to latexwiki. I have moved the functions 'runCommand' and 'log' into +> > util.py so that they can be used by axiom/reduce. There are a couple +> > other conflicts too (I improved plone/stylesheet in latexwiki.css). Why +> > do you have a font-size +2 in your latexwiki.css? Will you have time to +> > merge this in the next week or two? +> > +> > FYI, I have gotten MathML/LatexWiki working in Plone:: +> > +> > http://mcelrath.org/Plone/ITeXTest +> > +> > You will need my zwiki patches to do that:: +> > +> > http://bob.mcelrath.org/darcs/zwiki +> > +> > Hopefully I will get those into ZWiki 0.35 but I haven't been able to +> > get Simon's attention in the last couple of days. ;) As a reminder my +> > latexwiki repo is here:: +> > +> > http://bob.mcelrath.org/darcs/latexwiki +> > +> > > Did you download the binary version of Axiom that failed from +> > > debian unstable? If so, we should be sure to let Camm Maguire +> > > know since he is the architect of the debian version. What +> > > version of GCL are you using for the re-compile? What is the +> > > hardware platform that you are using? +> > +> > Mine is a debian binary:: +> > +> > (0) dpkg -l axiom +> > Desired=Unknown/Install/Remove/Purge/Hold +> > +> > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-insta +> > |lled / Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: +> > | uppercase=bad) +> > | +> > ||/ Name Version Description +> > +> > +> > +++-=================-=================-================================= +> >================= ii axiom 0.20040831-1 A general +> > purpose computer algebra system: main bi (0) axiom +> > Segmentation fault +> > +> > This is the alpha architecture. +> > +> > If I understand correctly, GCL is compiled-in? I do not have gcl itself +> > installed on this machine. + +\start +Date: Tue, 28 Sep 2004 12:38:41 -0700 +From: Bob McElrath +To: "Bill Page (E-mail)" +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: 'Camm Maguire' , 'Hans Peter Wuermli' , Bob McElrath + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] wrote: +> Bob McElrath supplied some details of the debian and +> axiom installation on his Alpha system which was still +> failing with a seg fault. +> +> Your suggested possible cause being "libc et.al dynamic +> dependencies" in the case of Bob's system seems plausible +> to me. I expect he will get back to you about this soon. + +alpha architecture: + ii libc6.1 2.3.2.ds1-11 GNU C Library: Shared libraries +axiom segfaults + ii libc6.1 2.3.2.ds1-16 GNU C Library: Shared libraries +axiom runs fine + +i386 architecture: + ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries +axiom runs fine + +Thus, it would appear that the debian package needs to add a dependency +on libc6 2.3.2.ds1-12 or greater. I do not know why on alpha it is +"libc6.1" and on intel it is "libc6". + +Hans, can you confirm on intel? + +\start +Date: Wed, 29 Sep 2004 01:02:01 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Dear Martin: + +Martin Rubey wrote: + +> "interpreting polynomials as functions" -> "use SUPs, please!" + +OK, I see what you meant: the variable in SUP is unspecified. But there is +really not that much difference between UP and SUP (UP is a special extension of +SUP, in fact UP == SUP add coerce: Variable(x)-> UP(x, R) +where coerce(v)== monomial(1,1) and another for coerce to outputform, printing +"x" instead of "?". So x is identified with ? under coerce for input, and ? is +printed as x on output. The only changes are in input/output. See also next +comment. + +[...] Regarding [equation] and [equal] : + +> I think you are right. When I get to it, I'll set up a MathAction page +> summarizing all this. + +That would be very much appreciated. But, perhaps no so fast: +Here is an example worth examining: + +supint:=monomial(1,1)$SUP(INT) +suppoly:=monomial(1,1)$SUP(POLY INT) +g:Boolean:= (supint = suppoly) + +The interpreter coerced supint:SUP(INT) to SUP(POLY INT) and then returns g as +true. Mathematically (see Lang, Algebra; more discussion later), supint is a +function from Variable(?)->INT with supint(?)=1$INT, and suppoly is a function +from Variable(?)->POLY INT, with suppoly(?)=1$(POLY INT), so as functions they +are different. The coercion means we identify supint with the composition supint +followed by the embedding INT->POLY INT (so that 1$INT is identified with +1$(POLY INT)). This is all mathematically acceptible. So for equality testing +a=b, coercion may be acceptable in certain cases, contrary to what I advocated +last time. I was thinking about the case where a:A, b:B and A is a subdomain of +B, but could not find an example where a=b is true as a statement in B, but b is +not in A. In the above example, A is the domain of functions from +Variable(?)->INT (or if you like, powers of the unspecified variable ?). +Similarly for B. So A is NOT a subdomain of B, but there is an embedding A -> B +induced by INT -> POLY INT. Of course, if we do make this identification, then +suppoly is in SUP(INT). (Axiom does allow this in the package SUP2(R,S)). + +suppoly::SUP INT + ? + +So I am no longer sure about banning all automatic coercions for [equal]. But I +don't know how else to avoid contradictions in Axiom if coercion remains the way +it works. + +upx:=monomial(1,1)$UP(x,INT) +g:= (supint = suppoly) + true +g:= (upx = supint) + true +g:= (upx = suppoly) + false + +Coercing to the common domain SUP POLY INT for the last test may be the cause +for the contradiction. More interestingly: + +upx * supint * suppoly + 2 + x ? + +supint * suppoly * upx + 2 + x? + +g:= (upx * supint * suppoly = supint * suppoly * upx) + false + +Exercise: try the other four permutations and predict the results. + +> ------------------------------------------------------------------------ +> Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this +> could be viewed as a polynomial. Of course, this argument is based on the idea +> that x=x, i.e, there shouldn't be different x's in one expression. +> +> I'm pretty sure that it is next to impossible to do this conversion +> consistently. For example: +> +> (14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT) +> +> (14) 1 +> Type: Fraction UnivariatePolynomial(x,Expression Integer) +> (15) -> x::UP(x, EXPR INT)/x::EXPR INT +> +> 1 +> (15) - x +> x +> Type: UnivariatePolynomial(x,Expression Integer) +> +> are both completely correct, given the strange semantics of UP(x, EXPR INT). + +The problem is caused by the user in (15). An undeclared x (as in "x ::") is +treated in the interpreter (you must declare for the compiler) as the unique +element of Variable(x). Any time such an x is coerced into UP(y, ?), it will +check if y is x, and if so, return the monomial x in UP(y,?), otherwise it tries +to coerce x into ? when possible, or gives an error if not. As I have pointed +out before, Axiom is not confused, the user is. Axiom cannot possibly rule out +such user behavior because each operation (x::UP(x,?), x::EXPR INT, and /) is +correctly performed. To do so would require Axiom to "look ahead" when +processing x::UP(x,?). This is unreasonable as well as impossible -- how far +ahead? what if the x::EXPR INT is something returned by another routine? + +I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now +stands.** Unfortunately, the general and categoric constructs in Axiom make it +difficult to "exclude" specific domains (POLY(R) is valid for any ring R; the +user is allowed to construct POLY(R) for whatever R, even if R is POLY(S). In +fact, I don't know of any Axiom mechanism to exclude specific domains in a +constructor's parameters. (Axiom allows declaring domains to HAVE certain +attributes, but I believe does not allow them to NOT HAVE certain attributes). + +Below, I'll try to analyse where the present problem lies and propose a way to +correct the problem. Even if you agree with my analysis, whether the correction +should be implemented or not is still subject to discussion. + +The problem lies in the original construction of POLY or EXPR: these domains +were meant to be user-friendly, they include any polynomial (or expression) in +whatever variables the user inputs. When a user is "lazy" and works in such +domains, it is implicitly assumed that (s)he is not aware of, or does not care +for, any particular data structure. So it is implicitly assumed that (s)he would +not extend such domains by adding more variables because these domains are +already all-encompassing as far as variables go (but the coefficient domain may +be extended to one that does not involve new variables). + +Now if we are to "generalize" the construction of POLY (and in fact the +construction of ANY domain with "variables," whether the set of "variables" is a +specific finite set of symbols or the set of all symbols), then we should go +back to the mathematical meaning of the polynomial ring (see Lang, Algebra, +1965). The set of indeterminates can be ANY set, so that towers like Q[S][T] is +mathematically meaningful for ANY sets S, T (even if S and T are the same set, +because the sets are only used to *index* the indeterminates: recall (Lang, p. +110) that a (primitive) monomial over S is a function f:S -> N (N the monoid of +non-negative integers) of finite support; and a polynomial ring over a ring R +with indeterminates (indexed by) S is the monoid algebra R[S] generated over R +by all (primitive) monomials. Normally, we would simply denote the variable +indexed by s: S by s, but this is "abuse of language" because the "variable" +indexed by s is actually a function and should be named f_s where f_s(s)=1 and +f_s(t) = 0 for t not equal to s. With this more pedantic notation, R[S] is +really $R[(f_s)_{s \in S}]$ (using TeX). So if after forming R[S], we want to +form R[S][T] where T = S, then by definition, a duplicate set of monomials +g:T->N is used and R[S][T] is $R[(f_s)_{s \in S}][(g_t)_{t \in T}]$ and no +confusion would arise even when S = T. (You may think of the row index set and +column index set of a square nxn matrix; both are [1..n], but we would use a +different notation say i for row and j for column. Anyone using i for both +indices, especially in programs, ...) + +Now the problem with the current implementation of any polynomial ring (or +Expression(R)) is that such duplicates are not anticipated (or ignored for +efficiency perhaps). If we were to generalize the construction by identifying +the "variables" with an indexed notation (for example, in R[x,y], the x and y +are actually (x,R) and (y,R); in programming terms, prefix or postfix x and y by +an identifier string unique to R much like C++), then we can create towers +without any ambiguity -- assuming no user would know these secret identifiers. +So "the set of all symbols" does not really mean ALL symbols but only those +within some limited constructive rule for symbols. In outputs, we may provide a +switch to turn the identifier part on or off. + +In the new generalized version: + +)set mess scope on + +x::UP(x,EXPR INT)/x::EXPR INT + +would output something like: + +x$UP(x, EXPR INT)/x$(EXPR INT) + +and not 1. The tags show the user exactly what is done without having to examine +the sometimes very long output from )set mess bot on. + +Let me say that there is pehaps a role for constructs like POLY POLY INT or POLY +EXPR INT. Examples: computing syzygies of polynomials generating an ideal, or +more generally the defining set of algebraic polynomial (equations) for +algebraic functions -- a (non-linear) system of differential equations is simply +algebraic equations for functions and their derivatives. However, just as POLY +INT is for the "lazy" user, so would the new POLY POLY INT. Any serious +computation should identify (and separate) the variables in towers. + +The utlimate question is: is it worth the trouble to generalize? If it is easy +to modify the compiler to add the identifiers, then that would be the easier +route. If not, I'll vote no unless someone shows me an example in a real +computation where this new type of construct is necessary, cannot be done +otherwise, and the benefit outweighs the work required. + +> I wouldn't think in terms of data representations yet. My credo: First +> determine good semantics, then worry about how to implement/represent +> them. +> +> > We need a clearer way to make the choice. Using a hidden and probably +> > unjustified convention that the "outer domain takes all the variables" +> > is questionable. +> +> I disagree: I am convinced that this convention is clear. The only other +> choice for me would be to depreciate these domains. + +Unfortunately, the current convention is not "outer domain takes all the +variables." + +)clear all +a:=monomial(1,1)$UP(x, INT) + x + +a::SUP INT + ? + +a::SUP UP(x,INT) + x + +Even though a tower of polynomial rings is involved in the above, these are +legitimate mathematical constructs (and correctly done) -- the unspecified +variable is intended to be transcendental over ANY coefficient domain, and is +often used to work with minimal polynomial of an element algebraic over the +coefficient domain. Here it shows that in coercing a variable into +SUP(R), the interpreter first try to coerce it into R, and failing that, to to +unspecified variable. So in this case, SUP only takes a variable when necessary. + +> > > The domain EXPR POLY INT would be strictly the same as EXPR INT, I +> > > think. +> +> > No, we are not talking about mathematics, but data structure. I think we +> > agree that the current semantics allowed is ambiguous and for this +> > reason, any reformating should be done with specific variables. +> +> I would like to have a mapping from maths to axiom as clear as possible. +> And given the convention that the "outermost" domain "takes" all the +> variables (it can), EXPR POLY INT and EXPR INT would be the same +> mathematically, since any polynomial is an EXPR. Of course, the +> representations could be different in the two domains. + +See above discussion on indexed method constructing polynomial rings. + +> I agree on everything you say about expressions with specified variables. + +Good, specified variables is the way to go. After all, what is strong typing +without specificity? + +> > > --------------------------------------------------------------------- +> +> I don't have anything clever to say right now about defining a wrapper of +> "variables" that has values in Any. +> +> If we want to follow the convention "outermost domain takes all variables +> it can" we can simply add a function "variables: % -> List Symbol" to +> QFCAT (or wherever it should go), since we only want to test for symbols +> right now. + +I am not convinced the convention is desirable. + +> Note that only the interpreter catches bogus like UP(x, UP(x, INT)) right +> now. It may be an option to change the interpreter rather than the +> library, but I think this is the wrong direction to go. BTW: Do you +> (or anybody else reading this) know how the interpreter catches this? +> In fact, it is broken anyway: +> +> (12) -> x::UP(x,UP(x,INT)) +> +> UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) is not a +> valid type. +> (12) -> monomial(1,1)$UP(x,UP(x,INT)) +> +> (12) x +> Type: UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) + +This is the same "error" you found some time ago, where somehow :: is handled +differently from : or coerce. In the second (12), the interpreter can find the +monomial function in $UP(x, *) and so it is happy -- never mind the *. In the +first (12), the interpreter must find the coerce function but don't know which +to pick, even if it did find them. If you packaged call, everything would be ok. + +(1) -> coerce(x)$UP(x, UP(x, INT)) + x +(2) -> degree % + 1 +(3) -> coerce(coerce(x)$UP(x, INT))$UP(x, UP(x, INT)) + x +(4) -> degree % + 0 + +I think the failure in (12) is an interpreter problem not able to find the +functions or cannot decide on what the user wants: (1) or (3). The error message +is an "error" in itself. UP(x, UP(x, INT)) seems a perfectly good domain in the +current Axiom system and the two x's are different (I believe in SUP, the +variable is indexed in the sense above; for SUPs with different coefficient +rings, these become equal only when coerced into a SUP with an extended +coefficient ring). This is the nature of SUP from which UP is derived. It's only +the user who assigns the same symbol for I/O, but shouldn't have. + +Generally, the Axiom compiler language is more precise and the interpreter +because it tries to be smart, does not always succeed in interpreting user +intentions. Nonetheless, it is still doing quite a good job. + +> Thus I think the direction to go is to put these checks into the compiler. + +I don't know enough about compilers: Can a compiler single out (12) to disallow +it? For now, just don't use the same symbol for two different things, and +perhaps fix the error message with a warning instead. + +> What would DPOLYCAT or DEXPR be? + +DPOLCAT already exists (Differential Polynomial Category, sorry for misspelling +of abbreviation -- actually a restriction of abbreviation rules in Axiom to 7 +characters to allow for DPOLCAT-). DEXPR would be Differential Expression (these +would involve derivatives or integrals of functions that could not be simplified +such as derivatives of Bessel functions, but also derivatives of other special +functions satisfying higher order differential equations). + +\start +Date: Wed, 29 Sep 2004 12:10:30 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Dear William, + +I'll only reply to the "mixing up variables" issue, since I do not have a clear +picture of the others yet. On the other hand, it seems to me that our +discussion is more about philosophy, since we agree that MEXPR(vars, Ring) is +the way to go. + +William Sit writes: + > Dear Martin: + > + > Martin Rubey wrote: + + > > Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this + > > could be viewed as a polynomial. Of course, this argument is based on the idea + > > that x=x, i.e, there shouldn't be different x's in one expression. + > > + > > I'm pretty sure that it is next to impossible to do this conversion + > > consistently. For example: + > > + > > (14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT) + > > + > > (14) 1 + > > Type: Fraction UnivariatePolynomial(x,Expression Integer) + > > (15) -> x::UP(x, EXPR INT)/x::EXPR INT + > > + > > 1 + > > (15) - x + > > x + > > Type: UnivariatePolynomial(x,Expression Integer) + > > + > > are both completely correct, given the strange semantics of UP(x, EXPR INT). + + > The problem is caused by the user in (15). An undeclared x (as in "x ::") is + > treated in the interpreter (you must declare for the compiler) as the unique + > element of Variable(x). Any time such an x is coerced into UP(y, ?), it will + > check if y is x, and if so, return the monomial x in UP(y,?), otherwise it + > tries to coerce x into ? when possible, or gives an error if not. As I have + > pointed out before, Axiom is not confused, the user is. + +Well, the result *is* confusing. And I don't think that this behaviour could be +useful. + + > Axiom cannot possibly rule out such user behavior because each operation + > (x::UP(x,?), x::EXPR INT, and /) is correctly performed. To do so would + > require Axiom to "look ahead" when processing x::UP(x,?). This is + > unreasonable as well as impossible -- how far ahead? what if the x::EXPR INT + > is something returned by another routine? + +I don't understand: it can! Well, I mean: it could. One possibility is the +following: every domain that has (named) variables should have a function vars: +R -> List Symbol and isvar?: Symbol -> Boolean. (I think the latter is not +strictly necessary: it should return true if the Symbol could be a variable in +the domain) Then coercions could be done as I suggested: + +if any?(isvar?, vars(thing)) + +then thing cannnot be regarded as a coefficient. + +I do admit that to integrate SUP into this picture might be tricky. + + > I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now + > stands.** Unfortunately, the general and categoric constructs in Axiom make + > it difficult to "exclude" specific domains (POLY(R) is valid for any ring R; + > the user is allowed to construct POLY(R) for whatever R, even if R is + > POLY(S). In fact, I don't know of any Axiom mechanism to exclude specific + > domains in a constructor's parameters. (Axiom allows declaring domains to + > HAVE certain attributes, but I believe does not allow them to NOT HAVE + > certain attributes). + +As it now stands, the way to do things is simple: don't use towers of domains +with variables. (One exeption is polynomials with coefficients that are +expressions not containing variables: we have to use POLY EXPR INT here...) + + > Below, I'll try to analyse where the present problem lies and propose a way + > to correct the problem. Even if you agree with my analysis, whether the + > correction should be implemented or not is still subject to discussion. + +Do I understand correctly: You propose (roughly) that variables should carry a +tag that tells which domain they belong to. + + > Let me say that there is pehaps a role for constructs like POLY POLY INT or + > POLY EXPR INT. Examples: computing syzygies of polynomials generating an + > ideal, or more generally the defining set of algebraic polynomial + > (equations) for algebraic functions -- a (non-linear) system of differential + > equations is simply algebraic equations for functions and their + > derivatives. + +Could you give an example here? I do not understand. + + > Unfortunately, the current convention is not "outer domain takes all the + > variables." + +Hmmm? I didn't say that it was. By the way, "the outer domain takes all the +variables" is an inprecise summary. That's why I added "it can" from time to +time... + +For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a +variable of the outer domain, y a coefficient. No confusion can arise. + +Maybe it would be better to say "a variable that can be taken by an outer +domain, cannot appear as a coefficient". To explain that (1/x)::POLY(EXPR INT) +should yield an error, note that the variable is x, not (1/x). + + > )clear all + > a:=monomial(1,1)$UP(x, INT) + > x + > + > a::SUP INT + > ? + +Note that this does not work in the compiler. You have to use makeSUP +expressively. And in fact, I think it shouldn't work in the interpreter either. + + > a::SUP UP(x,INT) + > x + + > Even though a tower of polynomial rings is involved in the above, these are + > legitimate mathematical constructs (and correctly done) -- the unspecified + > variable is intended to be transcendental over ANY coefficient domain, and + > is often used to work with minimal polynomial of an element algebraic over + > the coefficient domain. Here it shows that in coercing a variable into + > SUP(R), the interpreter first try to coerce it into R, and failing that, to + > to unspecified variable. So in this case, SUP only takes a variable when + > necessary. + +As an aside: towering SUP's is also an interesting issue. Consider + +makeSUP(y::UP(y,SUP INT)*x::UP(x,INT)) giving + (20) ? ? + Type: SparseUnivariatePolynomial SparseUnivariatePolynomial Integer + +Well, you know that. + + > > I would like to have a mapping from maths to axiom as clear as possible. + > > And given the convention that the "outermost" domain "takes" all the + > > variables (it can), EXPR POLY INT and EXPR INT would be the same + > > mathematically, since any polynomial is an EXPR. Of course, the + > > representations could be different in the two domains. + + > See above discussion on indexed method constructing polynomial rings. + +I agree that your proposal (if I understood it) is also clean. + + > > Thus I think the direction to go is to put these checks into the compiler. + + > I don't know enough about compilers: Can a compiler single out (12) to + > disallow it? For now, just don't use the same symbol for two different + > things, and perhaps fix the error message with a warning instead. + +I meant to say: "put these checks into the algebra." This is clearly possible. + +\start +Date: Wed, 29 Sep 2004 07:37:56 -0400 +From: "Page, Bill" +To: 'Martin Rubey' , 'Bob McElrath' +Subject: [Axiom-developer] literate programming pamphlet files for MathAction +Cc: "Bill Page \(E-mail\)" + +Martin (and others); + +I have started to document the work I am doing to implement +full Axiom pamphlet file support on MathAction. I hope to +have an test version of this extension available before the +weekend. + +There are few more notes and some examples here: + + http://test.axiom-developer.org/wiki/ConversionToHTML + +My approach is to use Norman Ramsey's Latex to HTML (l2h) +noweave filter. This filter together with noweave, is able +to produce HTML files directly from noweb (pamphlet) files. +l2h is written in Icon - so over the last couple of days +I had to learn yet another language. Icon is quite a tidy +fast and apparently well suited language for this sort of +complex conversion. I have modified and extended l2h so that +inline and display math environments as well as the axiom, +aldor and reduce pseudo-environments are passed straight +through the conversion. Now that I understand Icon and +thanks to Norman's literate programming style, I have also +added some missing things needed my first set of test files. + +The output of the modified l2h can then be given directly +to LatexWiki (or MathAction) as an HTML+LaTeX file. When +it is fully integrated into MathAction, the pamphlet file +itself will be stored and converted transparently using +noweave with the modified l2h filter when clicking Save. + +Please let me know if you have any questions or suggestions. +It will help motivate me to complete this work... :) + +\start +Date: Wed, 29 Sep 2004 13:59:44 +0000 +From: Martin Rubey +To: "Bill Page (E-mail)" +Subject: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: 'Bob McElrath' + +Dear Bill, + +great. + +Since you asked for suggestions, I have one (but it is low priority): It would +be even better if the entries in the table of contents were active links... + +Martin + +Page, Bill writes: + > Martin (and others); + > + > I have started to document the work I am doing to implement + > full Axiom pamphlet file support on MathAction. I hope to + > have an test version of this extension available before the + > weekend. + > + > There are few more notes and some examples here: + > + > http://test.axiom-developer.org/wiki/ConversionToHTML + > + > My approach is to use Norman Ramsey's Latex to HTML (l2h) + > noweave filter. This filter together with noweave, is able + > to produce HTML files directly from noweb (pamphlet) files. + > l2h is written in Icon - so over the last couple of days + > I had to learn yet another language. Icon is quite a tidy + > fast and apparently well suited language for this sort of + > complex conversion. I have modified and extended l2h so that + > inline and display math environments as well as the axiom, + > aldor and reduce pseudo-environments are passed straight + > through the conversion. Now that I understand Icon and + > thanks to Norman's literate programming style, I have also + > added some missing things needed my first set of test files. + > + > The output of the modified l2h can then be given directly + > to LatexWiki (or MathAction) as an HTML+LaTeX file. When + > it is fully integrated into MathAction, the pamphlet file + > itself will be stored and converted transparently using + > noweave with the modified l2h filter when clicking Save. + > + > Please let me know if you have any questions or suggestions. + > It will help motivate me to complete this work... :) + +\start +Date: Wed, 29 Sep 2004 13:22:43 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Martin Rubey wrote: + +> > Axiom cannot possibly rule out such user behavior because each operation +> > (x::UP(x,?), x::EXPR INT, and /) is correctly performed. To do so would +> > require Axiom to "look ahead" when processing x::UP(x,?). This is +> > unreasonable as well as impossible -- how far ahead? what if the x::EXPR INT +> > is something returned by another routine? +> +> I don't understand: it can! Well, I mean: it could. One possibility is the +> following: every domain that has (named) variables should have a function vars: +> R -> List Symbol and isvar?: Symbol -> Boolean. (I think the latter is not +> strictly necessary: it should return true if the Symbol could be a variable in +> the domain) Then coercions could be done as I suggested: +> +> if any?(isvar?, vars(thing)) +> +> then thing cannnot be regarded as a coefficient. + +But the two functions vars and isvar? are kind of available, perhaps not named +that way, but surely there are functions similar that serve the same purpose, if +all you want is to test whether a domain has "variables." For example, monomial, +degree, freeOf? You may have to do a more complicated test, but you can test +these right now. But I still do not see how the above test can rule out a +construction like EXPR EXPR INT. It's a catch-22 situation. I don't see any +action can be taken at compile time of the EXPR constructor other than put in +the code for the if-statement to run at instantiation (run) time. If EXPR EXPR +INT is encountered by the compiler, an outer version of the if-statment will be +compiled. So say your test returns false, assuming this test is executed at run +time when EXPR EXPR INT is instantiated, what is the then-clause? Can you first +instantiate the domain and then uninstantiate it? I think a simple error message +after this outer if-statement fails at instantiation time is not sufficient to +undo the instantiation; halting on error is not as good as catching this +construction at compile time. This would mean putting the rules for construction +into the grammar for the parser -- but the grammar does not know anything about +EXPR (or any specific constructor for that matter)! + +> +> I do admit that to integrate SUP into this picture might be tricky. +> +It sure would be. Even for the others, you have to make sure preventing +"illegal" towers will not break any code. "There is no such thing as a simple +job." + +> > I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now +> > stands.** Unfortunately, the general and categoric constructs in Axiom make +> > it difficult to "exclude" specific domains (POLY(R) is valid for any ring R; +> > the user is allowed to construct POLY(R) for whatever R, even if R is +> > POLY(S). In fact, I don't know of any Axiom mechanism to exclude specific +> > domains in a constructor's parameters. (Axiom allows declaring domains to +> > HAVE certain attributes, but I believe does not allow them to NOT HAVE +> > certain attributes). +> +> As it now stands, the way to do things is simple: don't use towers of domains +> with variables. (One exeption is polynomials with coefficients that are +> expressions not containing variables: we have to use POLY EXPR INT here...) + +That's a good example we have to be careful if we prohibit certain towers. But +that is not the only example. + +> > Below, I'll try to analyse where the present problem lies and propose a way +> > to correct the problem. Even if you agree with my analysis, whether the +> > correction should be implemented or not is still subject to discussion. +> +> Do I understand correctly: You propose (roughly) that variables should carry a +> tag that tells which domain they belong to. + +Yes. However, the tag is tied to the coefficient domain (which may have old +variables of its own), not the domain with (the new) variables. This corresponds +better to the mathematical notion of the "variables" ("algebraic indeterminates" +is the precise term) being algebraically independent over the coefficient +domain. + +> > Let me say that there is perhaps a role for constructs like POLY POLY INT or +> > POLY EXPR INT. Examples: computing syzygies of polynomials generating an +> > ideal, or more generally the defining set of algebraic polynomial +> > (equations) for algebraic functions -- a (non-linear) system of differential +> > equations is simply algebraic equations for functions and their +> > derivatives. +> +> Could you give an example here? I do not understand. + +Let's say I am hunting for two polynomials f(x), g(x) and I know they satisfy +some algebraic relations with coefficents that are polynomials. The polynomials +expressing these algebraic relations would then be in POLY POLY INT, such as + +h = a(x) y^3 + b(x) z^2 - c(x) + +where a, b, c are in POLY INT, and y, z when substituted by f, g would give +zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of +course, we know it would be better to use specified variables and work in +DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN +carry out these computations in POLY INT alone, but the more natural setting is +POLY POLY INT (for example, we may want to compute the grobner basis of the h's +in POLY POLY INT with POLY INT as coefficient domain. Relations like h(f,g) = 0 +are called a syzygies of (f,g) and are important computational objects in +algebraic geometry. If g(x) = df/dx, then h(f,g)=0 is a differential equation on +f(x). + +> +> > Unfortunately, the current convention is not "outer domain takes all the +> > variables." +> +> Hmmm? I didn't say that it was. By the way, "the outer domain takes all the +> variables" is an inprecise summary. That's why I added "it can" from time to +> time... + +Sorry, I misquoted. + +> For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a +> variable of the outer domain, y a coefficient. No confusion can arise. + +Yes, but you would disallow the prior use of x in POLY INT, which is where we +started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a +new indeterminate x over POLY INT. Tagging would distinguish this x from any +possible prior use of x. + +> Maybe it would be better to say "a variable that can be taken by an outer +> domain, cannot appear as a coefficient". To explain that (1/x)::POLY(EXPR INT) +> should yield an error, note that the variable is x, not (1/x). +> +> > )clear all +> > a:=monomial(1,1)$UP(x, INT) +> > x +> > +> > a::SUP INT +> > ? +> +> Note that this does not work in the compiler. You have to use makeSUP +> expressively. And in fact, I think it shouldn't work in the interpreter either. + +I don't know the mechanics of how the interpreter handles ::. We have seen it +uses at least more than one way (that is, it may use coerce, convert, and here, +makeSUP). I often don't know what map is used since ")set mess bot on" does not +always give output on "simple" things like this. However, we all know that the +compiler needs precise information, so if the interpreter is smart enough to use +makeSUP when :: is used, what's wrong with that? + +> > a::SUP UP(x,INT) +> > x +> +> > Even though a tower of polynomial rings is involved in the above, these are +> > legitimate mathematical constructs (and correctly done) -- the unspecified +> > variable is intended to be transcendental over ANY coefficient domain, and +> > is often used to work with minimal polynomial of an element algebraic over +> > the coefficient domain. Here it shows that in coercing a variable into +> > SUP(R), the interpreter first try to coerce it into R, and failing that, to +> > to unspecified variable. So in this case, SUP only takes a variable when +> > necessary. +> +> As an aside: towering SUP's is also an interesting issue. Consider +> +> makeSUP(y::UP(y,SUP INT)*x::UP(x,INT)) giving +> (20) ? ? +> Type: SparseUnivariatePolynomial SparseUnivariatePolynomial Integer +> +> Well, you know that. + +If we tag the variables, there will be no need for SUP using unspecified +variables and printing out ? all the time and the above I/O problem will go +away. + +> > > I would like to have a mapping from maths to axiom as clear as possible. +> > > And given the convention that the "outermost" domain "takes" all the +> > > variables (it can), EXPR POLY INT and EXPR INT would be the same +> > > mathematically, since any polynomial is an EXPR. Of course, the +> > > representations could be different in the two domains. +> +> > See above discussion on indexed method constructing polynomial rings. +> +> I agree that your proposal (if I understood it) is also clean. + +Thanks. I probably wrote too much! + +> > > Thus I think the direction to go is to put these checks into the compiler. +> +> > I don't know enough about compilers: Can a compiler single out (12) to +> > disallow it? For now, just don't use the same symbol for two different +> > things, and perhaps fix the error message with a warning instead. +> +> I meant to say: "put these checks into the algebra." This is clearly possible. + +Not clear to me at all! Perhaps I am missing the obvious. I believe it is going +to be a mess even if it is possible. It would be difficult to specify precisely +what towers are allowed or not. I think we should allow all towers and variables +should not be mixed (in any solution) and it is easier to do so with tags than +with tests. Tests are inefficient because it is a run-time penalty; while tags, +except at compile time, do not exert a penalty at all -- the symbol hash table +is the same, just the identifiers are longer. +Date: Wed, 29 Sep 2004 12:10:18 -0700 +From: Bob McElrath +To: "Bill Page (E-mail)" +Cc: zwiki@zwiki.org +Subject: [Axiom-developer] Re: literate programming pamphlet files for MathAction + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] wrote: +> Martin (and others); +> +> I have started to document the work I am doing to implement +> full Axiom pamphlet file support on MathAction. I hope to +> have an test version of this extension available before the +> weekend. +> +> There are few more notes and some examples here: +> +> http://test.axiom-developer.org/wiki/ConversionToHTML +> +> My approach is to use Norman Ramsey's Latex to HTML (l2h) +> noweave filter. This filter together with noweave, is able +> to produce HTML files directly from noweb (pamphlet) files. +> l2h is written in Icon - so over the last couple of days +> I had to learn yet another language. Icon is quite a tidy +> fast and apparently well suited language for this sort of +> complex conversion. I have modified and extended l2h so that +> inline and display math environments as well as the axiom, +> aldor and reduce pseudo-environments are passed straight +> through the conversion. Now that I understand Icon and +> thanks to Norman's literate programming style, I have also +> added some missing things needed my first set of test files. + +Let me suggest that you do this as a ZWiki "pagetype". (see pagetypes/ +in the ZWiki source) The relevant code for latexwiki is in the +__init__.py file. + +Each pagetype should define an input type and an output type. (and the +output type should almost always be html) + +> The output of the modified l2h can then be given directly +> to LatexWiki (or MathAction) as an HTML+LaTeX file. When +> it is fully integrated into MathAction, the pamphlet file +> itself will be stored and converted transparently using +> noweave with the modified l2h filter when clicking Save. +> +> Please let me know if you have any questions or suggestions. +> It will help motivate me to complete this work... :) + +Let me tell you what I have been doing, since it is very similar... + +ZWiki needs a huge rewrite of its page-rendering code. Right now it is +a big pile of regexes and because of this, one can find cases where it +will mangle pages. This is especially relevant for latex. I have +started this, and right now have a standalone code which does it +"properly". This is a subclass of StructuredText and uses that +machinery to render pages. + +Why this is relevant to you: + +When this is done I will start adding new page types. For me the first +will be "true" latex. But since this is all done within the +StructuredText system, new pagetypes (such as "spad") can *inherit* the +needed latex functionality from latexwiki. Thus we can combine our work +into new page types in ways that cannot mangle the document. + +The StructuredText classes are very simple. Basically for each text +"object" (like $math$) you have to write one function to recognize it +and one function to render it. In addition there is a list of which +"recognizers" have more importance than others, so you know what to do +with things like [foo $bar$] vs. $foo [bar]$ or -- which takes +properly with successive regexes that operate on the whole document. +That it works at all right now is a rather large hack involving +successive conversions to html, and ignoring html... + +This is not as good as a formally defined document grammar, but is +probably the best we can get with what we are doing. + +Join me on #zwiki at irc.freenode.net if you'd like to discuss this +further. I think we should discuss the "big scheme" before we head in +different directions and end up with a pile of incompatible software. + +I have placed my preliminary StructuredText classes here:: + + http://bob.mcelrath.org/WikiStructuredText + +along with a standalone example program showing how to use it. I hope +this should make it obvious how to extend. + +This will result in a more extensible, understandable, and robust +codebase. Not to mention faster. + +P.S. do I understand that MathAction is your website, and not a piece of +software? + +\start +Date: Thu, 30 Sep 2004 09:36:27 +0000 +From: Martin Rubey +To: Bob McElrath +Subject: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: zwiki@zwiki.org, "Bill Page \(E-mail\)" + +Yet another suggestion: + +In Axiom (and Aldor) code, there are two types of comments: -- and ++. + +The first tells the compiler to throw the comment away, the latter to keep +it. It seems that there are programs that can use these "descriptions", I +suppose Hyperdoc is one. More precisely: +++ tells the compiler that the +comment concerns the next name, ++ concerns the preceding name. + +I thus suggest a tiny bit of syntax highlighting: It would be great if the +++(+) comments would be printed a *little* differnent than the rest of the +code, maybe in italic or a different color. (Since the often contain code, they +need to be printed in the same font as code.) + +The -- comments often contain old code, so maybe a "lighter" face would be +appropriate. Those -- comments that explain the code will vanish and merge into +the pamphlet style documentation, I suspect. + + +\start +Date: Thu, 30 Sep 2004 10:24:32 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Hi Martin, + +It is not exactly clear what you want, but if it is just for the purpose +of editing .pamphlet files, there is already some support for Aldor code +edited in Emacs. See aldor.org or http://www.hemmecke.de/aldor. + +However, I don't like the #pile mode of Aldor/Axiom very much. This +might cause some problems with syntax highlighting. + +My mode even seems to work in connection with the Emacs noweb-mode, so +it should even highlight code within pamphlet files. You should put +something like this + +%EMACS Local Variables: +%EMACS mode: noweb +%EMACS noweb-code-mode: aldor-mode +%EMACS End: + +At the end of each pamphlet file or use other methods to convince Emacs +to load the right mode if it displays a .pamphlet file. + + +Jinlong Cai wrote another aldor-mode which is certainly +more advanced than mine, since it incorporates support for the Aldor +debugger. However, I haven't seen his mode openly available. + + + +There are some attempts to extract the ++ and +++ documentation from +Aldor .asy files and transform them finally to html. This goes under the +name AldorDoc, but is not very much advance yet. Unfortunately, Yannis +Chicha has no time to make progress with AldorDoc. + +But appart from syntax highlighting there is another question which is +still to be discussed. "What kind of structure should ++ comments have?" +Note that if these documentation comments are processed automatically, +there should be some tags so that the documentation compiler knows where +to link some names to or how to typeset certain pieces of the +documentation. Personally, I would very much like to get the +functionality of JavaDoc, but unfortunately ++ comments might become +unreadable in the .pamphlet file (which is undesirable). +But here people of Axiom and Aldor should work together so that they +come up with ONE nice suggestion and program that produces a online +version of the category hierarchy similar to JavaDoc or AlDoc (see +http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html) + +Aldoc (http://www-sop.inria.fr/safir/WHOSWHO/Manuel.Bronstein/) (in +contrast to AldorDoc) unfortunately does NOT use the ++ comments but +uses LaTeX code embedded in the .as files. + + +Ralf + +Martin Rubey wrote: +> Yet another suggestion: +> +> In Axiom (and Aldor) code, there are two types of comments: -- and ++. +> +> The first tells the compiler to throw the comment away, the latter to keep +> it. It seems that there are programs that can use these "descriptions", I +> suppose Hyperdoc is one. More precisely: +++ tells the compiler that the +> comment concerns the next name, ++ concerns the preceding name. +> +> I thus suggest a tiny bit of syntax highlighting: It would be great if the +> ++(+) comments would be printed a *little* differnent than the rest of the +> code, maybe in italic or a different color. (Since the often contain code, they +> need to be printed in the same font as code.) +> +> The -- comments often contain old code, so maybe a "lighter" face would be +> appropriate. Those -- comments that explain the code will vanish and merge into +> the pamphlet style documentation, I suspect. + +\start +Date: Thu, 30 Sep 2004 10:51:23 +0000 +From: Martin Rubey +To: Ralf HEMMECKE +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Hi Ralf, + +my suggestion concerns only the (future) presentation of pamphlet files on the +mathaction wiki. + +On the other hand, great that you are pointing out an aldor mode for emacs. If +this mode really supports pamphlet files, this would be pretty. + +Ralf HEMMECKE writes: + + > There are some attempts to extract the ++ and +++ documentation from + > Aldor .asy files and transform them finally to html. This goes under the + > name AldorDoc, but is not very much advance yet. Unfortunately, Yannis + > Chicha has no time to make progress with AldorDoc. + +In an ideal world, the documentation of Aldor and Axiom will be done with the +same tool. It seems to me, that the pamphlet + mathaction wiki approach is +quite sophisticated. + +Unfortunately it seems that quite some work has been done more than once. It +seems that aldoc and the pamphlet approach are quite similar. Maybe we could at +least reuse the aldoc latex class for Axiom... + + > "What kind of structure should ++ comments have?" Note that if these + > documentation comments are processed automatically, there should be some + > tags so that the documentation compiler knows where to link some names to or + > how to typeset certain pieces of the documentation. + +Yes. + + > Personally, I would very much like to get the functionality of JavaDoc, but + > unfortunately ++ comments might become unreadable in the .pamphlet file + > (which is undesirable). + +why do you think that they might become unreadable? + + > But here people of Axiom and Aldor should work together so that they + > come up with ONE nice suggestion and program that produces a online + > version of the category hierarchy + +Yes. + +\start +Date: Thu, 30 Sep 2004 11:27:02 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Dear Martin, + +> > Personally, I would very much like to get the functionality of JavaDoc, but +> > unfortunately ++ comments might become unreadable in the .pamphlet file +> > (which is undesirable). +> +> why do you think that they might become unreadable? + +In ++ comments one might wish to include some mathematical formulae. +Writing them in MathML makes the ++ comments unreadable. Many +mathematicians can read LaTeX these days, so I would prefer LaTeX here. +However, even the LaTeX style will not be there forever. + +I would agree on some XML like style, but this should come with an +editor that hides the tags and presents the things inside nicely. (I +know it is not well thought of.) + +Personally, I became familiar with noweb only recently, and it works +great. The \usepackage{srcltx} facility together with some newer dvi +viewers like kdvi or xdvi, let you 'inverse search' in the dvi file. +When you click at some place in the .dvi file, your editor opens and +points directly to the place in the .tex file. I have a modified version +of srcltx that jumps to the place in the corresponding .nw file instead +of the generated .tex file. I have simply replaced + +\def\src@@include#1#2{% + \src@before@file@hook{#2.tex}% + \src@include{#2}% + \src@after@file@hook{#1}% +} + +in srcltx 2004/05/15 v1.4 + +by + +\def\src@@include#1#2{% + \src@before@file@hook{#2}%--rhx: removed '.tex' extension + \src@include{#2}% + \src@after@file@hook{#1}% +} + +In connection to the extension rule of just adding .tex to the noweb file + + noweave FILE.nw > FILE.nw.tex + +this works quite nicely for me. + +But maybe this inverse-search facility is not necessary if pamphlet +files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no +experiences with the latter.) + +But still, the ++ code would remain untouched (and unformated) even in +the .dvi file (and thus maybe unreadable). So I have not quite made up +my mind of how to document in a structured way by using the ++ comments. + +\start +Date: Thu, 30 Sep 2004 11:38:24 +0000 +From: Martin Rubey +To: Ralf HEMMECKE +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Ralf HEMMECKE writes: + > Dear Martin, + > + > > > Personally, I would very much like to get the functionality of JavaDoc, but + > > > unfortunately ++ comments might become unreadable in the .pamphlet file + > > > (which is undesirable). + > > + > > why do you think that they might become unreadable? + > + > In ++ comments one might wish to include some mathematical formulae. + > Writing them in MathML makes the ++ comments unreadable. Many + > mathematicians can read LaTeX these days, so I would prefer LaTeX here. + +Why on earth would you write them in MathML? + + > However, even the LaTeX style will not be there forever. + +I doubt this. Well, for "forever" < 30 years, I'm pretty sure that LaTeX will +stay with us. + + + > I would agree on some XML like style + +I will not. + + > I have a modified version + > of srcltx that jumps to the place in the corresponding .nw file instead + > of the generated .tex file. I have simply replaced + > + > \def\src@@include#1#2{% + > \src@before@file@hook{#2.tex}% + > \src@include{#2}% + > \src@after@file@hook{#1}% + > } + > + > in srcltx 2004/05/15 v1.4 + > + > by + > + > \def\src@@include#1#2{% + > \src@before@file@hook{#2}%--rhx: removed '.tex' extension + > \src@include{#2}% + > \src@after@file@hook{#1}% + > } + + +very nice. + + > In connection to the extension rule of just adding .tex to the noweb file + > + > noweave FILE.nw > FILE.nw.tex + > + > this works quite nicely for me. + > + > But maybe this inverse-search facility is not necessary if pamphlet + > files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no + > experiences with the latter.) + +I suspect that small changes (like typos) will be done via MathAction +directly. Bigger changes will be done locally, and I will certainly use your +srcltx modification! Thanks! + + > But still, the ++ code would remain untouched (and unformated) even in the + > .dvi file (and thus maybe unreadable). + +I don't understand this. For postprocessing and editing, use +example.spad.pamphlet, for printing the example.spad.dvi, for browsing the +.pamphlet.spad.html output, for computing the example.spad format. All of them +will include the code of the spad (or aldor) file -- always human +readable. Except example.spad.pamphlet, all files are read only. + +\start +Date: Thu, 30 Sep 2004 12:06:39 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Hi Martin, + +> > In ++ comments one might wish to include some mathematical formulae. +> > Writing them in MathML makes the ++ comments unreadable. Many +> > mathematicians can read LaTeX these days, so I would prefer LaTeX here. +> +> Why on earth would you write them in MathML? + +What would you suggest? + +I am very much open to everything, even LaTeX, but there should be some +standard of how to document with ++ and this is missing currently! + +Would there be somebody else interested in this topic? Or would such a +discussion be too early? + +> > I would agree on some XML like style +> +> I will not. + +That was not a proposal. I just need some standard. And I was only +thinking of XML since there are more and more tools that can handle this. + +> > But still, the ++ code would remain untouched (and unformated) even in the +> > .dvi file (and thus maybe unreadable). + +> I don't understand this. For postprocessing and editing, use +> example.spad.pamphlet, for printing the example.spad.dvi, for browsing the +> .pamphlet.spad.html output, for computing the example.spad format. All of them +> will include the code of the spad (or aldor) file -- always human +> readable. Except example.spad.pamphlet, all files are read only. + +All ASCII files are human readable, but that is not the point. One can +certainly catch the information in $a_1^2$ quite quickly, but written in +MATHML this would take some while (at least for some unexperienced +person). This is what I mean by unreadable and why with an XML-like tag +form, there would be a need of an intelligent editor. + +\start +Date: Thu, 30 Sep 2004 12:22:00 +0000 +From: Martin Rubey +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Dear William, + +your point of view becomes clearer and clearer to me. I am nearly convinced :-) +In the following I'm only going to correct some apparent misunderstandings. + +William Sit writes: + > + > + > Martin Rubey wrote: + + > > every domain that has (named) variables should have a function vars: R -> + > > List Symbol and isvar?: Symbol -> Boolean. + > > + > > if any?(isvar?, vars(thing)) + > > + > > then thing cannnot be regarded as a coefficient. + > + > But the two functions vars and isvar? are kind of available, perhaps not named + > that way, but surely there are functions similar that serve the same purpose, if + > all you want is to test whether a domain has "variables." + +The important thing would be that all these functions would have the same name +and modeline. Otherwise I cannot test for them. The closest match is the +function variables. + + > But I still do not see how the above test can rule out a construction like + > EXPR EXPR INT. + +It wouldn't. In fact, EXPR EXPR INT would not be forbidden, only, the +coefficient domain would not be allowed to contain any variables. + +In fact, for EXPR EXPR INT, to clarify, lets denote this by EXPR COEFF, the +statement + +if any?(isvar?, vars(thing)) + +should always return false, i.e., the situation that Axiom tries to coerce +something that contains a variable to COEFF should never happen. If it does, I +misunderstood the coercion process. + +Thus, I do not propose to prevent the instantiation of domains. I only propose +to throw errors when Axiom is forced to do coercions that are not good. + + > > I do admit that to integrate SUP into this picture might be tricky. + > > + > It sure would be. Even for the others, you have to make sure preventing + > "illegal" towers will not break any code. + +I suspect you misunderstood me: my proposal does not make any towers +"illegal". Hence, it would not break any (well written) code. + + > > As it now stands, the way to do things is simple: don't use towers of + > > domains with variables. (One exeption is polynomials with coefficients + > > that are expressions not containing variables: we have to use POLY EXPR + > > INT here...) + > + > That's a good example we have to be careful if we prohibit certain + > towers. But that is not the only example. + +Again: following my proposal, POLY EXPR INT would not be prohibited. Quite the +contrary! + + > > Do I understand correctly: You propose (roughly) that variables should + > > carry a tag that tells which domain they belong to. + > + > Yes. However, the tag is tied to the coefficient domain (which may have old + > variables of its own), not the domain with (the new) variables. This + > corresponds better to the mathematical notion of the "variables" ("algebraic + > indeterminates" is the precise term) being algebraically independent over + > the coefficient domain. + +Good. If you rite up your proposal, maybe you could elaborate a bit on the +precise tagging. See below. + + > Let's say I am hunting for two polynomials f(x), g(x) and I know they + > satisfy some algebraic relations with coefficents that are polynomials. The + > polynomials expressing these algebraic relations would then be in POLY POLY + > INT, such as + > + > h = a(x) y^3 + b(x) z^2 - c(x) + > + > where a, b, c are in POLY INT, and y, z when substituted by f, g would give + > zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of + > course, we know it would be better to use specified variables and work in + > DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN + > carry out these computations in POLY INT alone, but the more natural setting + > is POLY POLY INT + +This is a nice example. I'd like to use it to raise an issue with your +proposal: suppose you have somehow generated h in POLY COEFF (where COEFF = +POLY INT, just to make it easier to talk about), such that y and z are +variables in POLY COEFF and a(x), b(x) and c(x) are coefficients, i.e., in +COEFF. + +The question is, how to multiply to such POLY COEFF's ? + +Suppose you ask for h*x. How would you instruct Axiom to understand the +multiplier x as an element of COEFF, and how would you instruct Axiom to +understand x as a variable in h? + +)set mess scope on + +h::(POLY POLY INT)*x::(POLY INT) + +-> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ... + +versus + +h::(POLY POLY INT)*x::(POLY POLY INT) + +-> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ... + +correct? + +Following my approach, you couldn't be *that* lazy. You'd have to say + +h::DMP([y,z], POLY INT). + +I realize right now, that I didn't consider POLY UP(x, INT) yet... As my +proposal is formulated right now, the coefficient domain would not contain any +variables. That's might not be that good, since POLY FRAC UP(x, INT) might be +an interesting domain. + + > > For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a + > > variable of the outer domain, y a coefficient. No confusion can arise. + > + > Yes, but you would disallow the prior use of x in POLY INT, which is where we + > started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a + > new indeterminate x over POLY INT. + +I wouldn't, but I see your point. + + > I don't know the mechanics of how the interpreter handles ::. We have seen + > it uses at least more than one way (that is, it may use coerce, convert, and + > here, makeSUP). I often don't know what map is used since ")set mess bot on" + > does not always give output on "simple" things like this. + +It would be really nice to have )set me bo on give output here too! I suspect +that the problem is that not all of the code is in the algebra, where I think +it should be. + + > > I agree that your proposal (if I understood it) is also clean. + > + > Thanks. I probably wrote too much! + +No. It is difficult to guess what I know or understand, and what needs +explaining. You did explain many things I knew, you did explain many things I +did not know... + + > > I meant to say: "put these checks into the algebra." This is clearly possible. + > + > Not clear to me at all! Perhaps I am missing the obvious. I believe it is + > going to be a mess even if it is possible. It would be difficult to specify + > precisely what towers are allowed or not. + +Yes. + + > I think we should allow all towers and variables should not be mixed (in any + > solution) and it is easier to do so with tags than with tests. + +Yes. However, we have to agree on one philosophy, I'm afraid. Would you be able +to write down as cleanly as possible the two proposals and add them add them at +the bottom of + +http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong + +? + +(Write a text file, click edit on the top right, paste, click save) + + > Tests are inefficient because it is a run-time penalty; + +True. + + > while tags, except at compile time, do not exert a penalty at all -- the + > symbol hash table is the same, just the identifiers are longer. + +True. + +\start +Date: Thu, 30 Sep 2004 12:31:36 +0000 +From: Martin Rubey +To: Ralf HEMMECKE +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +Ralf HEMMECKE writes: + > Hi Martin, + > + > > > In ++ comments one might wish to include some mathematical formulae. + > > > Writing them in MathML makes the ++ comments unreadable. Many + > > > mathematicians can read LaTeX these days, so I would prefer LaTeX here. + > > + > > Why on earth would you write them in MathML? + > + > What would you suggest? + +LaTeX. In the spad files, this is the way it is currently done: There are two +commands, \spad and \axiom, whose meaning I do not really now. Apart of this, +some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX +as possible. + + > I am very much open to everything, even LaTeX, but there should be some + > standard of how to document with ++ and this is missing currently! + > + > Would there be somebody else interested in this topic? Or would such a + > discussion be too early? + +I'd like to concentrate on making the two languages become one (i.e. Aldor) +first. + + > All ASCII files are human readable, but that is not the point. One can + > certainly catch the information in $a_1^2$ quite quickly, but written in + > MATHML this would take some while (at least for some unexperienced + > person). This is what I mean by unreadable and why with an XML-like tag + > form, there would be a need of an intelligent editor. + +Hence, don't use it. + +\start +Date: Thu, 30 Sep 2004 07:40:49 -0400 +From: root +To: martin.rubey@univie.ac.at, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, jcai3@uwo.ca, hemmecke@risc.uni-linz.ac.at + +Martin writes: + +> > In connection to the extension rule of just adding .tex to the noweb file +> > +> > noweave FILE.nw > FILE.nw.tex +> > +> > this works quite nicely for me. +> > +> > But maybe this inverse-search facility is not necessary if pamphlet +> > files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no +> > experiences with the latter.) +> +> I suspect that small changes (like typos) will be done via MathAction +> directly. Bigger changes will be done locally, and I will certainly use your +> srcltx modification! Thanks! + +I hope that, in the longer term, the mathaction wiki page presents the +original pamphlet file when you click 'edit'. That would imply running +noweb in the background when you click 'save'. The hard part, of course, +is that the change might actually fail, in which case there will be a +noweb msg or latex log file. + +If we could do this then it would be possible (at least technically) +to maintain axiom directly from the wiki pages. Of course there are +a lot of little steps along the way. I'd like to see the ability to +integrate CVS (or arch?) automatically into web page changes. + +Once mathaction can run stand-alone we plan to put it on a live-CD +and use it to 'front-end' a doyen system. Somewhere after that time +it would be interesting to be able to work on a page locally and then +"drag and drop" from your local browser tab (where you write/test) to +the mathaction tab on the host. At which point you could locally +develop a pamphlet for a conference and publish it to the mathaction +website. + +That said, I want to complement Bill on this excellent work. I spent +most of yesterday demonstrating the mathaction wiki to various +people at my university. Everyone is impressed. His work really +brings out the smiles as people begin to realize how potentially +useful this will be. In the long term this is going to define the +way computational science is done. Thanks, Bill. + +\start +Date: Thu, 30 Sep 2004 13:00:49 +0200 +From: Ralf HEMMECKE +To: Martin Rubey +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + +> > > > In ++ comments one might wish to include some mathematical formulae. +> > > > Writing them in MathML makes the ++ comments unreadable. Many +> > > > mathematicians can read LaTeX these days, so I would prefer LaTeX here. +> > > +> > > Why on earth would you write them in MathML? +> > +> > What would you suggest? +> +> LaTeX. In the spad files, this is the way it is currently done: There are two +> commands, \spad and \axiom, whose meaning I do not really now. Apart of this, +> some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX +> as possible. + +Well, is there some list of possible commands that are usable in ++ like +\axiom and \spad etc. What is their meaning. My hope would be that a +documentation compiler could even produce hyperlinks from certain tags. +Is this possible in Axiom? + +> I'd like to concentrate on making the two languages become one (i.e. Aldor) +> first. + +As far as I know there are 3 languages, all slightly different. +A Aldor +S SPAD +I Axiom interpreter language + +I could live with A \ne I, because the interpreter is there to make life +easier for the lazy user. For serious programming, however, Axiom should +use Aldor, not SPAD. I believe that SPAD and Aldor still differ in some +places, unfortunately. + +\start +Date: Thu, 30 Sep 2004 08:06:38 -0400 +From: root +To: hemmecke@risc.uni-linz.ac.at +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, jcai3@uwo.ca + +> > > In ++ comments one might wish to include some mathematical formulae. +> > > Writing them in MathML makes the ++ comments unreadable. Many +> > > mathematicians can read LaTeX these days, so I would prefer LaTeX here. +> > +> > Why on earth would you write them in MathML? +> +> What would you suggest? +> +> I am very much open to everything, even LaTeX, but there should be some +> standard of how to document with ++ and this is missing currently! + +I'm interested in this thread (though buried under a huge project in work +at the moment). The ++ and -- comments were part of the original +documentation mechanism. In the long term these will go away. The +code generated for the compiler won't contain documentation (since the +compiler doesn't care). There will be new environments in the pamphlet +file which will be standardized and automatically extracted. Standard +environments include \begin{testcase} for integrating .input file tests, +\begin{concept} for tagging the introduction of a new concept that needs +to be pushed into a semantic network (see the crystal discussion in the +history), etc. These stylized environments will, like \begin{list}, +probably have special sub-tags (like \testinput and \testresult so +testcases can automatically verify the results). + +++ and -- suffer from the usual problem of documentation. programmers +will not maintain documentation tags. mostly because almost nobody +but the programmer ever reads code. we tried to be clever about it +and make the comments "live" with hyperdoc (a pre-javadoc idea). +unfortunately it still suffers from the fact that embedded comments +are not the primary reason for a .spad file. I'm hoping that the +pamphlet file (which makes the documentation task primary and coding +secondary) will encourage computational mathematicians to actually +write papers that include working code and programmers to write real +papers that explain their algorithms. + +\start +Date: Thu, 30 Sep 2004 15:56:43 +0200 +From: Ralf HEMMECKE +To: daly@idsi.net +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, jcai3@uwo.ca + +>> I am very much open to everything, even LaTeX, but there should be +>> some standard of how to document with ++ and this is missing +>> currently! + +> I'm interested in this thread (though buried under a huge project in +> work at the moment). The ++ and -- comments were part of the original +> documentation mechanism. In the long term these will go away. + +Why should they go away? Is there a way in Axiom to produce a +hyperlinked category hierarchy? Such a hierarchy should be generated +from the actual CODE and not some latex documentation around. If then +there is some helpful documentation like the ++ comments that describe +the input/output parameters and approximately what the +domain/category/function is doing, this would greatly help programmers. + +I don't say that this should be the only documentation, but it should +not go away, because programmers need the exact interface of functions +in a compact way. Sometimes one knows what a function is doing, but not +exactly in which order the parameters go and what there exact +specification is. Putting this information away from the function code +is dangerous. + +Of course with noweb, one can do everything nicely, but the +documentation is lost for the Aldor compiler then. + +> The code generated for the compiler won't contain documentation +> (since the compiler doesn't care). + +This is NOT true for the Aldor compiler. Aldor compiles .as -> .ao -> .o +in a way so that the ++ comments are still extractable from the machine +independent .ao files. Leaving the ++ information in, would leave the +option of generating some type of documentation even from .al libraries +(a collection of .ao file) where the source code is not available. + +> There will be new environments in the pamphlet file which will be +> standardized and automatically extracted. Standard environments +> include \begin{testcase} for integrating .input file tests, +> \begin{concept} for tagging the introduction of a new concept that +> needs to be pushed into a semantic network (see the crystal +> discussion in the history), etc. These stylized environments will, +> like \begin{list}, probably have special sub-tags (like \testinput +> and \testresult so testcases can automatically verify the results). + +Speaking of testcases, you should have a look at AUnit. + +http://www.myjavaserver.com/~tmgisi/aldor-jsp/showPackage.jsp?id=1 + +Maybe this could be also useful for Axiom. Christian + took much effort to translate the JUnit +idea from Java to Aldor. I think he did great work. + +Christian, could you update your website with the newest version. On the +above site it is still AUnit0.0.1. + +> ++ and -- suffer from the usual problem of documentation. programmers +> will not maintain documentation tags. mostly because almost nobody +> but the programmer ever reads code. we tried to be clever about it +> and make the comments "live" with hyperdoc (a pre-javadoc idea). +> unfortunately it still suffers from the fact that embedded comments +> are not the primary reason for a .spad file. I'm hoping that the +> pamphlet file (which makes the documentation task primary and coding +> secondary) will encourage computational mathematicians to actually +> write papers that include working code and programmers to write real +> papers that explain their algorithms. + +I agree to a certain extend, but not completely. The pamphlet idea is +wonderful, but the paper-style text is quite unhandy as a reference +manual. An additional documentation like, for example, + +http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html + +would be desirable. Or can this be done already with AXIOM? + +\start +Date: Thu, 30 Sep 2004 08:26:55 -0700 +From: Bob McElrath +To: Ralf HEMMECKE +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai + + +Ralf HEMMECKE [hemmecke@risc.uni-linz.ac.at] wrote: +> But maybe this inverse-search facility is not necessary if pamphlet +> files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no +> experiences with the latter.) + +That is an interesting idea...I will have to try that in my latex +papers. + +I discovered recently that one can use:: + + + +To get a double click anywhere in the page to open up the LatexWiki edit +form. All that is required for what you suggest is to also position the +cursor. + +\start +Date: Thu, 30 Sep 2004 10:25:44 -0400 +From: Tim Daly +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] literate programming pamphlet files for MathAction + +Ralf, + +re: Why should ++ comments go away? + +There were actually 3 distinguished levels: + ++ and +++, an idea +lifted from lisp's use of ; ;; and ;;; comments. The idea was a +poor-man's way of doing \section, \subsection, and \subsubsection kind +of commenting with some cheesy syntax. Later we added keywords, special +tags (like \axiom) and function signature comments. + +The problems are apparent and, as one of the original developers and +the primary author of most of the bad signature comments, I can see +the flaws. I'll contrast them with the pamphlet mechanism. + +First, ++ comments are a cheap imitation of tex. You can include certain +macros like \axiom in them and certain magic post processing occurs. +What this set of magic tags are, why they are there, and how they affect +the presentation later is not clearly documented. There is a limited set +and, unless you wrote the original mechanism (i.e. are me) it is very +hard to extend. + +Pamphlet files let you use the full power of tex, including hyperlinking +packages and, now noweb and a browser. Thus we gain 4 benefits. + (a) the world understands tex so no documentation of the tags is needed, + (b) the mechanism is entirely general so anyone can make their own tags, + (c) less code needs to be maintained, and + (d) it all works with general purpose tools (mathaction, browser, etc). + +Second, ++ comments live in files intended to be fed to a compiler. As a +programmer I develop my own style of coding and, unless the compiler +enforces some syntax, I will do things my own way. In fact, to try to +overcome this problem you'll notice that the compiler actually complains +if either the ++ comments are improperly indented or they are missing. +I wrote the code that enforces that because I know programmers. But, +frankly, it still fails because the mindset is still to "make it work". +Thus programmers discovered that ++ comments can be complete nonsense +and the compiler will shut up. So I added a check for certain tags. +Same result. We shouldn't feed the compiler anything it can't use. +(With some cleverness we COULD define a function that could allow a +program to reference its own pamphlet at runtime. This might be useful) + +Pamphlet files change the emphasis from programming to writing a document. +You not only have to satisfy the compiler you also have to satisfy noweb +and tex (and l2h, etc). Thus, the emphasis is on creating a document. For +a programmer this is awkward. But pamphlet files are intended for doing +computational science which is a very specialized area of programming. +Once I got my old code back after 15 years I realized that unless we +keep the theory with the code there is no hope of maintaining, modifying, +and extending these heavy science systems. Pamphlet files are intended +to make sure we can. + +Third, you comment that "the ++ comments would greatly help programmers" +The pamphlet files are intended to satisfy what appear to be +a couple audiences, some of which are programmers who don't know the +science and some of which are scientists who don't program. I believe +that we are on the cusp of a new group of people that I refer to as +computational scientists. They are cross trained in both programming and +their particular science. Maintaining special, outdated, weak, and painful +syntax "for the programmers" is not helpful. + +Pamphlet files need some "canonical examples". I have permission to use +a couple phd thesis documents, technical papers that have algorithm +descriptions, proofs, complexity analysis, etc, sections of books and +other document sources. The idea is to "set the standard" for what we +can expect from a full, professionally documented, scientifically sound, +document with execution semantics. This will evolve over time as we add +new functionality (a test harness, a semantic network, drag and drop +installation, etc). + +Fourth, you mention that sometimes a programmer just wants the documentation +of the arguments. There is no reason why we need special syntax for this +and, as mentioned above, the previous programmers did not provide this. +The Axiom compiler does extract this type information while compiling. See +)show Integer +for an example of the output. + +Pamphlet files allow tagging of arguments in such a way that we could +construct automatic hyperlinks for arguments. And the hyperlinks would +go to other pamphlet files so that not only the type of the argument is +apparent but the rational for the choice is available. + +Fifth, you said "This is NOT true for the Aldor compiler". Currently the +Aldor compiler will process ++ comments and pass them along... to nothing. + +Pamphlet files will work with Aldor code. There is no language restriction +on noweb files (which is why I chose noweb rather than, say, CWeb). If you +look at the Axiom sources virtually every file is a pamphlet file including +lisp, c, boot, makefiles, etc. Thus making a pamphlet file using Aldor is +already supported. And all of the magic that MathAction will support is +automatic. The Aldor compiler should not know about comments. + +Sixth, you reference the javadoc-like documentation style +(http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html) + +Pamphlet files can contain this information and it can be parsed out +either with noweb, tex, l2h, etc. However, I'd expect that the original +pages in the pamphlet .dvi file can not only contain this information but +format it in a similar way if you so desire with additional information. +Bill Page's MathAction approach also allows multiple people to contribute +a wide rand of expertise to the documentation (for instance, the web page +you reference has a typo which I could fix if it were on a wiki). + +As for hierarchical information the src/algebra/Makefile.pamphlet contains +the current lattice of types. This information is waiting for someone to +exploit it. Bill and I have both looked at it in the past. Perhaps it will +get integrated into the MathAction site in some reasonable way. + +This is a long winded way of saying that I believe literate documents +(if not exactly pamphlet files) are the way forward not just for Axiom +but for scientific systems in general. The whole Axiom library, while +in pamphlet files now, needs better documentation. The current +"canonical example", which still needs much more work, is +dhmatrix.spad.pamphlet. + +I know it all seems like a lot of work but we are at the beginning of +the collision of computing with science. If we go back to the last +century and look at math proofs from that time they seem like just so +much handwaving compared to the standards of proofs today. In 30 years +lightly commented source code with ++ and -- will seem unprofessional. +Algorithms will be expected to have termination proofs, correctness +proofs, examples, test cases, complexity analysis, working source code +and a sound basis in theory in order to pass as professional +scientific work. + +All of which is clearly just my opinion on the subject. But at least +this will give you some idea why I believe ++ comments will die. + +\start +Date: Thu, 30 Sep 2004 09:18:06 -0700 +From: Bob McElrath +To: Martin Rubey +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Yannis Chicha , Jinlong Cai , Ralf HEMMECKE + +Martin Rubey [martin.rubey@univie.ac.at] wrote: +> Ralf HEMMECKE writes: +> > What would you suggest? +> +> LaTeX. In the spad files, this is the way it is currently done: There are two +> commands, \spad and \axiom, whose meaning I do not really now. Apart of this, +> some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX +> as possible. + +This is the goal of LatexWiki. The idea is to have a text format that +has markup that is as natural as possible. If you are not familiar with +StructuredText, take a look at:: + + http://mcelrath.org/Notes/StructuredTextRules + +I have added basic latex math components like $$, \[\] and +\begin{equation}...\end{equation}. StructuredText is used by the python +and zope projects for their in-code documentation. It might also be +appropriate for Axiom. + +As I mentioned elsewhere, StructuredTextLatex will soon be available +standalone, so axiom/aldor users need not run all fo zope and zwiki to +look at the source docs. It will generate either HTML+images for +equations or XHTML+MathML. + +\start +Date: Thu, 30 Sep 2004 09:25:04 -0700 +From: Bob McElrath +To: root +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, bill.page1@sympatico.ca, jcai3@uwo.ca, hemmecke@risc.uni-linz.ac.at + +root [daly@idsi.net] wrote: +> I hope that, in the longer term, the mathaction wiki page presents the +> original pamphlet file when you click 'edit'. That would imply running +> noweb in the background when you click 'save'. The hard part, of course, +> is that the change might actually fail, in which case there will be a +> noweb msg or latex log file. + +Right now tha page is not rendered and an error is printed at the bottom +of the page when you view it. Ideally, this integration should be +tighter. Perhaps a "test" button that could pop up the rendered page? + +> If we could do this then it would be possible (at least technically) +> to maintain axiom directly from the wiki pages. Of course there are +> a lot of little steps along the way. I'd like to see the ability to +> integrate CVS (or arch?) automatically into web page changes. + +This was mentioned before... + +Zope has a rudimentary "change history" that can be used to undo bad +changes, but it is crude as a versioning system. + +There is also a Zope product called FileSystemSite in which your site +is stored in a directory on the filesystem, rather than in the ZODB. +Such a directory can simultaneously be a CVS/arch/darcs repository. +Presumably it wouldn't be that hard to get Zope/ZWiki/LatexWiki to +ignore the CVS directory. + +\start +Date: Thu, 30 Sep 2004 13:23:16 -0400 +From: William Sit +To: Martin Rubey +Subject: [Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions) + +Hi Martin: + +Martin Rubey wrote: + +> > But the two functions vars and isvar? are kind of available, perhaps not named +> > that way, but surely there are functions similar that serve the same purpose, if +> > all you want is to test whether a domain has "variables." +> +> The important thing would be that all these functions would have the same name +> and modeline. Otherwise I cannot test for them. The closest match is the +> function variables. + +Having the same function names and modeline of course simplifies the predicate. +What I meant was at the expense of a more complicated predicate, you can +currently make the same test without the new functions. But what you gain in the +(code) efficiency of the predicate, you pay for by adding the functions to +multiple domains. + +> > But I still do not see how the above test can rule out a construction like +> > EXPR EXPR INT. +> +> It wouldn't. In fact, EXPR EXPR INT would not be forbidden, only, the +> coefficient domain would not be allowed to contain any variables. + +In my opinion, I think that (coefficient domain EXPR INT not allowed to have any +variables) is too drastic. Perhaps because of this view, I misunderstood you +intention was to forbid such towers through testing the presence of isvar? etc. + +> In fact, for EXPR EXPR INT, to clarify, lets denote this by EXPR COEFF, the +> statement +> +> if any?(isvar?, vars(thing)) +> +> should always return false, i.e., the situation that Axiom tries to coerce +> something that contains a variable to COEFF should never happen. If it does, I +> misunderstood the coercion process. + +Given that the test is categorically included in the constructor EXPR, if it +always return false for EXPR COEFF, it would also have to return false in COEFF += EXPR INT. No? You did not specify where this "if" statement resides. + +I don't know if there are any statement that will make Axiom coerce something +that contains a variable to COEFF, but I have shown you examples where a +variable is coerced into COEFF = POLY INT of SUP(COEFF). So yes, "it does," but +may be it still "should never happen." The "coercion process" is an entirely +interpreter process because it is trying to be "smart" for "lazy" users. I don't +understand how this is done (will have to ask Bob Sutor, or look at source +code). What I am (guess, we are) doing is observe what it does and trying to +infer how it does things. It may be what the Chinese call "the blind men feeling +an elephant." (which means each only gets part of the picture, depending on +where one place his hand). + + +> +> Thus, I do not propose to prevent the instantiation of domains. I only propose +> to throw errors when Axiom is forced to do coercions that are not good. + +Can you please explain step by step how the "if" line will be called into action +when Axiom is so forced after a tower is instantiated? + +> > > I do admit that to integrate SUP into this picture might be tricky. +> > > +> > It sure would be. Even for the others, you have to make sure preventing +> > "illegal" towers will not break any code. +> +> I suspect you misunderstood me: my proposal does not make any towers +> "illegal". Hence, it would not break any (well written) code. + +My mistake. But you changed the semantics of the tower. Almost by definition, +any code that can be ambiguous/confusing to the reader is not well written. If +such code exists in the library, we should find them and rewrite them. Adding +code to prevent bad code is difficult, because you can never catch all of them. +(This reminds me of programs that attempts catch students' math mistakes. The +programmers (me included) are never as ingenious as the students.) + +> > > As it now stands, the way to do things is simple: don't use towers of +> > > domains with variables. (One exeption is polynomials with coefficients +> > > that are expressions not containing variables: we have to use POLY EXPR +> > > INT here...) +> > +> > That's a good example we have to be careful if we prohibit certain +> > towers. But that is not the only example. +> +> Again: following my proposal, POLY EXPR INT would not be prohibited. Quite the +> contrary! +> +> > > Do I understand correctly: You propose (roughly) that variables should +> > > carry a tag that tells which domain they belong to. +> > +> > Yes. However, the tag is tied to the coefficient domain (which may have old +> > variables of its own), not the domain with (the new) variables. This +> > corresponds better to the mathematical notion of the "variables" ("algebraic +> > indeterminates" is the precise term) being algebraically independent over +> > the coefficient domain. +> +> Good. If you rite up your proposal, maybe you could elaborate a bit on the +> precise tagging. See below. +> +> > Let's say I am hunting for two polynomials f(x), g(x) and I know they +> > satisfy some algebraic relations with coefficents that are polynomials. The +> > polynomials expressing these algebraic relations would then be in POLY POLY +> > INT, such as +> > +> > h = a(x) y^3 + b(x) z^2 - c(x) +> > +> > where a, b, c are in POLY INT, and y, z when substituted by f, g would give +> > zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of +> > course, we know it would be better to use specified variables and work in +> > DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN +> > carry out these computations in POLY INT alone, but the more natural setting +> > is POLY POLY INT +> +> This is a nice example. I'd like to use it to raise an issue with your +> proposal: suppose you have somehow generated h in POLY COEFF (where COEFF = +> POLY INT, just to make it easier to talk about), such that y and z are +> variables in POLY COEFF and a(x), b(x) and c(x) are coefficients, i.e., in +> COEFF. +> +> The question is, how to multiply to such POLY COEFF's ? +> +> Suppose you ask for h*x. How would you instruct Axiom to understand the +> multiplier x as an element of COEFF, and how would you instruct Axiom to +> understand x as a variable in h? +> +> )set mess scope on +> +> (1) h::(POLY POLY INT)*x::(POLY INT) +> +> -> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ... +> +> versus +> +> (2) h::(POLY POLY INT)*x::(POLY POLY INT) +> +> -> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ... +> +> correct? + +I suppose you are asking how the interpreter can discern the meaning of h*x. +Under the tag proposal, x is already bound and tagged as x$(COEFF) by the prior +use of a(x): COEFF, and h: POLY COEFF is also bound (note that I am not using +::). So h*x (not h:: POLY COEFF * x:: COEFF) has unambiguous meaning. If you +insist on using :: as given, then both coercions in (1) are unnecessary, and the +first coercion in (2) for h is unnecessary while the coercion x::POLY COEFF +would be the natural coercion (that is COEFF as subdomain of POLY, similiar to +saying 3::POLY INT); the multiplication would be the multiplication in POLY +COEFF, but since x is in COEFF, this is scalar multiplication (similar to 3*t in +POLY INT). In other words, both (1) and (2) produce same result and uses the +same scalar multiplication. The "scoped" output you gave for (2) is incorrect in +that the notation x$(POLY COEFF) means a (tagged) variable x of the outer POLY, +so it is a different x. + +Perhaps if you change your question to simply how to coerce 'w, where 'w:Symbol, +to POLY COEFF and to COEFF, it would illustrate what is needed better (at least +one less confusion). (I'll drop the ' before w now, having made clear that w is +"virgin"). The solution is quite simple in fact (and you'll like this): having +all existing variables clearly tagged, we can assign a virgin symbol using your +outer rule! So + +(3) w::POLY POLY INT + -> w$(POLY COEFF) +(4) w::POLY INT + -> w$COEFF + +Of course, I am only using COEFF to clarify where w belongs. But this is really +not necessary because the way tags are *output* adopts your "outer" convention +in the sense that the variable always belong to the Varset of the outermost +domain (not that it "takes" from the inner domains). To avoid confusion, I will +refer to this as the "outer output" convention. *Internally*, w$COEFF may be a +concatenation of a hash for w and a hash for INT (as a variable over INT) and +w$(POLY COEFF) would be a concatenation of the hash for w and a hash for COEFF. + +Note that this method of tagging (to the coefficient domain and not the +polynomial ring) allows for "mixing" or lifting. If a user wants to have UP(w, +INT), that w would also be the *same* as the w in POLY INT and coercion between +the two domain is a breeze because in both case, it is actually the same symbol +(concatenation of hash for w and hash for INT). If the user wants UP(w, COEFF) +this w would be the same as the w in POLY COEFF. Again this is all natural when +we say, mathematically, let w be an indeterminate (or transcendental) over INT +-- mathematicians DON'T care which polynomial ring w belongs to! (too bad Axiom +cares). Just another example to clarify: + + w$(POLY COEFF)::UP(w, COEFF) is perfectly ok. + + w$(POLY COEFF)::UP(w, INT) is ok too + +(because w transcendental over COEFF=POLY INT is a fortiori transcendental over +INT) + + w$(POLY INT)::UP(w, COEFF) becomes a ground element + + Note again: w$(POLY INT) is NOT w$(UP(w, COEFF)) because the transcendental w +over INT is not necessarily transcendental over COEFF=POLY INT --in fact in this +example, it belongs to COEFF. + +> Following my approach, you couldn't be *that* lazy. You'd have to say +> +> h::DMP([y,z], POLY INT). + +Wouldn't you rather be lazier? :-) + +> I realize right now, that I didn't consider POLY UP(x, INT) yet... As my +> proposal is formulated right now, the coefficient domain would not contain any +> variables. That's might not be that good, since POLY FRAC UP(x, INT) might be +> an interesting domain. + +According to your "outer" rule, POLY UP(x, INT) would be the same as POLY INT, +and POLY FRAC UP(x, INT) would be POLY FRAC INT. So there would be no reason to +use the towers, except that the towers may be constructed "after the fact" (that +UP(x, INT) was already used in previous computations). This is exactly what I +meant by your rule, if implemented, would forbid prior use (though not the tower +itself). + +> > > For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a +> > > variable of the outer domain, y a coefficient. No confusion can arise. +> > +> > Yes, but you would disallow the prior use of x in POLY INT, which is where we +> > started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a +> > new indeterminate x over POLY INT. +> +> I wouldn't, but I see your point. + +What do you mean "I wouldn't"? Even under your approach, x is a new +indeterminate over POLY INT because POLY INT cannot contain x! + +> > I don't know the mechanics of how the interpreter handles ::. We have seen +> > it uses at least more than one way (that is, it may use coerce, convert, and +> > here, makeSUP). I often don't know what map is used since ")set mess bot on" +> > does not always give output on "simple" things like this. +> +> It would be really nice to have )set me bo on give output here too! I suspect +> that the problem is that not all of the code is in the algebra, where I think +> it should be. + +I agree that it is likely the interpreter has magic code, but I don't see how +such code be in the algebra (spad source). Because users are lazy, the +interpreter has to make the choice or guess the choice of which (often +overloaded) function the user wants. In the algebra code, you can't be lazy or +it won't compile! Sometimes I do wish the compiler gets some of the IQ from the +interpreter, it would have saved a lot of time -- when stuck with a problem on +coercion, I often go to the interpreter for help using )set mess bot on. + +> > > I agree that your proposal (if I understood it) is also clean. +> > +> > Thanks. I probably wrote too much! +> +> No. It is difficult to guess what I know or understand, and what needs +> explaining. You did explain many things I knew, you did explain many things I +> did not know... +> +> > > I meant to say: "put these checks into the algebra." This is clearly possible. +> > +> > Not clear to me at all! Perhaps I am missing the obvious. I believe it is +> > going to be a mess even if it is possible. It would be difficult to specify +> > precisely what towers are allowed or not. +> +> Yes. +> +> > I think we should allow all towers and variables should not be mixed (in any +> > solution) and it is easier to do so with tags than with tests. +> +> Yes. However, we have to agree on one philosophy, I'm afraid. Would you be able +> to write down as cleanly as possible the two proposals and add them add them at +> the bottom of +> +> http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong +> + +I visited your page and it is taken from your posts. However, we have posted +back and forth and as you said, comments cannot be taken out of context and in +email, we quote each other. I don't know how to do that in mathaction. + +I could be wrong, but my impression is that the attractiveness of mathaction +pages is that you can run live Axiom code and it is browser based. So I think it +is an ideal platform for documentation or summaries with examples, but a rather +poor platform for casual discussion. For example, one can only add comments at +the bottom, making it difficult to refer to lines or codes on the page. But even +if it becomes more fancy like MS Word, where you can insert comments anywhere, +the page would not be "clean". Despite the extra effort, in order that someone +not familiar with the issues can follow, the pages have to be tutorial in style. +And that takes rewriting. +I don't know how detail or how brief I should write (that is, who will be the +readers?) + +> +> (Write a text file, click edit on the top right, paste, click save) + +I don't like text files and much prefer LaTeX to get pdf or dvi output. Lots of +text editors don't have good line breaks (or paragraph reflow) and arbitrarily +change them (like most email programs). Is text file the only choice? + +The text file would have to include Axiom code fragments as examples. I don't +know how to get "live" axiom with mathaction, the way your pages look. + +Well, I think this is truely a joint effort and fruitful discussion. I wouldn't +have thought of the problem (or proposal) if you didn't raise it. So, thanks. + + +\start +Date: Thu, 30 Sep 2004 13:46:06 -0400 +From: Stephen Wilson +To: Ralf HEMMECKE +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction + +On Thu, Sep 30, 2004 at 10:24:32AM +0200, Ralf HEMMECKE wrote: + +> Jinlong Cai wrote another aldor-mode which is certainly +> more advanced than mine, since it incorporates support for the Aldor +> debugger. However, I haven't seen his mode openly available. +> + +Hello, + +Actually, Jinlong did not write the Aldor emacs mode of which you +speak. That was my work, and I simply gave him the code to use during +his ISSAC demo of the Aldor debugger. + +This aldor mode is not currently on aldor.org since I wrote it with +GNU/Emacs in mind, and have found XEmacs to have a few problems +dealing with the elisp. One I can support both emacs's, it will appear +on aldor.org. + +If anyone would like a copy, just email me and I'll gladly send you +it. The code is GPL'ed and I fully intend it to be available to all. + +\start +Date: Thu, 30 Sep 2004 21:29:00 +0200 +From: Ralf HEMMECKE +To: Stephen Wilson +Subject: Re: [Axiom-developer] Re: literate programming pamphlet files for MathAction + +Stephen, + +Please accept my apologies for mixing the names. + +Ralf + +Stephen Wilson wrote: +> On Thu, Sep 30, 2004 at 10:24:32AM +0200, Ralf HEMMECKE wrote: +> +> +>>Jinlong Cai wrote another aldor-mode which is certainly +>>more advanced than mine, since it incorporates support for the Aldor +>>debugger. However, I haven't seen his mode openly available. +>> +> +> +> Hello, +> +> Actually, Jinlong did not write the Aldor emacs mode of which you +> speak. That was my work, and I simply gave him the code to use during +> his ISSAC demo of the Aldor debugger. +> +> This aldor mode is not currently on aldor.org since I wrote it with +> GNU/Emacs in mind, and have found XEmacs to have a few problems +> dealing with the elisp. One I can support both emacs's, it will appear +> on aldor.org. +> +> If anyone would like a copy, just email me and I'll gladly send you +> it. The code is GPL'ed and I fully intend it to be available to all. +> +> Sincerely, +> Steve + + + diff --git a/changelog b/changelog index 156c7f4..10b0c9b 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140423 tpd src/axiom-website/patches.html 20140423.04.tpd.patch +20140423 tpd book/2004-09.txt regularize 20140423 tpd src/axiom-website/patches.html 20140423.03.tpd.patch 20140423 tpd book/2004-08.txt regularize 20140423 tpd src/axiom-website/patches.html 20140423.02.tpd.patch diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html index 64d14a7..46f93f8 100644 --- a/src/axiom-website/patches.html +++ b/src/axiom-website/patches.html @@ -4302,6 +4302,8 @@ book/2004-06.txt regularize book/2004-07.txt regularize 20140423.03.tpd.patch book/2004-08.txt regularize +20140423.04.tpd.patch +book/2004-09.txt regularize