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