diff --git a/book/2004-06.txt b/book/2004-06.txt
new file mode 100644
index 0000000..2f4d703
--- /dev/null
+++ b/book/2004-06.txt
@@ -0,0 +1,29881 @@
+\start
+Date: Tue, 1 Jun 2004 07:22:57 -0400
+From: root
+To: Bill.Page@drdc-rddc.gc.ca
+Subject: [Axiom-developer] Re: learning in public
+Cc: bill.page1@sympatico.ca
+
+Bill,
+
+Email should be fixed now.
+
+\start
+Date: Tue, 1 Jun 2004 07:36:02 -0400
+From: root
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] sigh.
+
+Headline: ATI unveils Axiom
+
+http://www.theregister.co.uk/2004/06/01/ati_axiom_unveiled/
+
+No, it's not what you think, unfortunately.
+
+\start
+Date: Tue, 1 Jun 2004 10:12:25 -0400
+From: "Page, Bill"
+To: "'daly@idsi.net'"
+Subject: [Axiom-developer] RE: learning in public
+Cc: bill.page1@sympatico.ca
+
+Thanks Tim!
+
+Email subscription is now working at
+
+ http://page.axiom-developer.org/zope/Plone/wiki
+
+If anyone desires, we can also setup "mail-in" to the wiki so
+that email sent to a standard address on axiom-developer.org (or
+in reply to an email sent via subscription) can be automatically
+appended to a specified wiki page. This lets people interact with
+the wiki entirely by email. Setting this up is a little harder
+than the "mail-out" feature used by subscription because it
+requires that sendmail be configured to call a script on receipt
+of the incoming email. I've done this successfully on a Solaris 8
+based server but not yet on Linux. Let me know if you would like
+me to give this a try.
+
+Cheers,
+Bill Page.
+
+> -----Original Message-----
+> From: root [mailto:daly@idsi.net]
+> Sent: Tuesday, June 01, 2004 7:23 AM
+> To: Bill.Page@drdc-rddc.gc.ca
+> Cc: daly@idsi.net; axiom-developer@nongnu.org; bill.page1@sympatico.ca
+> Subject: Re: learning in public
+>
+>
+> Bill,
+>
+> Email should be fixed now.
+
+\start
+Date: Tue, 1 Jun 2004 10:21:34 -0400
+From: Tim Daly
+To: bill.page@drdc-rddc.gc.ca
+Subject: [Axiom-developer] learning in public
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+More interesting to me would be a way to unify the website <-> latex.
+I can create a website with latex2html which is how I usually do these
+things. I'd like to have the information in latex format because I can
+do so many more things with it. HTML is a dead end, write-only format.
+
+\start
+Date: Tue, 1 Jun 2004 12:47:51 -0400
+From: "Page, Bill"
+To: 'Tim Daly'
+Subject: [Axiom-developer] website <-> latex
+Cc: "Bill Page \(E-mail\)"
+
+Tim,
+
+You wrote:
+
+"HTML is a dead end, write-only format."
+
+Well, I know where you are coming from, but I seriously doubt
+that you will be able to convince the current generation of
+web users of that! The move is still very strongly away from
+traditional LaTeX and towards XML-based extensions of HTML
+such as MATHML.
+
+In the current LatexWiki that is implemented at
+
+ http://page.axiom-developer.org/zope/Plone/wiki
+
+when you Edit the contents of a page, you have option of
+specifying alternate input languages for the page:
+
+ Structured Text + LaTeX
+ HTML + LaTeX
+ Structured Text
+ reStructured Text
+ HTML
+ Plain text
+
+The thing that is closest to pure LaTeX coding is the first
+one: Structured Text + LaTeX. In that case you can have simply
+formatted text, e.g. paragraphs and embedded LaTeX coding
+(usually only for equations). Structured Text also allows you
+to specify list structures, heading etc. but the format is
+not the same as in usual LaTeX coding.
+
+I find the HTML + LaTeX option a rather strange mix, however
+it is powerful and flexible that the first one.
+
+One enhancement of LatexWiki that I would like to see is a
+"pure" LaTeX mode which would parse LaTeX constructions such
+as \itemize and some of the other common LaTeX text formatting
+codes into the equivalent HTML code rather than rendering it
+as a graphic generated from LaTeX output. And this might also
+be extended to handle MATHML coding (if desired). We have
+had some discussions here about software that can do reliable
+LaTeX to HTML/MATHML and I think this could be quite easily
+encorporated in LatexWiki. At the present time, it should be
+possible to process LaTeX to HTML/MATHML using an external
+program and then use the simple HMTL option to upload it to
+a wiki page. But if your generated HTML code needs associated
+graphics, these will have to be uploaded separately.
+
+I know that Bob McElrath is working on the idea of extending
+LatexWiki here:
+
+ http://mcelrath.org/Notes/LatexWiki#msg20040531222012-0700@mcelrath.org
+
+----
+
+Today I have updated the software on the Axiom Portal so that it
+is now possible to subscribe to Discussions (forum topics) as
+well as to Wiki pages. For example see the :> Subscribe menu
+option at
+
+ http://page.axiom-developer.org/zope/Plone/forum/public
+
+In the case of subscription to a Wiki page, any new pages or
+comments on these pages are immediately sent to all subscribers.
+But in the case of the Discussion (forum) subscriptions, a
+digest of new topics and replys is sent only once per week.
+
+Please let me know if you have any trouble using these
+features.
+
+> -----Original Message-----
+> From: Tim Daly [mailto:daly@rio.sci.ccny.cuny.edu]
+> Sent: Tuesday, June 01, 2004 10:22 AM
+> To: bill.page@drdc-rddc.gc.ca
+> Cc: daly@idsi.net; axiom-developer@nongnu.org
+> Subject: learning in public
+>
+>
+> More interesting to me would be a way to unify the
+> website <-> latex. I can create a website with latex2html
+> which is how I usually do these things. I'd like to have
+> the information in latex format because I can do so many
+> more things with it. HTML is a dead end, write-only format.
+
+\start
+Date: Tue, 1 Jun 2004 10:50:38 -0700
+From: Bob McElrath
+To: "Page, Bill"
+Subject: Re: [Axiom-developer] website <-> latex
+Cc: "Bill Page \(E-mail\)"
+
+Page, Bill [Bill.Page@drdc-rddc.gc.ca] wrote:
+> One enhancement of LatexWiki that I would like to see is a
+> "pure" LaTeX mode which would parse LaTeX constructions such
+> as \itemize and some of the other common LaTeX text formatting
+> codes into the equivalent HTML code rather than rendering it
+> as a graphic generated from LaTeX output. And this might also
+> be extended to handle MATHML coding (if desired). We have
+> had some discussions here about software that can do reliable
+> LaTeX to HTML/MATHML and I think this could be quite easily
+> encorporated in LatexWiki. At the present time, it should be
+> possible to process LaTeX to HTML/MATHML using an external
+> program and then use the simple HMTL option to upload it to
+> a wiki page. But if your generated HTML code needs associated
+> graphics, these will have to be uploaded separately.
+
+Well the original idea was just to add the minimal required to enable
+people to easily write equations. I didn't really intend for a full
+latex environment. tex4ht can convert latex documents to html/mathml,
+but it is very slow. (slower than regular latex) You will notice that
+the current latexwiki can do mathml via a program called itex2MML if you
+uncomment the type at the bottom of __init__.py. This program uses lex
+and yacc to parse a subset of the latex math syntax. Do not feed it
+anything too complicated.
+
+FULL latex compatibility will require involving the latex program, which
+I would like to move away from because it's slow. But I'm open to
+adding more latex elements to latexwiki.
+
+Note that the whole thing is open source, written in python, so I
+encourage you all to implement any of the above that you're interested
+in. ;)
+
+The problem with mathml is that the client side is a disaster. (fonts)
+So for the forseeable future I will implement it as a option that
+individutal users have to go turn on.
+
+\start
+Date: Wed, 2 Jun 2004 00:55:35 +0200 (CEST)
+From: Bertfried Fauser
+To: "Page, Bill"
+Subject: Re: [Axiom-developer] RE: learning in public
+
+Dear Tim,
+
+ I regard this page as a motivation to start with an actual
+thinking on the design of a Clifford package. If less ambiguose, I can
+help with the most peculiar algorithms, but I still do not see how to do
+it categorial and in a full generality.
+ This week I am technically still in vacations and next week partly
+on a conference, so I will have a fast internet connection only from
+pre-next week onwards. I will try to take this time to think about a start
+implementation and what it should look like.
+
+Categorical:
+
+>From a categorical point of view, there is a functor from the spaces
+having a quadratic (bilinear not necessarily symmetric) form into the
+category of associative algebras. To characterize this functor would be
+the most difficult thing. But this is a unsolved math problem.
+
+Analytic:
+
+Many people work in Clifford analysis and many physicisty use Clifford
+algebras actually as Clifford modules. To cope with this generalization
+(in a mathematical rigorous way) is a major obstacte which hangs around
+and should be kept in ming if a wide aplicability is intended.
+
+Engineering:
+
+"Geometric Algebra" is the term promoted by Hestenes and followers for a
+style of using Clifford algebras as a "unifying language for mathematics
+and physics". I was some time also infected by this nicely looking vision
+and Hestenes charismatic writing. However, threse poeple have different
+goals in mind. They stick to 19th century geometry and to 19th century
+mathematics. From a categorial point, there cannot be a geometric algebra,
+but that is a question of defining a representation functor from some
+algebra into some geometry. This is a very wide filed and needs also a
+rectification of many concepts in the foundation of mathematics and in
+particular to logic. Clifford logic is not boolean etc pp.
+
+will write later more
+BF.
+
+PS: I am not unhappy that the wiki pages were refered ;-) but check out
+there the paper on Geometric Algebra, which I was intended to change....
+however, after typing in for 2 hours, mozilla crashed whene I pressed the
+submit button, and I was not fit enough mentally to do a second attempt.
+
+\start
+Date: Tue, 1 Jun 2004 19:31:38 -0400
+From: "Page, Bill"
+To: "'Bertfried.Fauser@uni-konstanz.de'"
+Subject: [Axiom-developer] Mozilla FireFox
+Cc: "'bill.page1@sympatico.ca'"
+
+Bertfried,
+
+On Tuesday, June 01, 2004 6:56 PM you wrote:
+>
+> PS: I am not unhappy that the wiki pages were refered ;-) but
+> check out there the paper on Geometric Algebra, which I was
+> intended to change....
+
+What "wiki pages" do you mean? Could you provide a link?
+
+> however, after typing in for 2 hours, mozilla crashed whene I
+> pressed the submit button, and I was not fit enough mentally
+> to do a second attempt.
+
+My favorite failure while using a browser to type something
+complicated is to accidentally press the Esc key twice where
+apon everything I typed in is irrecoverably gone! :( I don't
+know what to do to prevent this except to cultivate a habit to
+freqently save the work by a copy-paste into an auxillary text
+editor window.
+
+But for preventing browser crashes, my experience with the
+new FireFox version of Mozilla in very good even though it is
+still in the 0.8 release.
+
+http://www.mozilla.org/products/firefox/#mainContent
+
+It is especially simple to install under Windows, including
+support for the MathML fonts.
+
+http://www.mozilla.org/projects/mathml/fonts/
+
+\start
+Date: Tue, 1 Jun 2004 20:57:43 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] RE: learning in public
+Cc: Bill.Page@drdc-rddc.gc.ca
+
+BF,
+
+I just picked up a book "Clifford (Geometric) Algebras with applications
+in Physics, Mathematics, and Engineering" today. It is 33 chapters and
+somewhat unreadably dense in some areas. I have several other books to
+work thru in order to get familiar with the ideas and issues before
+even thinking about an implementation. You know the math and I know
+Axiom so I figure we can "meet in the middle". But I have much to learn
+before I can hold an intelligent conversation with you on the subject.
+
+Bill has put up a wiki and I've been pondering ways of using it to
+document Axiom and math. I've decided that I can write down the steps
+I take to develop the expertise in Clifford algebras as an experiment.
+Web page development is mildly tedious and I'd rather work in TeX but
+until I try to fully use the wiki tool I can't really suggest alternatives.
+Ideally there would be a latex<->html mapping so I can push the web pages
+back into pamphlet format but I don't know how to do this yet. Anyway
+I've decided to make my ignorance public and inflict it on the world :-)
+
+I see tiny pieces of work in Axiom that are related, like Quaternions and
+Denavit-Hartenburg matricies (4x4 transformation matrices). Axiom doesn't
+(yet) have the category "algebra" from which a Clifford algebra would
+derive. I suspect that getting educated in this subject is going to
+force an fair-sized enlargement of Axiom's category structure.
+
+I picked up a couple online papers from
+http://carol.wins.uva.nl/~leo/clifford
+These are probably part of the "geometric algebra" view of the world
+but I'm such a novice that I can't yet distinguish the various
+intellectual branches of the subject.
+
+Anyway, this should be fun.
+
+\start
+Date: Tue, 1 Jun 2004 21:08:37 -0400
+From: "Page, Bill"
+To: "'Bertfried.Fauser@uni-konstanz.de'"
+Subject: RE: [Axiom-developer] RE: learning in public
+Cc: "'bill.page1@sympatico.ca'"
+
+Bertfried and Tim,
+
+On Tuesday, June 01, 2004 6:56 PM you wrote:
+>
+> ... but I still do not see how to do it categorial and in
+> a full generality.
+> This week I am technically still in vacations and next
+> week partly on a conference, so I will have a fast internet
+> connection only from pre-next week onwards. I will try to
+> take this time to think about a start implementation and what
+> it should look like.
+>
+> Categorical:
+>
+> From a categorical point of view, there is a functor from the
+> spaces having a quadratic (bilinear not necessarily symmetric)
+> form into the category of associative algebras. To characterize
+> this functor would be the most difficult thing. But this is an
+> unsolved math problem.
+>
+
+>From http://en.wikipedia.org/wiki/Clifford_algebra
+
+Formal definition
+
+Let V be a vector space over a field k, and q : V -> k a quadratic form on
+V. The Clifford Algebra C(q) is a unital associative algebra over k together
+with a linear map i : V -> C(q) defined by the following universal property:
+
+for every associative algebra A over k with a linear map j : V -> A such
+that for every v in V we have j(v)^2 = q(v)1 (where 1 denotes the
+multiplicative identity of A), there is a unique algebra homomorphism
+
+ f : C(q) ? A
+
+such that the following diagram commutes:
+
+ V ----> C(q)
+ | /
+ | / Exists and is unique
+ | /
+ v v
+ A
+
+i.e. such that fi = j.
+
+---------
+
+Definition by a universal property
+
+ http://en.wikipedia.org/wiki/Universal_property
+
+is a common method of category theory. Unfortunately it is
+rather too abstract on usually non-constructive. Perhaps what
+you had in mind is the notion of adjoint functors
+
+ http://en.wikipedia.org/wiki/Adjoint_functors
+
+But I think best approach is to start from the general
+tensor algebra
+
+ http://en.wikipedia.org/wiki/Tensor_algebra
+ http://planetmath.org/encyclopedia/TensorAlgebra.html
+
+I can imagine that the general construction of the tensor
+algebra on a vector space should be quite natural in Axiom -
+perhaps most of this is already present in Axiom. But then to
+complete the general construction of a Clifford algebra we
+need to be able to compute the quotient ring generated by
+the quadratic form.
+
+ http://planetmath.org/encyclopedia/CliffordAlgebra2.html
+
+I am not so sure how one can do this in Axiom without
+introducing a basis. In general we need to be able to
+define an equivalence relation over the tensor expressions.
+
+The following paper is rather difficult for me but
+seems interesting.
+
+ http://www.nd.edu/~alhonors/pages/CliffordFinal.pdf
+
+The Clifford Algebra in the Theory of Algebras, Quadratic
+Forms, and Classical Groups by Alexander Hahn.
+
+And the following work by Paul Leopardi also seems very
+relevant.
+
+ http://cage.rug.ac.be/~krauss/iciam.pdf
+
+ http://www.maths.unsw.edu.au/~leopardi/
+
+ http://www.maths.unsw.edu.au/~leopardi/clifford-2003-06-05.pdf
+
+ http://sourceforge.net/projects/glucat/
+
+\start
+Date: Wed, 02 Jun 2004 12:26:48 +0200
+From: Michel.Lavaud@univ-orleans.fr
+To: "Page, Bill"
+Subject: Re: [Axiom-developer] website <-> latex
+
+Hello Bill,
+
+> Well, I know where you are coming from, but I seriously doubt
+> that you will be able to convince the current generation of
+> web users of that!
+
+I think it would be more adapted to consider only the current
+generation of scientists, rather than web users (most won't care about
+Axiom, I suppose? ). And I can assure you, from my experience and
+the experience of colleagues, that it is very easy to have students in
+science learn TeX in a few days, and write their reports in TeX. Not
+more easy, not less easy to learn than any other computer language
+like Fortran or C, and certainly much simpler to learn than Quantum
+Field Theory or C* algebras :-)
+
+> The move is still very strongly away from
+> traditional LaTeX and towards XML-based extensions of HTML
+> such as MATHML.
+
+Well, XML is driven by the Microsoft mammouth and a few others, and I
+agree that, in theory, it would be very attractive to merge portions
+of XML documents generated by Word with portions of documents
+generated by other software such as LaTeX, Amaya, Lyx, TeXmacs, etc.
+
+However, in practice, my experience with the much simpler example of
+just trying to import, into Word, HTML documents issued from other
+software, is that one usually obtains error messages saying
+approximately "The document you are trying to import contains errors,
+correct them and try later" ; even if it is a perfectly correct html
+document, that you displayed with Internet Explorer or Mozilla a few
+minutes before, so that it's clear the bugs come from Word, not from
+the html document.
+
+As for importing / exporting XML documents to exchange documents
+between various software, it seems to me reasonable to fear that
+bugged software ( such as Word, but not only) can create bugged XML
+documents, and thus bugged formulas, so that for ex. a formula that is
+correctly displayed with Word version N could be displayed incorrectly
+with another version of Word, or some other editor or display software
+(Amaya or other). So, my reaction to your remark "The move is still
+very strongly away from traditional LaTeX and towards XML-based
+extensions" would be that, if your remark is true, then it is a very
+strong argument to completely avoid XML, if one wants to privilege
+rigor in math documents and in Axiom :-) Just look at Basic and what
+it became in the hands of Microsoft : I have a personal theorem that
+asserts that any program written in MS Basic (i.e. using MS
+extensions) is bound to fail with any succeeding version of MS Basic
+one or two years later...
+
+Furthermore, I still don't see the advantages, for mathematicians, of
+Mathml/Xml over TeX, it seems to me nothing else than a (still)
+unachieved and very verbose way of trying to do the same, with the
+considerable disadvantage IMHO of making math formulas completely
+unreadable by humans, so that we are forced to read them through
+software, which are inevitably buggy, and so might represent
+incorrectly the formulae etc etc. (goto previous paragraph !). TeX has
+been created by a mathematician for mathematicians, and a TeX formula
+is very similar to the way one would read a formula to a colleague by
+telephone (cf. "history of TeX" on TUG site), so it's easy for a human
+to read it from its TeX source, not from its mathml source : one line
+of TeX is roughly one page of Mathml.
+
+The experience of TechExplorer is IMHO a good example of what can
+happen when trying to follow fashion driven by commercial products and
+stick to them : it could display directly some LaTeX documents into
+the first versions of Internet Explorer, but it ultimately failed, in
+part (if I understood well) because of modifications from Internet
+Explorer 5 to 6. Just replace LaTeX with Mathml, and imagine what
+could happen.
+
+To summarize, I think that, for Open Source mathematical software, we
+ought to privilege rigorous developments, rather than vigorous
+developments. I vote for Tim's approach, considering TeX documents as
+source, and html as dead-end,
+
+write-only format ; and I propose to consider Xml and Mathml on the
+same footing as html, because Xml/Mathml documents can be created from
+TeX source by TeX4ht, and because this prevents Axiom from becoming
+dependent of future evolution of Xml/Mathml and commercial software,
+so that it continues to be built on a zero-bug, rock-solid basis.
+
+\start
+Date: Wed, 2 Jun 2004 18:54:31 +0200 (CEST)
+From: Bertfried Fauser
+To: "Page, Bill"
+Subject: RE: [Axiom-developer] RE: learning in public
+
+On Tue, 1 Jun 2004, Page, Bill wrote:
+
+> Bertfried and Tim,
+
+> Formal definition
+>
+> Let V be a vector space over a field k, and q : V -> k a quadratic form on
+> V. The Clifford Algebra C(q) is a unital associative algebra over k together
+> with a linear map i : V -> C(q) defined by the following universal property:
+>
+> for every associative algebra A over k with a linear map j : V -> A such
+> that for every v in V we have j(v)^2 = q(v)1 (where 1 denotes the
+> multiplicative identity of A), there is a unique algebra homomorphism
+>
+> f : C(q) ? A
+>
+> such that the following diagram commutes:
+>
+> V ----> C(q)
+> | /
+> | / Exists and is unique
+> | /
+> v v
+> A
+>
+> i.e. such that fi = j.
+
+Of course, this is standard! But....
+
+1) Usually you will need Clifford algebras over rings, not fields, like
+the ring of smooth functions -> tempered distributions
+
+2) The form should be a bilinear form, not only a quadratic form. See
+
+ symmetric forms = bilinear forms mod altermating forms
+
+iff char of teh base field/ring is not 2. The above construction is then
+no longer so obvious.
+
+3) ANY base introduces a filtration. Physics is _sensitive_ to this
+filtration, even if the algebras are _isomorphic_ and hence mathematically
+indistingishable. This stems from additional features employed in physics.
+Hence it is _tremendously dangerous_ to introduce bases. However, certain
+physical appliocations _need_ such a reference base, alas I am confused.
+
+4) From a technical point of view, the most easy construction of a
+Clifford algebra (and that one which is capable of arbitrary even
+degenerated bilinear forms) is that of Chevalley, which unfortunately
+assumes a grading, which is _not_ inherent in a Clifford structure.
+
+Let x,y in V, u,v,w in V^, the exterior (Grassmann) algebra over V (unique
+up to isomorphisms) define the Clifford product recursively as:
+
+i) x _| y = B(x,y) = y |_ x (bilinear for acting on VxV )
+
+ii) x _| (u /\ v) = (x _| u) /\ v + =DFhat{u} /\ (x _| v) (derivation)
+
+iii) u _| ( v _| w) = (u /\ v) _| w (left action on the module V^)
+
+definition: the Clifford multiplication wrt the bilinaer form B (used in
+the contraction _|) is defined as
+
+ x =B0 u = x _| u + x /\ u
+
+a general element v can be multiplied by recursive use of i) ii) and iii)
+
+This is not the most efficient algorithm, but a plain approch. A much
+better approch uses Hopf algebras and defines the Clifford product as a
+twist by a (Laplace) 2-cocycle on the Grassmann Hopf algebra.
+
+Hence the way to go is:
+
+Define a category "graded module"
+Define the categories symmetric and exterior algebras over such a module
+(this amouts to introduce super symmetric multilinear algebra)
+Define the category of reflexive spaces with inner product.
+Define the Clifford algebra als a Funtor which assigns to every reflexive
+module a Clifford algebra.
+
+Much better is to make this that way that an itteration can be done.
+
+It is mandatory that such modules may be direct sum of graded modules and
+that one can somehow manage the grading information, eg we should think of
+modules composes from symmetric and exterior parts
+
+ M = Sym(V) \oplus Alt(W)
+
+this is needed for more advanced Cliffordizations.
+
+hope this helps
+ciao
+BF.
+
+PS: Tim, with wiki I was refering to the wikipedia pages.
+
+\start
+Date: Wed, 2 Jun 2004 09:14:50 -0700
+From: Bob McElrath
+To: Michel.Lavaud@univ-orleans.fr
+Subject: Re: [Axiom-developer] website <-> latex
+Cc: "Page, Bill"
+
+> The move is still very strongly away from
+> traditional LaTeX and towards XML-based extensions of HTML
+> such as MATHML.
+
+MathML is not writable or readable by humans. Therefore it will always
+be an intermediate format, and *only* an intermediate format. One must
+use other tools to create it. The appropriate tool for the forseeable
+future is LaTeX.
+
+\start
+Date: Wed, 2 Jun 2004 13:41:48 -0400
+From: "Bill Page"
+To:
+Subject: RE: [Axiom-developer] website <-> latex
+
+On Wednesday, June 02, 2004 6:27 AM
+Michel.Lavaud@univ-orleans.fr wrote:
+>
+> > Well, I know where you are coming from, but I seriously
+> > doubt that you will be able to convince the current
+> > generation of web users of that!
+>
+> I think it would be more adapted to consider only the current
+> generation of scientists, rather than web users (most won't
+> care about Axiom, I suppose?). And I can assure you, from my
+> experience and the experience of colleagues, that it is very
+> easy to have students in science learn TeX in a few days, and
+> write their reports in TeX. Not more easy, not less easy to
+> learn than any other computer language like Fortran or C, and
+> certainly much simpler to learn than Quantum Field Theory or
+> C* algebras :-)
+
+Yes I agree with you. But I work for a large scientific
+research organization (about 200 research scientists, some in
+engineering, math and physics, others in "softer sciences").
+Recently I have had to deal specifically and almost everyday
+with the issue of LaTeX versus WORD. Perhaps 50% of our authors
+are still "die-hard" LaTeX users who would also share your
+views. The other 50% (and probably increasing) now use WORD -
+in spite of all of the problems that it causes. In fact, the
+use of WORD is a de facto organization standard as set by
+corporate office users who know very little about preparing
+scientific documents and for the most part do not even use
+WORD very well. I don't think this trend is unique to our
+organization.
+
+Still, I promote and defend LaTeX when ever I can. When
+I can't do that, I promote OpenOffice. But you might be
+quite surprised how hard it is to "sell" something that
+is free, even when it is clearly better.
+
+>
+> > The move is still very strongly away from traditional
+> > LaTeX and towards XML-based extensions of HTML such as
+> > MATHML.
+>
+> Well, XML is driven by the Microsoft mammoth and a few
+> others, and I agree that, in theory, it would be very
+> attractive to merge portions of XML documents generated
+> by Word with portions of documents generated by other
+> software such as LaTeX, Amaya, Lyx, TeXmacs, etc.
+>
+
+XML is a W3C standard. What Microsoft does with it is,
+in my opinion, largely irrelevant. The XML format used
+by WORD is not very useful - still it is somewhat better
+than an undisclosed completely proprietary format. I think
+OpenOffice generates much better XML.
+
+But really it is incorrect to refer to "XML documents". XML
+is not a document format. It is a semantic neutral generic
+mark-up language. It is the namespace and other semantics that
+one must add to XML in any given application that determine
+the actual "document" content.
+
+> However, in practice, my experience with the much simpler
+> example of just trying to import, into Word, HTML documents
+> issued from other software, is that one usually obtains error
+> messages saying approximately "The document you are trying
+> to import contains errors, correct them and try later";
+> even if it is a perfectly correct html document, that you
+> displayed with Internet Explorer or Mozilla a few minutes
+> before,
+
+Just because an HTML document displays properly in some
+browser (Explorer, Mozilla or any other, any given version,
+etc.) does not mean that it is "correct" HTML. For that
+you need an HTML validator program (see W3C website). But
+trying to creating or importing HTML to/from WORD is not
+something I would ever try to do except perhaps as a last
+resort. HTML is a "presentation" format. WORD wants an
+editable format as input. WORD creates rather poor and
+idiosyncratic HTML as output. (OpenOffice creates much
+better HTML.) You would have similar (or worse) problems
+trying to import postscript or PDF format into WORD (or
+other word processor).
+
+> so that it's clear the bugs come from Word, not from the
+> html document.
+
+WORD certainly has bugs, but I don't see how you can
+conclude this from what you apparently are asking it
+to do.
+
+>
+> As for importing / exporting XML documents to exchange
+> documents between various software, it seems to me
+> reasonable to fear that bugged software (such as Word,
+> but not only) can create bugged XML documents, and thus
+> bugged formulas, so that for ex. a formula that is correctly
+> displayed with Word version N could be displayed incorrectly
+> with another version of Word, or some other editor or
+> display software (Amaya or other).
+
+Yes, I agree. There are many examples of this. But it has
+nothing to do with XML as such.
+
+> So, my reaction to your remark "The move is still very
+> strongly away from traditional LaTeX and towards
+> XML-based extensions" would be that, if your remark is true,
+> then it is a very strong argument to completely avoid XML,
+> if one wants to privilege rigor in math documents and in
+> Axiom :-)
+
+I don't see what this has to do with XML?
+
+> Just look at Basic and what it became in the hands of
+> Microsoft : I have a personal theorem that asserts
+> that any program written in MS Basic (i.e. using MS
+> extensions) is bound to fail with any succeeding version
+> of MS Basic one or two years later...
+>
+
+You are right. However I have a similar experience with
+Java, Perl, Maple, and even Axiom. So I think that you
+are simply protesting too much about Microsoft. Forget
+about Microsoft as such, and support free and open source
+software.
+
+> Furthermore, I still don't see the advantages, for
+> mathematicians, of Mathml/Xml over TeX, it seems to me
+> nothing else than a (still) unachieved and very verbose
+> way of trying to do the same, with the considerable
+> disadvantage IMHO of making math formulas completely
+> unreadable by humans, so that we are forced to read them
+> through software, which are inevitably buggy, and so might
+> represent incorrectly the formulae etc etc. (goto previous
+> paragraph !).
+
+I agree with what you say about the readability of MATHML
+but it is not correct to think of it as "trying to do the
+same" as TeX. As Bob McElrath wrote:
+
+> MathML is not writable or readable by humans. Therefore
+> it will always be an intermediate format, and *only* an
+> intermediate format. One must use other tools to create it.
+> The appropriate tool for the foreseeable future is LaTeX.
+
+I agree with this and am not trying to argue against it.
+LaTeX is still a very reasonable way to create typeset
+quality mathematics. But the goals of MATHML are quite
+different. It is a standard language which a web browser
+is expected to be able to parse and render just like it
+renders other HTML and even vector graphics formats etc.
+Yes, it could have been LaTeX instead of an XML-based
+standard, in fact LaTeX even had most (all?) of the
+formatting and hypertext extensions available when HTML
+was invented for the Web. But as it turns out, standards
+are one thing and "best practices" are another. Most people
+think that the web and HTML succeeded where earlier tools
+like LaTeX and SGML failed simply because of the sudden
+acceptance of this coding as a "standard". Usually it is
+just a matter of timing and politics.
+
+Perhaps it is a mistake to think that W3C and related
+international organizations can repeat this with more
+complex text like mathematics.
+
+
+> TeX has been created by a mathematician for mathematicians,
+> and a TeX formula is very similar to the way one would read
+> a formula to a colleague by telephone (cf. "history of TeX"
+> on TUG site), so it's easy for a human to read it from
+> its TeX source, not from its mathml source : one line of TeX
+> is roughly one page of Mathml.
+
+I really don't see much advantage of reading formula by
+telephone ... although I admit that I often use a simplified
+LaTeX coding in emails to colleagues.
+
+But the point is that it takes a computer with a LaTeX
+package installed to properly render mathematics from LaTeX
+and it takes a MATHML capable browser to render MATHML. If or
+when people have MATHML capable browsers open and ready on
+their desk tops, they might expect to display mathematical
+text without any additional programs. Right now we do that
+by resorting to a much less efficient graphic format such
+as png, gif or jpeg (which of course none are in any kind
+of "human" readable format).
+
+>
+> The experience of TechExplorer is IMHO a good example of
+> what can happen when trying to follow fashion driven by
+> commercial products and stick to them : it could display
+> directly some LaTeX documents into the first versions of
+> Internet Explorer, but it ultimately failed, in part (if
+> I understood well) because of modifications from Internet
+> Explorer 5 to 6. Just replace LaTeX with Mathml, and imagine
+> what could happen.
+
+That is already happening. I think TechExplorer is still
+a commercial product of IBM, right?
+
+>
+> To summarize, I think that, for Open Source mathematical
+> software, we ought to privilege rigorous developments,
+> rather than vigorous developments. I vote for Tim's approach,
+> considering TeX documents as source, and html as dead-end,
+> write-only format ; and I propose to consider Xml and Mathml
+> on the same footing as html, because Xml/Mathml documents
+> can be created from TeX source by TeX4ht, and because this
+> prevents Axiom from becoming dependent of future evolution
+> of Xml/Mathml and commercial software, so that it continues
+> to be built on a zero-bug, rock-solid basis.
+
+I also agree with you, Tim and Bob about the choice of
+LaTeX (or more specifically Tim's noweb extensions of it)
+as a practical source format. However I do not agree with
+your opinions about XML or that HTML and MATHML are
+"dead-ends". To me they are simply "a means to an end".
+
+\start
+Date: Wed, 2 Jun 2004 12:59:27 -0400
+From: Tim Daly
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] conference feedback
+
+*,
+
+We (CAISS, City College of NY) are planning a conference in December.
+The conference is intended to be centered around Axiom and intended
+for a broad audience. I'd welcome feedback about what you'd like to
+hear and who might have topics to present.
+
+\start
+Date: Thu, 3 Jun 2004 09:18:37 -0400
+From: "Bill Page"
+To:
+Subject: RE: [Axiom-developer] website <-> latex
+
+On Thursday, June 03, 2004 4:04 AM Michel.Lavaud@univ-orleans.fr
+wrote
+
+> Bill Page wrote:
+> > I do not agree [that] XML or HTML and MATHML are "dead-ends".
+> > To me they are simply "a means to an end".
+> Sorry, I did not explain clearly. No, I did not say they
+> _are_ dead ends, I just suggested to _consider them_ as
+> dead-ends, as long as there is no tool that translates from
+> mathml to latex.
+
+Actually MATHML to LaTeX is not very difficult. Here are
+some references:
+
+>From http://www.w3.org/Math/implementations.html
+
+"Vasil I. Yaroshevich's MathML to LaTeX translator [November
+2002] XSLT MathML Library, is a set of XSLT stylesheets to
+transform MathML 2.0 to LaTeX. It supports Presentation and
+Content MathML."
+
+ http://sourceforge.net/projects/xsltml/
+ http://xsltml.sourceforge.net/
+
+Also the MathType website at
+
+http://www.dessci.com/en/support/tutorials/mt_mathml/default.htm
+
+says:
+
+"IBM techexplorer Hypermedia Browser - IBM. A plug-in for the
+high-quality and customizable display of scientific and
+mathematical expressions and documents. It supports hypertext,
+multimedia, extended navigational features, and many user-definable
+UI features. It renders a large subset of TeX and LaTeX, and a
+large support for MathML (both for Content and Presentation
+markup). The final version is expected to support LaTeX to
+MathML and MathML to LaTeX translation. The techexplorer plug-in
+is currently available for Windows 9x/NT, Linux, AIX, Solaris
+and Irix."
+
+But I have not yet been able to verify that "MathML to LaTeX
+translation" was ever implemented.
+
+BTW, earlier I wrote:
+
+> I think TechExplorer is still a commercial product of IBM,
+> right?
+
+but the site
+
+ http://www-306.ibm.com/software/network/techexplorer/
+
+says
+
+ IBM no longer markets techexplorer Hypermedia. This product
+is now available from Integre Technical Publishing Co.,
+please visit their web site at
+
+ http://www.integretechpub.com/
+
+There is says:
+
+"Welcome to the web site for the Integre techexplorer Hypermedia
+Browser. Here you will find information on two products that
+are available for free download for individual use:
+
+The techexplorer Hypermedia Browser allows your browser to display
+TeX, LaTeX, and MathML markup, either from separate source files,
+or embedded into an HTML page.
+
+The MathML Equation Editor, which requires techexplorer, allows
+you to create, edit, and save both Content and Presentation MathML.
+
+Also on this site you will find customer support links, extended
+licensing information, and technical resources for those developing
+applications using techexplorer. "
+
+http://www.integretechpub.com/techexplorer/
+
+http://www.integretechpub.com/docs/techexplorer/Help/
+
+In a recent email Tim Daly mentioned something about the possibility
+of re-incorporating Techexplorer back into Axiom... I think that this
+would be great!
+
+\start
+Date: Thu, 3 Jun 2004 09:34:34 -0400
+From: "Bill Page"
+To:
+Subject: [Axiom-developer] MathML to LaTeX
+
+>
+> >From http://www.w3.org/Math/implementations.html
+>
+> "Vasil I. Yaroshevich's MathML to LaTeX translator [November
+> 2002] XSLT MathML Library, is a set of XSLT stylesheets to
+> transform MathML 2.0 to LaTeX. It supports Presentation and
+> Content MathML."
+>
+> http://sourceforge.net/projects/xsltml/
+> http://xsltml.sourceforge.net/
+>
+
+Here are some useful links from the README.txt file
+
+ http://www.raleigh.ru/MathML/mmltex/index.php?lang=en
+
+ http://www.raleigh.ru/MathML/mmltex/online.php
+
+\start
+Date: Thu, 3 Jun 2004 17:03:32 +0200 (CEST)
+From: "m.rubey"
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] (no subject)
+
+I'm about to finish a package that guesses - given the first few terms of
+a sequence of numbers - a function that might be generating these numbers.
+In principle it's a port of Christian Krattenthaler's program rate.m for
+MMA. See http://igd.univ-lyon1.fr/~webeuler/home/kratt/rate/rate.html
+for more information.
+
+Although my package works in principle, I encountered some problems - some
+of which were easy to solve, but some remain.
+
+In principle, I'd need to write to extend the domain EXPR to fields.
+However, this appears to me to be a bit too complicated for the
+moment, so I'd be content with the following:
+
+given a field which has OrderedSet, say FRAC POLY INT, how can my program
+find out that the "correct" expression space is EXPR INT? (because,
+unfortunately, EXPR FRAC POLY INT is not a valid type...)
+
+Thanks in advance,
+
+Martin
+
+PS: While writing the patch for dvdsum -- axiom assumes at the moment that
+d/dx sum_i=1^x f(i) equals f(x) -- I ran across some new problems, that's
+the reason why the patch is not yet submitted
+
+PPS: more bugs tomorrow :-(
+I have a handwritten list in my former office...~
+
+\start
+Date: Thu, 3 Jun 2004 20:53:41 -0700
+From: Bob McElrath
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Playing with Axiom
+
+--3MwIy2ne0vdjdPXF
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+I started playing a bit with Axiom,
+
+ http://mcelrath.org/Notes/AxiomInParticlePhysics
+
+(Any comments on the above page are welcome)
+
+Can anyone answer for me:
+
+ 1) How do I unassign/undeclare a variable? i.e.
+ a: Matrix(Integer) := diagonalMatrix([1,1])
+ a: Integer
+
+ 2) The subst() operator doesn't work on my tensors. Is there a better
+ way to substitute/evaluate when you're substituting into a complex
+ object?
+
+ 3) Let's say I wanted to allow the conversion of rank 0 tensors into
+ their scalar counterpart. Any idea where to start?
+
+\start
+Date: Fri, 4 Jun 2004 09:49:06 +0200 (CEST)
+From: "m.rubey"
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Playing with Axiom
+
+On Thu, 3 Jun 2004, Bob McElrath wrote:
+
+> I started playing a bit with Axiom,
+>
+> http://mcelrath.org/Notes/AxiomInParticlePhysics
+>
+> (Any comments on the above page are welcome)
+>
+> Can anyone answer for me:
+>
+> 1) How do I unassign/undeclare a variable? i.e.
+> a: Matrix(Integer) := diagonalMatrix([1,1])
+> a: Integer
+
+I hope the following is self explaining:
+
+(1) -> f:INT
+ Type:
+Void
+(2) -> f:MATRIX INT
+ Type:
+Void
+(3) -> f:=matrix [[1]]
+ (3) [1]
+ Type: Matrix
+Integer
+(4) -> f:INT
+
+ You cannot declare f to be of type Integer because either the
+ declared type of f or the type of the value of f is different
+ from Integer .
+(4) -> )cl val f
+(4) -> f:INT
+ Type:
+Void
+(5) -> f:=1
+
+ (5) 1
+
+for more information about )cl val == )clear value see pg 990 of the Axiom
+book (Section about System Commands)
+
+\start
+Date: Fri, 4 Jun 2004 10:12:32 -0400
+From: root
+To: rubey@geometrie.tuwien.ac.at
+Subject: Re: [Axiom-developer] Playing with Axiom
+Cc: bob@mcelrath.org
+
+Martin,
+
+try
+
+)clear properties f
+
+
+you can find the options on clear by typing:
+
+)clear
+
+at the command line. Any command that is not complete will issue
+help text about options.
+
+\start
+Date: Fri, 4 Jun 2004 10:13:41 -0400
+From: root
+To: bob@mcelrath.org
+Subject: Re: [Axiom-developer] Playing with Axiom
+
+Martin,
+
+re: subst on tensors. can you give me an example that doesn't work
+along with an explanation of what you'd like to have happen?
+
+\start
+Date: Fri, 4 Jun 2004 09:27:06 -0700
+From: Bob McElrath
+To: root
+Subject: Re: [Axiom-developer] Playing with Axiom
+
+root [daly@idsi.net] wrote:
+> Martin,
+>
+> re: subst on tensors. can you give me an example that doesn't work
+> along with an explanation of what you'd like to have happen?
+
+ (a,b):Expression Float
+ c: CartesianTensor(0,2,Expression Float)
+ c := [a,b]
+ subst(c, [a=1, b=2])
+
+This seems to work if the dimension of CartesionTensor (second argument)
+is 1, but not if it is larger.
+
+I get a different error if I do:
+
+ (E,px,py,pz):Expression Complex Float
+ p: CartesianTensor(0,4,Expression Complex Float)
+ p := [E,px,py,pz]
+ subst(p, [E=1, px=2, py=3, pz=4])
+
+\start
+Date: Fri, 4 Jun 2004 15:48:45 -0400
+From: root
+To: bill.page1@sympatico.ca
+Subject: [Axiom-developer] plone/python/axiom
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+Bill,
+
+At http://page.axiom-developer.org/zope/Plone/wiki/June32004
+there are a bunch of Axiom expressions. It would be sweet if
+there was some way to execute Axiom behind the scenes. Since
+plone is python, nearly lisp, there ought to be a way to do
+this. Suggestions?
+
+\start
+Date: Fri, 4 Jun 2004 18:08:53 -0400
+From: root
+To: math@its.utexas.edu
+Subject: [Axiom-developer] IMSL and Axiom
+
+Axiom is a free, open source computer algebra system.
+I'm the lead developer on the project.
+
+I'd like to get Axiom working with IMSL.
+Who is the correct person to contact?
+
+\start
+Date: Fri, 4 Jun 2004 22:05:22 -0400
+From: "Bill Page"
+To:
+Subject: [Axiom-developer] RE: plone/python/axiom
+
+Tim,
+
+On Friday, June 04, 2004 3:49 PM you wrote:
+>
+> At http://page.axiom-developer.org/zope/Plone/wiki/June32004
+> there are a bunch of Axiom expressions. It would be sweet if
+> there was some way to execute Axiom behind the scenes. Since
+> plone is python, nearly lisp, there ought to be a way to do
+> this. Suggestions?
+
+Well, the simplest approach I can think of would be to patch
+the existing LatexWiki code to treat input such as
+
+ \begin{axiom-input}
+ R1:=matrix([[cos a, sin a, 0],[-sin a, cos a, 0],[0, 0, 1]])
+ \end{axiom-input}
+ Next we define a rotation around the Y axis by a rotation angle of b
+ \begin{axiom-input}
+ R2:=matrix([[cos b, 0, -sin b],[0, 1, 0],[sin b, 0, cos b]])
+ \end{axiom-input}
+ The we compose them (order is important) to form the single
+ rotation equivalent to first rotating around X, then around
+ the new, displaced Y.
+ \begin{axiom-input}
+ R:=R1*R2
+ \end{axiom-input}
+ ...
+
+in a special way. Anything between \begin{axiom-input} ...
+\end{axiom-input}would be first passed via a pipe to Axiom
+and the output would be passed to LaTeX instead of going direct
+to LaTeX the way it does now. I think one must start an Axiom
+session at the occurrence of the first \begin{axiom-input} on
+the page and not close it until finished parsing the contents
+of the page.
+
+In principle adding code to do this to the wiki code should
+not be that difficult since it already does a lot of these
+things to generate the LaTeX math output anyway.
+
+Regards,
+Bill Page.
+
+BTW, I made some editing changes to your June32004 page to
+illustrate the use of the LaTeX math. For example you can
+write $G0_n$ and $R^n$ and then it displays with a real
+subscript and superscripts. $\alpha$ display the Greek
+letter etc. If you need to you can also display LaTeX
+equations this way. Let me know if this is ok or if you
+have any questions about using LaTeX in the wiki.
+
+\start
+Date: Sun, 06 Jun 2004 12:55:31 +0200
+From: David MENTRE
+To: mpleszkoch@yahoo.com
+Subject: [Axiom-developer] Re: New user registration
+
+Hello Mark,
+
+Welcome to the Axiom developer group. I hope we will find joint domains
+that will improve Axiom and your work.
+
+Yours,
+david mentré
+
+savannah-hackers@gnu.org writes:
+
+> User Full Name: Mark Pleszkoch
+> User Name: mpleszko
+> User Email: mpleszkoch@yahoo.com
+>
+> Project Full Name: Axiom Computer Algebra System
+> Project System Name: axiom
+> Project page: https://savannah.nongnu.org//projects/axiom
+>
+> Message from user:
+>
+> I'm interesting in joining the Axiom group. I'm starting a job at
+> CMU's Software Engineering Institute that involves the symbolic
+> execution of programs, and I think there will be a lot of synergy with
+> computer algebra.
+
+\start
+Date: Mon, 7 Jun 2004 09:49:21 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] debian layout
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+I looked over your debian layout and I don't see anything wrong
+with it. As I'm not running debian anywhere I really can't test
+it but if it passes the .input file tests then it should be fine.
+
+\start
+Date: Mon, 7 Jun 2004 09:53:01 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] BLAS and GCL
+
+In response to the numericIntegration question I looked at what
+would be required to rebuild the missing NAG functionality. The
+base layer seems to be BLAS (Basic Linear Algebra Subroutines).
+I downloaded BLAS over the weekend and rebuilt it as pamphlets.
+Now I'm going to try to link it into the GCL image. Have you
+ever seen a fortran linkage or should I use the C cover functions
+(CBLAS)?
+
+\start
+Date: Mon, 7 Jun 2004 09:55:49 -0400
+From: Tim Daly
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru
+
+Mike,
+
+Is the new open math draft finalized?
+
+\start
+Date: Mon, 7 Jun 2004 15:58:22 +0100
+From: Mike Dewar
+To: Tim Daly
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru
+
+Hi Tim,
+
+Pretty much. We are allowing people to submit editorial corrections up
+to June 18th and then we will produce the final version.
+
+Cheers, Mike.
+
+On Mon, Jun 07, 2004 at 09:55:49AM -0400, Tim Daly wrote:
+> Mike,
+>
+> Is the new open math draft finalized?
+
+\start
+Date: Mon, 7 Jun 2004 16:17:21 +0100
+From: Mike Dewar
+To: Tim Daly
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru
+
+Its available from www.openmath.org.
+
+Cheers, Mike.
+On Mon, Jun 07, 2004 at 10:07:43AM -0400, Tim Daly wrote:
+> Is it somewhere I can reach? I'd like to make another step of
+> progress on the MONET problem.
+
+\start
+Date: 07 Jun 2004 11:10:09 -0400
+From: Camm Maguire
+To: Tim Daly
+Subject: Re: [Axiom-developer] debian layout
+Cc: Lehobey , dmentre@linux-france.org
+
+Greetings, and thanks!
+
+Tim Daly writes:
+
+> I looked over your debian layout and I don't see anything wrong
+> with it. As I'm not running debian anywhere I really can't test
+> it but if it passes the .input file tests then it should be fine.
+>
+
+Great!
+
+Here are some comments I've received from another very helpful Debian
+axiom user. I'd appreciate your thoughts on these too if you have a
+moment before finalizing the package. I think including the .dvi is
+a good idea, but am unsure of whether it would be better in axiom-doc
+as opposed to its own axiom-source-doc -- are these files logically
+separate from the other documentation? I don't know anything about the
+.as files.
+
+=============================================================================
+Two remarks:
+
+ I have been surprised to see a few .as files in axiom-test. I
+thought they were specific to Aldor (and not Axiom). Are they just
+lying there without ever been used (I have not checked what they
+were)?
+
+ What would you think of a (new) axiom-source-doc package that would
+also include the output of noweave in .dvi or .ps or even .pdf. I
+mean giving the sources with their comments in typeset format as
+expected by Tim from his literate programming pamphlets (maybe even
+the typset makefile...).
+=============================================================================
+
+\start
+Date: Mon, 7 Jun 2004 10:07:43 -0400
+From: Tim Daly
+To: miked@nag.co.uk
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru
+
+Is it somewhere I can reach? I'd like to make another step of
+progress on the MONET problem.
+
+\start
+Date: Mon, 7 Jun 2004 11:08:23 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+> I have been surprised to see a few .as files in axiom-test. I
+>thought they were specific to Aldor (and not Axiom). Are they just
+>lying there without ever been used (I have not checked what they
+>were)?
+
+The .as files are there because in the fullness of time the plan calls
+for restoring aldor functionality (I'm now an Aldor developer). So
+they are "in plan" but not yet in use. Axiom has a couple "hanging"
+portions waiting for the missing functions to be rebuilt. This takes a
+surprisingly long time but there is progress you can't see because it
+is happening locally. Graphics test cases are there but the graphics
+code is not. However graphics code is coming to life and, hopefully,
+might see the light of day by the end of this summer.
+
+> What would you think of a (new) axiom-source-doc package that would
+>also include the output of noweave in .dvi or .ps or even .pdf. I
+>mean giving the sources with their comments in typeset format as
+>expected by Tim from his literate programming pamphlets (maybe even
+>the typset makefile...).
+
+mnt/linux/doc contains .dvi files which are the output of running
+noweave -> latex -> dvi on the pamphlet files. The long term plan
+is to integrate the dvi files into the mythical new front end.
+I've skipped using pdf and ps as I consider them to be write-only
+formats (once info is in pdf or ps form I can't use it anywhere).
+However it is trivial to make pdf or ps files if we want since
+the dvi files exist. See, for example,
+mnt/linux/doc/src/algebra for the dvi files from the algebra code.
+
+In particular see
+mnt/linux/doc/src/algebra/dhmatrix.spad.dvi (algebra)
+mnt/linux/doc/src/interp/setvars.boot.dvi (interpreter internals)
+for examples of documentation.
+
+Every file I set out to modify I first set out to document. This
+is very time consuming but necessary for the long term. Thus
+development is slowed even further because I have to reverse-engineer
+code I wrote in the last century. For algebra it involves finding the
+original research work and securing permission to use it (and then
+understand it enough to document it).
+
+Progress (albeit glacial) is happening.
+
+\start
+Date: Mon, 7 Jun 2004 11:11:51 -0400
+From: Tim Daly
+To: miked@nag.co.uk
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru
+
+I'd be nice if they posted the TeX files. Then I could integrate them
+into Axiom as documentation. Any chance of convincing the team to do
+that?
+
+\start
+Date: 07 Jun 2004 12:09:50 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: [Axiom-developer] Re: BLAS and GCL
+
+Greetings!
+
+Tim Daly writes:
+
+> In response to the numericIntegration question I looked at what
+> would be required to rebuild the missing NAG functionality. The
+> base layer seems to be BLAS (Basic Linear Algebra Subroutines).
+> I downloaded BLAS over the weekend and rebuilt it as pamphlets.
+> Now I'm going to try to link it into the GCL image. Have you
+> ever seen a fortran linkage or should I use the C cover functions
+> (CBLAS)?
+>
+
+Well, fortunately or not, I also happen to maintain blas/lapack/atlas
+for Debian, and we use the blas heavily here at work. I've always
+intended to give GCL blas functionality -- we even discussed on the
+mailing list how to instruct the compiler to optimize written out lisp
+loops into blas calls. On Debian, such calls are automatically
+redirected at runtime to the most efficient blas implementation
+installed for the running cpu, taking advantage of various subarch
+extensions such as sse2, etc. There is matlisp, which I have not
+looked at, but my guess is that it would be far more overhead than GCL
+needs, as if there is anything at which GCL excels, it is in its C
+interface.
+
+My only uncertainty in how to proceed here lies in how to modularize
+this capability. One surely does not want all gcl images to depend on
+a blas shared external lib. On the other hand, one wants to be able
+to load a module with the lisp interface, dlopen the lib, save the
+system, and have the resulting image still depend on blas and to work
+properly. One can do this at present via (compiler::link
+"lisp_blas.o" "new_image" "" "-lblas -lg2c"), but the beauty of
+save-system over this is that it maintains the state of the heap
+created in the session up to that point, wheras the link function
+would have to be supplied an optional argument containing code to
+recreate this state in the newly linked image. However, the dynamic
+linker ld.so will not redirect symbols in loaded compiled lisp objects
+after a save-system and re-execution -- GCL's internal linker is
+'static'. I suppose the solution ultimately is to rewrite sfaslbfd.c
+and the like to leave such symbols undefined but marked for processing
+by ld.so -- should be possible, I just don't know how to do it yet.
+
+In any case, this is a lot more than you wanted to know no doubt. In
+short, you can use either the fortran or C interface functions. On
+Debian, cblas wrappers are rolled into the same single libblas with
+the fortran.
+
+An example fortran call would look like:
+
+extern void
+dgemv_ (char *,int *,int *,double *,
+ const double *,int *,const double *,
+ int *,double *,double *,int *);
+
+dgemv_ (&t,&n,&m,&alpha,a,&lda,x,&ix,&beta,y,&iy);
+
+i.e. all functions have an underscore postpended, all arguments are
+passed by reference, and one can link with the normal C linker adding
+-lg2c. A home grown C wrapper for this would look like:
+
+int
+dgemv (char t,int m,int n,double alpha,const double *a,
+ int lda,const double *x,int ix,
+ double beta,double *y,int iy);
+
+One way to proceed would therefore be to place the following in
+dgemv.lisp (obviously more error checking is needed, but you get the
+idea):
+
+=============================================================================
+(clines "
+extern void
+dgemv_ (char *,int *,int *,double *,
+ const double *,int *,const double *,
+ int *,double *,double *,int *);
+
+int
+dgemv (char t,int m,int n,double alpha,object a,
+ int lda,object x,int ix,
+ double beta,object y,int iy) {
+
+ t=t=='T' ? 'N' : 'T'; /* Fortran arrays are column-major*/
+ dgemv_ (&t,&n,&m,&alpha,a->lfa.lfa_self,&lda,x->lfa.lfa_self,&ix,&beta,y->lfa.lfa_self,&iy);
+ return 0;
+
+}
+init_dgemv() {}
+
+")
+
+
+(defentry %dgemv (char int int double object int object int double object int) (int dgemv))
+=============================================================================
+
+and then in gcl:
+
+>(compile-file "/tmp/dgemv.lisp")
+>(compiler::link '("/tmp/dgemv.o") "/tmp/new_image" "" "-lblas -lg2c")
+
+
+One could similarly use the cblas interface if desired.
+
+Come to think of it, we should really have compiler::link append the
+new libs to compiler::*ld-libs* for subsequent invocations in the new
+image.
+
+Take care,
+
+\start
+Date: Mon, 7 Jun 2004 17:15:31 +0100
+From: Mike Dewar
+To: Tim Daly
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru
+
+The standard is written in XML using the DocBook DTD. We generate
+XHTML+MathML (the normative version) and PDF via LaTeX (non-normative)
+using XSLT. We could probably make the source form and our stylesheet
+available when the final version is released if that would help, but for
+forms sake I'd like to check with the rest of the OpenMath Executive
+Committee before doing so.
+
+Mike.
+
+On Mon, Jun 07, 2004 at 11:11:51AM -0400, Tim Daly wrote:
+> I'd be nice if they posted the TeX files. Then I could integrate them
+> into Axiom as documentation. Any chance of convincing the team to do
+> that?
+
+\start
+Date: Mon, 07 Jun 2004 18:52:07 +0200
+From: David MENTRE
+To: Tim Daly
+Subject: Re: [Axiom-developer] debian layout
+Cc: camm@enhanced.com, Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+Hello,
+
+To answer more precisely Camm question:
+
+Tim Daly writes:
+
+> The .as files are there because in the fullness of time the plan calls
+> for restoring aldor functionality (I'm now an Aldor developer). So
+> they are "in plan" but not yet in use. Axiom has a couple "hanging"
+> portions waiting for the missing functions to be rebuilt. This takes a
+> surprisingly long time but there is progress you can't see because it
+> is happening locally. Graphics test cases are there but the graphics
+> code is not. However graphics code is coming to life and, hopefully,
+> might see the light of day by the end of this summer.
+
+So the .as files are nto strictly needed right now (they are currently
+developer files and not user files, and as such are available in the CVS
+and Arch trees). So they should not be in the debian package.
+
+>> What would you think of a (new) axiom-source-doc package that would
+>>also include the output of noweave in .dvi or .ps or even .pdf. I
+>>mean giving the sources with their comments in typeset format as
+>>expected by Tim from his literate programming pamphlets (maybe even
+>>the typset makefile...).
+>
+> mnt/linux/doc contains .dvi files which are the output of running
+> noweave -> latex -> dvi on the pamphlet files. The long term plan
+> is to integrate the dvi files into the mythical new front end.
+> I've skipped using pdf and ps as I consider them to be write-only
+> formats (once info is in pdf or ps form I can't use it anywhere).
+> However it is trivial to make pdf or ps files if we want since
+> the dvi files exist. See, for example,
+> mnt/linux/doc/src/algebra for the dvi files from the algebra code.
+
+So the .dvi files are considered developer documentation. I would put it
+in a axiom-developer-doc package (or whatever better name suits you).
+
+\start
+Date: Mon, 7 Jun 2004 12:07:43 -0400
+From: Tim Daly
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] debian layout
+Cc: camm@enhanced.com, Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+re: .dvi files are considered developer documentation....
+
+two comments.
+
+clearly the dhmatrix.spad.dvi file is end-user documentation. it
+contains parts of Richard Paul's PhD thesis (with permission)
+explaining the theory.
+
+the documentation of the boot and lisp level are also end-user
+documentation albeit for a different class of end-user. Axiom has
+always been the best system to use for doing math research. as such it
+often requires modification. (witness, for example, the Math on the
+Net (MONET) project which is an end-user of Axiom, not a developer,
+but needing to change the system to support the research goal).
+
+each level of documentation is both useful for the developer (such as
+myself) and as a user (such as a mathematician wanting to understand
+dhmatrices).
+
+in any case, virtually all of the files in axiom are documentation
+(pamphlet) files. look carefully and you won't see any C, lisp, boot,
+spad, makefiles, etc. it's quite artificial to split out "developer"
+documentation. in fact, in the long term Axiom will be one, large,
+integrated document.
+
+so i would argue against the 20th century mindset that documentation
+belongs in a separate package. Axiom is taking the path that there is
+no code, just documentation with execution semantics.
+
+\start
+Date: 07 Jun 2004 13:30:00 -0400
+From: Camm Maguire
+To: Tim Daly
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+Greetings!
+
+Tim Daly writes:
+
+> re: .dvi files are considered developer documentation....
+>
+> two comments.
+>
+> clearly the dhmatrix.spad.dvi file is end-user documentation. it
+> contains parts of Richard Paul's PhD thesis (with permission)
+> explaining the theory.
+>
+> the documentation of the boot and lisp level are also end-user
+> documentation albeit for a different class of end-user. Axiom has
+> always been the best system to use for doing math research. as such it
+> often requires modification. (witness, for example, the Math on the
+> Net (MONET) project which is an end-user of Axiom, not a developer,
+> but needing to change the system to support the research goal).
+>
+> each level of documentation is both useful for the developer (such as
+> myself) and as a user (such as a mathematician wanting to understand
+> dhmatrices).
+>
+> in any case, virtually all of the files in axiom are documentation
+> (pamphlet) files. look carefully and you won't see any C, lisp, boot,
+> spad, makefiles, etc. it's quite artificial to split out "developer"
+> documentation. in fact, in the long term Axiom will be one, large,
+> integrated document.
+>
+> so i would argue against the 20th century mindset that documentation
+> belongs in a separate package. Axiom is taking the path that there is
+> no code, just documentation with execution semantics.
+>
+
+Well said, and may I extend my complements for such an original and
+sensible approach. I suggest then that all documentation be in
+axiom-doc, and that this be required by axiom (i.e. not optional). I
+can't include it in the same package as the binaries, as the
+documentation is binary independent, and need not (cannot by Debian
+policy) be duplicated 12 times in the archives.
+
+Perhaps the dependency relationships of the other packages need
+altering as well?
+
+\start
+Date: Mon, 7 Jun 2004 12:43:07 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+>Well said, and may I extend my complements for such an original and
+>sensible approach. I suggest then that all documentation be in
+>axiom-doc, and that this be required by axiom (i.e. not optional). I
+>can't include it in the same package as the binaries, as the
+>documentation is binary independent, and need not (cannot by Debian
+>policy) be duplicated 12 times in the archives.
+
+>Perhaps the dependency relationships of the other packages need
+>altering as well?
+
+Camm, please rephrase this. I'm unable to understand what you are
+proposing. What do you want to change and why do you want to change it?
+
+Axiom seems to be colliding with debian rules based on some assumption
+in debian that code and documentation are separate, independent objects.
+I'm now paying the pain for this very assumption in my old code that I
+now get to maintain and change. I'm questioning this assumption and
+believe that debian rules are flawed, at least in regard to Axiom.
+
+If you ship source everything is pamphlet files.
+If you ship binaries everything will show up as dvi files.
+
+\start
+Date: 07 Jun 2004 16:25:32 -0400
+From: Camm Maguire
+To: Tim Daly
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+Greetings!
+
+Tim Daly writes:
+
+> >Well said, and may I extend my complements for such an original and
+> >sensible approach. I suggest then that all documentation be in
+> >axiom-doc, and that this be required by axiom (i.e. not optional). I
+> >can't include it in the same package as the binaries, as the
+> >documentation is binary independent, and need not (cannot by Debian
+> >policy) be duplicated 12 times in the archives.
+>
+> >Perhaps the dependency relationships of the other packages need
+> >altering as well?
+>
+> Camm, please rephrase this. I'm unable to understand what you are
+> proposing. What do you want to change and why do you want to change it?
+>
+> Axiom seems to be colliding with debian rules based on some assumption
+> in debian that code and documentation are separate, independent objects.
+> I'm now paying the pain for this very assumption in my old code that I
+> now get to maintain and change. I'm questioning this assumption and
+> believe that debian rules are flawed, at least in regard to Axiom.
+>
+> If you ship source everything is pamphlet files.
+> If you ship binaries everything will show up as dvi files.
+>
+
+Thanks for this. The Debian packaging structure need imply no
+code/documentation separation for the end user -- its only a question
+of how the material is stored in the archives. I.e. .dvi files are
+the same on m68k, mips, i386, ..., but .o files are not. Debian has a
+policy that we don't waste archive storage space by needlessly copying
+the former 12 times, and as this space is charitably donated to the
+Debian project, such a policy has clear merit :-). Furthermore, there
+are large multiarch site installations where people share binary
+independent data via nfs under /usr/share -- this is part of the Linux
+file system standard. Binary specific data must go under /usr/lib.
+
+This is not a problem vis a vis axiom, as the same apparent file
+layout can be achieved via symlinks. This is what is done in the
+current trial packages. (I can show you how to inspect the contents
+of the packages without Debian being installed if you wish).
+
+As for dependencies, each Debian package can declare relationships
+with other packages, the most common of which are 'Depends:',
+'Recommends:', and 'Suggests:'. If package 'a' 'depends' on package
+'b', it cannot be installed unless package 'b' is as well. Right now
+we have:
+
+axiom:
+ Depends: axiom-databases
+ Recommends: axiom-source, axiom-doc
+ Suggests: texmacs, axiom-tex, axiom-test, nowebm
+
+axiom-test:
+ Depends: axiom
+
+axiom-tex:
+ Depends: tetex-extra
+
+with the other packages declaring no such relationships.
+
+So for example, a user can install axiom and axiom-databases (the
+.daase files) alone at present without the source, documentation,
+test-suite files, etc. The most popular Debian installation tool,
+'apt', will pull in recommended packages as well by default, so a user
+installing axiom thereby would also install axiom-source and
+axiom-doc.
+
+What I was suggesting is that given your stated philosophy of axiom,
+we might make axiom depend on axiom-doc, so that the two would be
+inseparable. Whether or not it is a good idea to enforce this
+philosophy on people who might just want to save disk space might be
+open for discussion, but the possibility is acceptable vis a vis
+Debian policy, as the binary independent data has its own package and
+is not replicated.
+
+Please let me know if I'm still sounding muddled. Its not you -- I'm
+just pressed for time.
+
+\start
+Date: Mon, 07 Jun 2004 14:47:46 -0700
+From: Mark
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Axiom on LtU
+
+I posted this:
+http://lambda.weblogs.com/discuss/msgReader$12593
+
+It might be fruitful for someone who knows about
+Axiom (I don't) to discuss its type system and in
+particular, dependent types. Or you could just
+post links to relevant portions of the docs.
+
+\start
+Date: Tue, 8 Jun 2004 00:09:40 +0200
+From: =?iso-8859-1?Q?Fr=E9d=E9ric_Lehobey?=
+To: Camm Maguire
+Subject: Re: [Axiom-developer] debian layout
+Cc: dmentre@linux-france.org
+
+Hi,
+
+On Mon, Jun 07, 2004 at 04:25:32PM -0400, Camm Maguire wrote:
+
+> What I was suggesting is that given your stated philosophy of axiom,
+> we might make axiom depend on axiom-doc, so that the two would be
+> inseparable. Whether or not it is a good idea to enforce this
+> philosophy on people who might just want to save disk space might be
+> open for discussion, but the possibility is acceptable vis a vis
+> Debian policy, as the binary independent data has its own package and
+> is not replicated.
+
+While I agree with the general purpose of having all developer
+documentation installed and handled as user documentation, I expect
+some usage of axiom for batch computations on dedicated machines (as
+"crunching numbers"). Therefore the (Debian) dependency on axiom-doc
+may be sometimes a bit too strong. On the other hand on such
+machines, disk space should not be the real bottleneck... (You never
+have too much documentation, especially for computer algebra systems.)
+
+Sorry for those who may find this thread a bit too Debian-centric but
+most of the time questions raised by the Debian policy are sensible
+questions. In any case, you may be happy some day to use Camm soon to
+be released axiom Debian packages.
+
+\start
+Date: Mon, 7 Jun 2004 20:09:04 -0400
+From: root
+To: Frederic.Lehobey@free.fr
+Subject: Re: [Axiom-developer] debian layout
+Cc: camm@enhanced.com, dmentre@linux-france.org
+
+ok, so to summarize, if I understand correctly:
+
+there needs to be a layering in the mnt/linux subdirectory based on
+
+(1) system-dependent
+ code and data, that achieves a "minimum install image"
+ (because some people just want a runnable axiom sans anything else)
+
+(2) system-independent
+ code and data that is necessary to run the system
+ (because debian doesn't want to have 12 copies of this)
+
+(3) system independent
+ data that is useful but optional
+ (because some people just want a runnable system)
+ (because debian doesn't want to have 12 copies)
+
+The build process needs to build (1) and package for many target systems
+The build process needs to build (2) and package it once
+The build process needs to build (3) and package it once.
+
+Did I understand correctly?
+
+\start
+Date: Tue, 8 Jun 2004 16:36:25 +1000
+From: "Mike Thomas"
+To: "Axiom-Developer@Nongnu. Org"
+Subject: [Axiom-developer] Axiom on Windows
+Cc: Camm Maguire , Bill Page
+
+Hi Tim/Bill.
+
+I'm very close to getting a truncated Axiom running on Windows using the
+pending GCL 2.6.2 release code - (no sockets, Unixisms, XWindows stuff; had
+to restart make twice as it couldn't hack the pace etc). It's a mess but I
+couldn't contain my excitement!
+
+After getting through the algebra layer and making the algebra docs, GCL
+finally barfed at the point of rebuilding the databases as set out below
+(due to a path issue I think); Lisp debugger debug log below for Camm.
+
+I decided to press ahead, copying these files:
+
+c:/cvs/head/axiom/src/share/algebra/browse.daase
+c:/cvs/head/axiom/src/share/algebra/category.daase
+c:/cvs/head/axiom/src/share/algebra/compress.daase
+c:/cvs/head/axiom/src/share/algebra/interp.daase
+c:/cvs/head/axiom/src/share/algebra/operation.daase
+
+into "c:/cvs/head/axiom/mnt/windows/algebra" and the command summary into
+"mnt/windows/lib".
+
+Starting Axiom I had the very simple (and messy) session also shown below.
+
+My question is:
+
+How do I turn off the TeXish output and the module load log in a console
+session. I tried this:
+
+------------------------------------------------------------------------
+(1) -> )set output tex off
+(1) -> 1+2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/PI.o for domain
+ PositiveInteger
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/NNI.o for domain
+ NonNegativeInteger
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INT.o for domain
+ Integer
+
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/OUTFORM.o for domain
+ OutputForm
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LIST.o for domain List
+
+ (1) 3
+\axPrintType{\lispLink{\verb!(|conPage| '(
+|PositiveInteger| ))!}{\verb`Positive
+Integer`}}(2) ->
+(2) ->
+------------------------------------------------------------------------
+
+but it doesn't seem to have worked so I suppose that there is a bug here
+specific to Windows.
+
+I don't want to fall into another open source development black hole so I
+probably won't go much further with this myself, but I'm feeling very
+pleased at the moment.
+
+Bill, I can tell you what I did to get this far if you like (patch etc,
+based on your earlier posting to the group + some other stuff), but you
+would probably be better off waiting until GCL 2.6.2 is finalised and
+Tim/whomever updates the Axiom lisp source tree to reflect current trends in
+GCL development.
+
+===============================================================
+AXIOM BUILD LOG CRASH
+
+
+Use (help) to get some basic information on how to use GCL.
+ AXIOM Computer Algebra System
+ Version of Tuesday June 8, 2004 at 13:25:54
+----------------------------------------------------------------------------
+-
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+----------------------------------------------------------------------------
+-
+
+ Using local database c:/cvs/head/axiom/src/share/algebra/compress.daase..
+Using local database c:/cvs/head/axiom/src/share/algebra/interp.daase..
+ Using local database
+c:/cvs/head/axiom/src/share/algebra/operation.daase..
+ Using local database c:/cvs/head/axiom/src/share/algebra/category.daase..
+ Using local database c:/cvs/head/axiom/src/share/algebra/browse.daase..
+(1) ->
+Error: Caught fatal error [memory may be damaged]
+Fast links are on: do (si::use-fast-links nil) for debugging
+Error signalled by RETURN.
+Broken at APPLY. Type :H for Help.
+BOOT>>cp: cannot stat `c:/cvs/head/axiom/int/algebra/*.daase': No such file
+or directory
+make[3]: *** [c:/cvs/head/axiom/int/algebra/dbcomplete] Error 1
+make[3]: Leaving directory `/c/cvs/head/axiom/src/algebra'
+make[2]: *** [algebradir] Error 2
+make[2]: Leaving directory `/c/cvs/head/axiom/src'
+make[1]: *** [srcdir] Error 2
+make[1]: Leaving directory `/c/cvs/head/axiom'
+
+
+=============================================================
+MESSY AXIOM SESSION LOG
+=============================================================
+
+$ ./mnt/windows/bin/AXIOMsys.exe
+GCL (GNU Common Lisp) 2.6.2 CLtL1 Jun 8 2004 13:12:41
+Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
+Binary License: GPL due to GPL'ed components: (UNEXEC)
+Modifications of this banner must retain notice of a compatible license
+Dedicated to the memory of W. Schelter
+
+Use (help) to get some basic information on how to use GCL.
+ AXIOM Computer Algebra System
+ Version of Tuesday June 8, 2004 at 13:25:54
+----------------------------------------------------------------------------
+-
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+----------------------------------------------------------------------------
+-
+
+(1) -> summary
+
+ (1) summary
+\axPrintType{\lispLink{\verb!(|conPage| '( |Variable| (QUOTE
+ |summary| ) ))!}{\
+verb`Variable`} summary}(2) ->
+(2) -> cos 2.45
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FLOAT.o for domain
+ Float
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/PI.o for domain
+ PositiveInteger
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/REF.o for domain
+ Reference
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INT.o for domain
+ Integer
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/NNI.o for domain
+ NonNegativeInteger
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/STRING.o for domain
+ String
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/CHAR.o for domain
+ Character
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/SINT.o for domain
+ SingleInteger
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/OUTFORM.o for domain
+ OutputForm
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LIST.o for domain List
+
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/PRIMARR.o for domain
+ PrimitiveArray
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/A1AGG-.o for domain
+ OneDimensionalArrayAggregate&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INS-.o for domain
+ IntegerNumberSystem&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MONOID-.o for domain
+ Monoid&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ABELSG-.o for domain
+ AbelianSemiGroup&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/SGROUP-.o for domain
+ SemiGroup&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/REPSQ.o for package
+ RepeatedSquaring
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/EUCDOM-.o for domain
+ EuclideanDomain&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UFD-.o for domain
+ UniqueFactorizationDomain&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GCDDOM-.o for domain
+ GcdDomain&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INTDOM-.o for domain
+ IntegralDomain&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ALGEBRA-.o for domain
+ Algebra&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/DIFRING-.o for domain
+ DifferentialRing&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ORDRING-.o for domain
+ OrderedRing&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MODULE-.o for domain
+ Module&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/RING-.o for domain
+ Ring&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ABELGRP-.o for domain
+ AbelianGroup&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ABELMON-.o for domain
+ AbelianMonoid&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ORDSET-.o for domain
+ OrderedSet&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/IROOT.o for package
+ IntegerRoots
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FPS-.o for domain
+ FloatingPointSystem&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/RNS-.o for domain
+ RealNumberSystem&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FIELD-.o for domain
+ Field&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/DIVRING-.o for domain
+ DivisionRing&
+
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ISTRING.o for domain
+ IndexedString
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/SRAGG-.o for domain
+ StringAggregate&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FLAGG-.o for domain
+ FiniteLinearAggregate&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LNAGG-.o for domain
+ LinearAggregate&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UNISEG.o for domain
+ UniversalSegment
+ (2) - 0.7702312540 4730734171
+\axPrintType{\lispLink{\verb!(|conPage| '( |Float| ))!}{\verb`Float`}}(3) ->
+(3) -> 6.93*4.1328
+
+ (3) 28.640304
+\axPrintType{\lispLink{\verb!(|conPage| '( |Float| ))!}{\verb`Float`}}(4) ->
+(4) -> 6.93/4.1328
+
+ (4) 1.6768292682 926829268
+\axPrintType{\lispLink{\verb!(|conPage| '( |Float| ))!}{\verb`Float`}}(5) ->
+(5) -> 4/6
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FRAC.o for domain
+ Fraction
+
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LA.o for domain
+ LocalAlgebra
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LO.o for domain
+ Localize
+ 2
+ (5) -
+ 3
+\axPrintType{\lispLink{\verb!(|conPage| '( |Fraction| (
+|Integer| ) ))!}{\verb`F
+raction`} \lispLink{\verb!(|conPage| '(
+|Integer| ))!}{\verb`Integer`}}(6) ->
+(6) ->
+
+miketh@WATER /c/cvs/head/axiom
+$ cd /c/cvs/head/axiom/src/algebra
+
+miketh@WATER /c/cvs/head/axiom/src/algebra
+$ ../../mnt/windows/bin/AXIOMsys.exe
+GCL (GNU Common Lisp) 2.6.2 CLtL1 Jun 8 2004 13:12:41
+Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
+Binary License: GPL due to GPL'ed components: (UNEXEC)
+Modifications of this banner must retain notice of a compatible license
+Dedicated to the memory of W. Schelter
+
+Use (help) to get some basic information on how to use GCL.
+ AXIOM Computer Algebra System
+ Version of Tuesday June 8, 2004 at 13:25:54
+----------------------------------------------------------------------------
+-
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+----------------------------------------------------------------------------
+-
+
+(1) -> )lisp (make-databases "" nil)
+
+Error: Caught fatal error [memory may be damaged]
+Fast links are on: do (si::use-fast-links nil) for debugging
+Error signalled by RETURN.
+Broken at APPLY. Type :H for Help.
+BOOT>>:bt
+
+#0 APPLY {loc0=#,loc1=:error
+,loc2=nil,l...} [ihs ]
+#1 APPLY {loc0=#,loc1=:error
+,loc2=nil,l...} [ihs=19]
+#2 LAMBDA {} [ihs=16]
+#3 systemError {g160176="Can't change the current directory to
+\"NIL\".",loc1=
+"System error",lo...} [ihs=15]
+#4 LAMBDA {"NIL"=nil,} [ihs=8]
+#5 MAKE-DATABASES {ext="",g170243=nil,g170208="",loc3=nil,loc4=((|dir|
+"NIL"))
+,loc5=make-database,...} [ihs=7]
+#6 RESTART {loc0=nil,loc1=nil,loc2=nil,loc3=#} [ihs=6]
+#7 TOP-LEVEL
+{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7"c:/cvs/head/ax...} [ihs=5]
+#8 FUNCALL {loc0=#} [ihs=4]
+NIL
+BOOT>>
+
+
+
+
+From MAILER-DAEMON Tue Jun 08 02:49:32 2004
+Received: from mailman by lists.gnu.org with archive (Exim 4.33)
+ id 1BXaQO-0006EM-FT
+ for mharc-axiom-developer@gnu.org; Tue, 08 Jun 2004 02:49:32 -0400
+Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
+ id 1BXaQM-0006E2-Rw
+ for axiom-developer@nongnu.org; Tue, 08 Jun 2004 02:49:30 -0400
+Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
+ id 1BXaQM-0006Di-3E
+ for axiom-developer@nongnu.org; Tue, 08 Jun 2004 02:49:30 -0400
+Received: from [199.232.76.173] (helo=monty-python.gnu.org)
+ by lists.gnu.org with esmtp (Exim 4.33) id 1BXaQL-0006Df-VS
+ for axiom-developer@nongnu.org; Tue, 08 Jun 2004 02:49:30 -0400
+Received: from [203.52.176.30] (helo=br-dmz.paradigmgeo.com)
+ by monty-python.gnu.org with esmtp (Exim 4.34) id 1BXaPH-0008Na-0i
+ for axiom-developer@nongnu.org; Tue, 08 Jun 2004 02:48:24 -0400
+Received: from water (br-fw.brisbane.ParadigmGeo.com [203.52.176.26])
+ by br-dmz.paradigmgeo.com (8.12.10/8.12.8) with SMTP id i586lENA031930;
+ Tue, 8 Jun 2004 16:47:14 +1000
+From: "Mike Thomas"
+To: "Mike Thomas" ,
+ "Axiom-Developer@Nongnu. Org"
+Date: Tue, 8 Jun 2004 16:51:30 +1000
+Message-ID:
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="iso-8859-1"
+X-Priority: 3 (Normal)
+X-MSMail-Priority: Normal
+X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
+In-reply-to:
+Importance: Normal
+X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
+Content-Transfer-Encoding: quoted-printable
+X-MIME-Autoconverted: from 8bit to quoted-printable by br-dmz.paradigmgeo.com
+ id i586lENA031930
+Cc: Camm Maguire , Root , gcl-devel@gnu.org,
+ Bill Page
+Subject: [Axiom-developer] RE: Axiom on Windows
+X-BeenThere: axiom-developer@nongnu.org
+X-Mailman-Version: 2.1.4
+Precedence: list
+List-Id: Axiom Developers
+List-Unsubscribe: ,
+
+List-Archive:
+List-Post:
+List-Help:
+List-Subscribe: ,
+
+X-List-Received-Date: Tue, 08 Jun 2004 06:49:31 -0000
+
+PS.
+
+I hacked a way around the TeX output by redirecting to a file. I couldn't
+resist trying some examples from the Axiom book; net result is that it's all
+a bit wobbly, but it does recover from errors and the results seem to accord
+with the book. Thanks to you all for this most excellent software package,
+Auriferous Aximatic Artificers:
+
+
+(6) -> integrate((x**2+2*x+1)/((x+1)**6+1),x)
+
+ 3 2
+ atan(x + 3x + 3x + 1)
+ (6) -----------------------
+ 3
+(7) -> integrate(1/(x**2 + a),x)
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MRATFAC.o for package
+ MRationalFactorize
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MULTFACT.o for package
+ MultivariateFactorize
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INNMFACT.o for package
+ InnerMultFact
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MULTSQFR.o for package
+ MultivariateSquareFree
+
+ 2 +---+
+ (x - a)\|- a + 2a x +-+
+ log(---------------------) x\|a
+ 2 atan(-----)
+ x + a a
+ (7) [--------------------------,-----------]
+ +---+ +-+
+ 2\|- a \|a
+(8) -> y := operator =92y
+
+ (8) y
+(9) -> deq := x**3 * D(y x, x, 3) + x**2 * D(y x, x, 2) - 2 * x * D(y x, x)
++ 2
+* y x = 2 * x**4
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/EQ.o for domain
+ Equation
+
+ 3 ,,, 2 ,, , 4
+ (9) x y (x) + x y (x) - 2xy (x) + 2y(x)= 2x
+
+(10) -> solve(deq, y, x)
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEEF.o for package
+ ElementaryFunctionODESolver
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEINT.o for package
+ ODEIntegration
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO.o for domain
+ LinearOrdinaryDifferentialOperator
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/AUTOMOR.o for domain
+ Automorphism
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ORESUP.o for domain
+ SparseUnivariateSkewPolynomial
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LODEEF.o for package
+ ElementaryFunctionLODESolver
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LODOCAT-.o for domain
+ LinearOrdinaryDifferentialOperatorCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/OREPCAT-.o for domain
+ UnivariateSkewPolynomialCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO1.o for domain
+ LinearOrdinaryDifferentialOperator1
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODERAT.o for package
+ RationalLODE
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO2.o for domain
+ LinearOrdinaryDifferentialOperator2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEPRIM.o for package
+ PrimitiveRatDE
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ICDEN.o for package
+ InnerCommonDenominator
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FLAGG2.o for package
+ FiniteLinearAggregateFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/BALFACT.o for package
+ BalancedFactorisation
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/OREPCTO.o for package
+ UnivariateSkewPolynomialCategoryOps
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/BOUNDZRO.o for package
+ BoundIntegerRoots
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/BRILL.o for package
+ BrillhartTests
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FLOAT.o for domain
+ Float
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GALFACTU.o for package
+ GaloisGroupFactorizationUtilities
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FPS-.o for domain
+ FloatingPointSystem&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/RNS-.o for domain
+ RealNumberSystem&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GALUTIL.o for package
+ GaloisGroupUtilities
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UPDECOMP.o for package
+ UnivariatePolynomialDecompositionPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GHENSEL.o for package
+ GeneralHenselPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UTS.o for domain
+ UnivariateTaylorSeries
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/STREAM.o for domain
+ Stream
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UTSODETL.o for package
+ UTSodetools
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UTSODE.o for package
+ UnivariateTaylorSeriesODESolver
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ITAYLOR.o for domain
+ InnerTaylorSeries
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/STTAYLOR.o for package
+ StreamTaylorSeriesOperations
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/VECTCAT-.o for domain
+ VectorCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/YSTREAM.o for package
+ ParadoxicalCombinatorsForStreams
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LIST2.o for package
+ ListFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LZSTAGG-.o for domain
+ LazyStreamAggregate&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/STREAM2.o for package
+ StreamFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/APPLYORE.o for package
+ ApplyUnivariateSkewPolynomial
+
+ (10)
+ 5 3 2 3 2 3 3 2
+ x - 10x + 20x + 4 2x - 3x + 1 x - 1 x - 3x -
+1
+ [particular= --------------------,basis[-------------,------,------------]]
+
+ 15x x x x
+
+Error: Caught fatal error [memory may be damaged]
+Fast links are on: do (si::use-fast-links nil) for debugging
+Error signalled by RETURN.
+Broken at APPLY. Type :H for Help.
+BOOT>>:q
+(10) -> deq := (x**2 + 1) * D(y x, x, 2) + 3 * x * D(y x, x) + y x = 0
+
+ 2 ,, ,
+ (10) (x + 1)y (x) + 3xy (x) + y(x)= 0
+
+(11) -> solve(deq, y, x)
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MATRIX.o for domain
+ Matrix
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/IIARRAY2.o for domain
+ InnerIndexedTwoDimensionalArray
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MATCAT-.o for domain
+ MatrixCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MCDEN.o for package
+ MatrixCommonDenominator
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ARR2CAT-.o for domain
+ TwoDimensionalArrayCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MATCAT2.o for package
+ MatrixCategoryFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LSMP.o for package
+ LinearSystemMatrixPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MATLIN.o for package
+ MatrixLinearAlgebraFunctions
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/IMATLIN.o for package
+ InnerMatrixLinearAlgebraFunctions
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/REDORDER.o for package
+ ReductionOfOrder
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODERTRIC.o for package
+ RationalRicDE
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEPRRIC.o for package
+ PrimitiveRatRicDE
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/NLINSOL.o for package
+ NonLinearSolvePackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/RETSOL.o for package
+ RetractSolvePackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/SYSSOLP.o for package
+ SystemSolvePackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/DMP.o for domain
+ DistributedMultivariatePolynomial
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/OVAR.o for domain
+ OrderedVariableList
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/DIRPROD.o for domain
+ DirectProduct
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/PUSHVAR.o for package
+ PushVariables
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GDMP.o for domain
+ GeneralDistributedMultivariatePolynomial
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/DIRPCAT-.o for domain
+ DirectProductCategory&
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GROEBSOL.o for package
+ GroebnerSolve
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/POLTOPOL.o for package
+ PolToPol
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/HDP.o for domain
+ HomogeneousDirectProduct
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/HDMP.o for domain
+ HomogeneousDistributedMultivariatePolynomial
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GB.o for package
+ GroebnerPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GBINTERN.o for package
+ GroebnerInternalPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LGROBP.o for package
+ LinGroebnerPackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GENMFACT.o for package
+ GeneralizedMultivariateFactorize
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MPCPF.o for package
+ MPolyCatPolyFactorizer
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/GENUFACT.o for package
+ GenUFactorize
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/POLY2.o for package
+ PolynomialFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/MPRFF.o for package
+ MPolyCatRationalFunctionFactorizer
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/NTPOLFN.o for package
+ NumberTheoreticPolynomialFunctions
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/PNTHEORY.o for package
+ PolynomialNumberTheoryFunctions
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/RDETR.o for package
+ TranscendentalRischDE
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/FSINT.o for package
+ FunctionSpaceIntegration
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/EFSTRUC.o for package
+ ElementaryFunctionStructurePackage
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INTEF.o for package
+ ElementaryIntegration
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/ZLINDEP.o for package
+ IntegerLinearDependence
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/LINDEP.o for package
+ LinearDependence
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/VECTOR2.o for package
+ VectorFunctions2
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/COMBINAT.o for package
+ IntegerCombinatoricFunctions
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INTPAF.o for package
+ PureAlgebraicIntegration
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/INTG0.o for package
+ GenusZeroIntegration
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/UPCDEN.o for package
+ UnivariatePolynomialCommonDenominator
+ Loading c:/cvs/head/axiom/mnt/windows/algebra/CDEN.o for package
+ CommonDenominator
+
+ +------+
+ | 2
+ 1 log(\|x + 1 - x)
+ (11) [particular= 0,basis= [---------,------------------]]
+ +------+ +------+
+ | 2 | 2
+ \|x + 1 \|x + 1
+
+Error: Caught fatal error [memory may be damaged]
+Fast links are on: do (si::use-fast-links nil) for debugging
+Error signalled by RETURN.
+Broken at APPLY. Type :H for Help.
+BOOT>>:q
+(11) ->
+
+
+\start
+Date: Tue, 8 Jun 2004 04:23:02 -0400
+From: "Page, Bill"
+To: "'Bertfried.Fauser@uni-konstanz.de'"
+Subject: RE: [Axiom-developer] RE: learning in public
+Cc: "Bill Page \(E-mail\)"
+
+Bertfried on Wednesday, June 02, 2004 12:55 PM you wrote:
+>
+> On Tue, 1 Jun 2004, Page, Bill wrote:
+>
+> > Bertfried and Tim,
+>
+> > Formal definition
+> >
+> > Let V be a vector space over a field k, and q : V -> k
+> > a quadratic form on V. The Clifford Algebra C(q) is a
+> > unital associative algebra over k together with a linear
+> > map i : V -> C(q) defined by the following universal
+> > property:
+> >
+> > for every associative algebra A over k with a linear map
+> > j : V -> A such that for every v in V we have
+> > j(v)^2 = q(v)1 (where 1 denotes the multiplicative
+> > identity of A), there is a unique algebra homomorphism
+> >
+> > f : C(q) -> A
+> >
+> > such that the following diagram commutes:
+> >
+> > V ----> C(q)
+> > | /
+> > | / Exists and is unique
+> > | /
+> > v v
+> > A
+> >
+> > i.e. such that fi = j.
+>
+> Of course, this is standard! But....
+
+It is standard and it is categorical but even in the
+case of fields and vector spaces the constructive
+definition (in terms of a particular quotient over the
+the tensor algebra) is not at all "obvious" to me.
+
+>
+> 1) Usually you will need Clifford algebras over rings,
+> not fields, like the ring of smooth functions -> tempered
+> distributions
+>
+> 2) The form should be a bilinear form, not only a quadratic
+> form. See
+>
+> symmetric forms = bilinear forms mod alternating forms
+>
+> iff char of the base field/ring is not 2. The above
+> construction is then no longer so obvious.
+
+I do not understand why you say these generalizations
+make the constructive definition any less obvious. It
+seems to me that we can have tensor algebra over a
+module
+
+ http://planetmath.org/encyclopedia/TensorAlgebra.html
+
+and the analogous construction at
+
+ http://planetmath.org/encyclopedia/CliffordAlgebra2.html
+
+"Let M be a (left-)module over a ring R, and B:VxV->k a
+symmetric bilinear form. Then the Clifford algebra Cliff(M,B)
+is the quotient of the tensor algebra T(M) by the relations
+ v (x) w + w (x) v = -2 B(v,w)"
+
+where (x) denotes tensor product, makes good sense to me.
+I don't see any problem if B(v,w) is degenerate. The
+Z_2-grading on the tensor algebra is still inherited in
+the same way.
+
+>
+> 3) ANY base introduces a filtration. Physics is _sensitive_ to
+> this filtration, even if the algebras are _isomorphic_ and
+> hence mathematically indistinguishable. This stems from additional
+> features employed in physics. Hence it is _tremendously dangerous_
+> to introduce bases. However, certain physical applications
+> _need_ such a reference base, alas I am confused.
+
+I do not think one needs to make assumptions about a basis
+in order to prove that the Clifford algebra is filtered
+
+ http://planetmath.org/encyclopedia/FilteredAlgebra.html
+
+and (most of?) the construction of the exterior algebra
+
+ http://planetmath.org/encyclopedia/ExteriorAlgebra.html
+
+goes through.
+
+>
+> 4) From a technical point of view, the most easy construction of a
+> Clifford algebra (and that one which is capable of arbitrary even
+> degenerated bilinear forms) is that of Chevalley, which unfortunately
+> assumes a grading, which is _not_ inherent in a Clifford structure.
+>
+> Let x,y in V, u,v,w in V^, the exterior (Grassmann) algebra
+> over V (unique up to isomorphism) define the Clifford product
+> recursively as:
+>
+> i) x _| y = B(x,y) = y |_ x (bilinear for acting on VxV )
+>
+> ii) x _| (u /\ v) = (x _| u) /\ v + =DFhat{u} /\ (x _| v) (derivation)
+>
+> iii) u _| ( v _| w) = (u /\ v) _| w (left action on the module V^)
+>
+> definition: the Clifford multiplication wrt the bilinear
+> form B (used in the contraction _|) is defined as
+>
+> x =B0 u = x _| u + x /\ u
+>
+> a general element v can be multiplied by recursive use of i)
+> ii) and iii)
+>
+> This is not the most efficient algorithm, but a plain approach.
+
+Chevalley's recursive construction is interesting since it
+simultaneously builds the graded structure and the quotient.
+
+> A much better approach uses Hopf algebras and defines the
+> Clifford product as a twist by a (Laplace) 2-cocycle on the
+> Grassmann Hopf algebra.
+
+It is not immediately clear to me how this approach is
+reflected in your definition below. What part is the Hopf
+algebra and what part is the twist?
+
+>
+> Hence the way to go is:
+>
+> Define a category "graded module"
+> Define the categories symmetric and exterior algebras over
+> such a module (this amounts to introduce super symmetric
+> multilinear algebra)
+
+I think that this is equivalent to the tensor algebra
+defined above, isn't it?
+
+> Define the category of reflexive spaces with inner product.
+
+I presume you mean something more general than the
+inner product?
+
+> Define the Clifford algebra as a Functor which assigns to
+> every reflexive module a Clifford algebra.
+
+Aw, now that's the hard part isn't it? But I think it is
+the same problem as in the less general case. We need
+(somehow) to efficiently construct the appropriate quotient
+of the tensor algebra.
+
+>
+> Much better is to make this that way that an iteration can
+> be done.
+>
+
+I think I *might* know how to do this an incremental fashion
+in terms of a map (i.e. a "remember table") that defines the
+partition
+
+ T(M) ->> Cliff(M,B)
+
+given by the bilinear relations.
+
+> It is mandatory that such modules may be direct sum of graded
+> modules and that one can somehow manage the grading information,
+> eg we should think of modules composes from symmetric and
+> exterior parts
+>
+> M = Sym(V) \oplus Alt(W)
+>
+> this is needed for more advanced Cliffordizations.
+
+Isn't this logically part of in the tensor algebra and the
+Z_2-grading?
+
+>
+> hope this helps
+> ciao
+> BF.
+>
+
+Yes, I think it does. Does what I say above make sense
+to you?
+
+\start
+Date: Tue, 8 Jun 2004 04:36:32 -0400
+From: "Page, Bill"
+To: 'Mike Thomas'
+Subject: [Axiom-developer] RE: Axiom on Windows
+Cc: Camm Maguire , Bill Page
+
+Mike,
+
+Your results are fantastic!!! You have every right to
+be pleased.
+
+Yes, I can wait until GCL 2.6.2 is finished, but when
+you have a moment I really would appreciate hearing
+what you had to change. If I look at my old notes I may
+be able to find some of the path changes that I had to
+make in my last (failed) attempt.
+
+Great work!
+
+Regards,
+Bill Page.
+
+> -----Original Message-----
+> From: Mike Thomas [mailto:mike.thomas@brisbane.paradigmgeo.com]
+> Sent: Tuesday, June 08, 2004 2:36 AM
+> To: Axiom-Developer@Nongnu. Org
+> Cc: Root; gcl-devel@gnu.org; Camm Maguire; Bill Page
+> Subject: Axiom on Windows
+>
+>
+> Hi Tim/Bill.
+>
+> I'm very close to getting a truncated Axiom running on
+> Windows using the pending GCL 2.6.2 release code - (no
+> sockets, Unixisms, XWindows stuff; had to restart make
+> twice as it couldn't hack the pace etc). It's a mess but
+> I couldn't contain my excitement!
+>
+> After getting through the algebra layer and making the
+> algebra docs, GCL finally barfed at the point of rebuilding
+> the databases as set out below (due to a path issue
+> I think); Lisp debugger debug log below for Camm.
+>
+> I decided to press ahead, copying these files:
+>
+> c:/cvs/head/axiom/src/share/algebra/browse.daase
+> c:/cvs/head/axiom/src/share/algebra/category.daase
+> c:/cvs/head/axiom/src/share/algebra/compress.daase
+> c:/cvs/head/axiom/src/share/algebra/interp.daase
+> c:/cvs/head/axiom/src/share/algebra/operation.daase
+>
+> into "c:/cvs/head/axiom/mnt/windows/algebra" and the command
+> summary into
+> "mnt/windows/lib".
+>
+> Starting Axiom I had the very simple (and messy) session
+> also shown below.
+>
+> My question is:
+>
+> How do I turn off the TeXish output and the module load log
+> in a console session. I tried this:
+>
+> --------------------------------------------------------------
+>
+> (1) -> )set output tex off
+> (1) -> 1+2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/PI.o for domain
+> PositiveInteger
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/NNI.o for domain
+> NonNegativeInteger
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/INT.o for domain
+> Integer
+>
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/OUTFORM.o for domain
+> OutputForm
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LIST.o for
+> domain List
+>
+> (1) 3
+> \axPrintType{\lispLink{\verb!(|conPage| '(
+> |PositiveInteger| ))!}{\verb`Positive
+> Integer`}}(2) ->
+> (2) ->
+> --------------------------------------------------------------
+> ----------
+>
+> but it doesn't seem to have worked so I suppose that there is
+> a bug here specific to Windows.
+>
+> I don't want to fall into another open source development
+> black hole so I probably won't go much further with this
+> myself, but I'm feeling very pleased at the moment.
+>
+> Bill, I can tell you what I did to get this far if you like
+> (patch etc, based on your earlier posting to the group + some
+> other stuff), but you would probably be better off waiting until
+> GCL 2.6.2 is finalised and Tim/whomever updates the Axiom lisp
+> source tree to reflect current trends in GCL development.
+
+\start
+Date: Tue, 8 Jun 2004 07:31:46 -0400
+From: root
+To: mike.thomas@brisbane.paradigmgeo.com
+Subject: Re: [Axiom-developer] RE: Axiom on Windows
+Cc: bill.page1@sympatico.ca, mike.thomas@brisbane.paradigmgeo.com, camm@enhanced.com
+
+Awesome! I'm jazzed! Lots of requests for Windows version and
+all I can do now is mutter a reply. This means that we're much
+closer than I thought. --t
+
+\start
+Date: Tue, 8 Jun 2004 16:11:39 +0400
+From: "Serge D. Mechveliani"
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] making from CVS
+
+Recently, I reported about CVS failure.
+But it is fixed now, I am sorry for the disturbance.
+
+Also I had difficulties with `make' under tcsh.
+And it occurs to work under bash.
+All right, let `make' finish, and we'll see.
+
+I hope a large Axiom library will be usefull.
+
+With kind regards,
+
+-----------------
+Serge Mechveliani
+mechvel@botik.ru
+
+\start
+Date: Tue, 8 Jun 2004 16:41:25 +0200 (CEST)
+From: Bertfried Fauser
+To: "Page, Bill"
+Subject: RE: [Axiom-developer] RE: learning in public
+
+On Tue, 8 Jun 2004, Page, Bill wrote:
+
+Dear Bill,
+
+=09I try to recover from my holidays and a conference, to get the
+paper work off the desk, so this time only a medium size response.
+
+> > > Formal definition
+> > >
+> > > ... bla bla ...
+> > >
+> > > such that the following diagram commutes:
+> > >
+> > > V ----> C(q)
+> > > | /
+> > > | / Exists and is unique
+> > > | /
+> > > v v
+> > > A
+> > >
+
+Indeed, this construction is categorial, but not algorithmic. Hence almost
+useless for computer algebra.
+
+
+> > 2) The form should be a bilinear form, not only a quadratic
+> > form. See
+>
+> I do not understand why you say these generalizations
+> make the constructive definition any less obvious. It
+> seems to me that we can have tensor algebra over a
+> module
+
+Look at the (anti)commutation of two grade one elements, its symmetric by
+construction, so
+
+=09a (x) b + b (x) a = 2g(a,b)
+
+has to have a symmetric bilinear form. To generalize this, you need an
+_order relation_ on the grade one elements, to decide if you expand for
+a (x) b (or for b (x) a), say we take lexicographic order and lets assume
+e_i < e_j if i http://planetmath.org/encyclopedia/TensorAlgebra.html
+> http://planetmath.org/encyclopedia/CliffordAlgebra2.html
+
+I will look for these, but hadn't yet time.
+
+
+> "Let M be a (left-)module over a ring R, and B:VxV->k a
+> symmetric bilinear form. Then the Clifford algebra Cliff(M,B)
+> is the quotient of the tensor algebra T(M) by the relations
+> v (x) w + w (x) v = -2 B(v,w)"
+>
+> where (x) denotes tensor product, makes good sense to me.
+> I don't see any problem if B(v,w) is degenerate. The
+> Z_2-grading on the tensor algebra is still inherited in
+> the same way.
+
+In my eyes, the Clifford algebra is associated to a (graded) symmetric
+algebra (which is already a quotient of teh tensor algebra) and not
+directly to the tensor algebra, so the construction spezializes as:
+
+Tensor algebra -> Graded Symmetric Algebra (ie Grassmann involved!)
+ -> Clifford Algebra (symplectic case = Weyl algebra involved!)
+
+> I do not think one needs to make assumptions about a basis
+> in order to prove that the Clifford algebra is filtered
+>
+> http://planetmath.org/encyclopedia/FilteredAlgebra.html
+>
+> and (most of?) the construction of the exterior algebra
+>
+> http://planetmath.org/encyclopedia/ExteriorAlgebra.html
+>
+> goes through.
+
+Point is, that in physics one deals not with the the plain algebraic
+structures, but withaugmented ones. Eg, in QFT, one has to deal with
+normal ordered and time ordered n-point functions. These for an algebra.
+The normal odered field operators form a bicommutative Hopf algebra
+(graded symmetric Hopf algebra). However, the normal and time odered
+algebras are *isomorphic as Hopf algebras*!! However, they describe
+totally different physical entities under the evaluation (counit) map
+
+<0| : \psi_1\psi_2 ... \psi_n : |0> = \phi_n
+<0| T(\psi_1\psi_2 ... \psi_n ) |0> = \tau_n
+
+and the transition is an bijective map, the Wick expansion. Both algebras
+differ _only_ in their filtration and can be distinguished, since they are
+evaluated with respect to the _same_ physical vaccum, which is not
+transformed! This is one of the major applications of Clifford algebra
+structures in QFT and should be modeled in computer algebra, as was done
+in Clifford/Bigebra.
+
+
+> Chevalley's recursive construction is interesting since it
+> simultaneously builds the graded structure and the quotient.
+
+A couple of clifford packages were build upon these relations. However,
+for fully symbolic computations, the recursion produces terms, which
+cancel out in the next step of recursion, so the methos if by fare not
+optimal. Example
+
+ (a /\ b) =B0 c = (a =B0 b - g(a,b) ) =B0 c # look at the g(a,b) term
+ = a =B0 ( b /\ c + g(b,c)) - g(a,b) c
+ = a _| (b /\ c + g(b,c)) + a /\ ( b /\ c + g(b,c)) - g(a,b) c
+ = g(a,b) c - g(a,c) b + g(b,c) a - g(a,b) c + a /\ b /\ c
+ = g(b,c) a - g(a,c) b + a /\ b /\ c
+
+etc....
+
+Hopf:
+> It is not immediately clear to me how this approach is
+> reflected in your definition below. What part is the Hopf
+> algebra and what part is the twist?
+
+Mail is probably not the right diection to write this down. If you are
+interested, you might find the 2nd chapter of my hablitation usefull for
+finding variouse definitions of Clifford algebras, the Hopf approch is
+exactly the subject of this work (math.QA/0202059 and a concise short
+explanation is found in the cookeville proceedings chapter
+math-ph/0208018) More techical stuff can be found in (math-ph/0212031 and
+math-ph/0212032, where explicite Clifford and Bigebra calculations are
+shown) There you will see also that nonsymmetric bilinear forms are
+mandatory. ;-))
+
+
+> > Define a category "graded module"
+> > Define the categories symmetric and exterior algebras over
+> > such a module (this amounts to introduce super symmetric
+> > multilinear algebra)
+>
+> I think that this is equivalent to the tensor algebra
+> defined above, isn't it?
+
+Nearly, its algraedy the quotione to the Grassmann (symmetric) algebra.
+
+> > Define the category of reflexive spaces with inner product.
+>
+> I presume you mean something more general than the
+> inner product?
+
+Depends on what you mean by inner product. In fact there are quite a lot
+different such products available, but only a special bilinear form
+(namely one which is a Laplace 2-cocycle) plays an algorithioc role. See
+my habilitation....
+
+
+> > Define the Clifford algebra as a Functor which assigns to
+> > every reflexive module a Clifford algebra.
+>
+> Aw, now that's the hard part isn't it? But I think it is
+> the same problem as in the less general case. We need
+> (somehow) to efficiently construct the appropriate quotient
+> of the tensor algebra.
+
+Yes, indeed. However, this should be done in a so sensible way, that we
+can deal with many structures at the same time.
+
+tensor -> graded symmetric = [Grassmann | Symmetric] -> Clifford | Weyl
+
+In this way, the algebra of symmetric functions is also a Clifford (Hopf)
+algebra, ;-)))
+
+> I think I *might* know how to do this an incremental fashion
+> in terms of a map (i.e. a "remember table") that defines the
+> partition
+>
+> T(M) ->> Cliff(M,B)
+
+Thats not so difficult, however, in Maple we failed to compute the
+multiplication table! Due to memory and time constraints. Maple 5 was not
+able to compute the thing due to a 2^15 bit pointer restriction and maple
+6 onwards was not able to do it because of memory constraints (I have 1GB
+though) and the computation did not finish in reasonable time (weeks!)
+Hence the product has to be evaluated on the spot. In Clifford we have
+hash tables for already computed products on a low level (bilinear form
+independent, since the form may be changed during computation)
+
+> Isn't this logically part of in the tensor algebra and the
+> Z_2-grading?
+
+No, I think about super symmetric (multi) linear algebra. A very good
+reference is
+
+@INPROCEEDINGS{grosshans:rota:stein:1987a
+ ,AUTHOR = {Grosshans, {Frank D.} and Rota, {Gian-Carlo} and
+Stein, {Joel A.}}
+ ,BOOKTITLE = {conference board of the mathematical sciences regional
+conference series in mathematics, number 69}
+ ,ID = {13}
+ ,PAGES = {i--xxi,1--80}
+ ,PUBLISHER = {American Mathematical Society}
+ ,TITLE = {Invariant theory and superalgebras}
+ ,YEAR = {1987}
+}
+
+There you will notice the complexity of the problem.
+
+A further remark:
+
+The most impressive and compelling paper on Clifford algebra is the
+following (pair, the first one is sufficient for almost all computer
+algebra issues about the subject)
+
+@ARTICLE{rota:stein:1994a
+ ,AUTHOR = {Rota, {Gian-Carlo} and Stein, {Joel A.}}
+ ,ID = {6}
+ ,JOURNAL = {Proc. Natl. Acad. Sci. USA}
+ ,MONTH = {December}
+ ,PAGES = {13057--13061}
+ ,TITLE = {Plethystic {H}opf algebras}
+ ,VOLUME = {91}
+ ,YEAR = {1994}
+}
+@ARTICLE{rota:stein:1994b
+ ,AUTHOR = {Rota, {Gian-Carlo} and Stein, {Joel A.}}
+ ,ID = {7}
+ ,JOURNAL = {Proc. Natl. Acad. Sci. USA}
+ ,MONTH = {December}
+ ,PAGES = {13062--13066}
+ ,TITLE = {Plethystic algebras and vector symmetric functions}
+ ,VOLUME = {91}
+ ,YEAR = {1994}
+}
+
+Rota and Stein there developed a theory of high abstraction (I try to
+understand this paper since 1999 (Ixtapa conference) in an algorithmic
+way but have not yet fully suceeded ....) You will notice however, that
+the paper _is_ algorithmic in nature, as is the above cited work too!
+
+To my best knowlegde, the three citations I made in this mail are the most
+unique sources to a super symmetric multilinear algebra which contains
+almost all algebra necessary for eg QFT. However, its also the most highly
+abstracted thing (beside one further paper on the representation of
+matroids, which I will not cite) which I know, so its the best approch for
+an AXIOM implementation of the subject.
+
+
+My Problem:
+
+Still I am not able to envision a data structure complex enough to hold
+the problem and simple enough not to make everything totally unmanagable.
+A good start would be to write an AXIOM package for supersymmetric
+bi-commutative Hopf algebras, if thats done, cliffordization is relatively
+easy to implement.
+
+My Abilities:
+
+Right now, I am in posession of algorithms, which I can document
+precicely, of the above described strutures. So if I would have a domain
+(category) where the implementation part is missing, but types, etc were
+defined, I could come up with highly efficient algorithms for the
+implementation part.
+
+Details later.
+
+\start
+Date: 08 Jun 2004 11:04:21 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: [Axiom-developer] C library support [ was Re: BLAS and GCL ]
+Cc: "Paul F. Dietz" , Aurelien Chanudet
+
+Greetings! This topic triggered an old idea which should be a major
+GCL feature if it would be workable. We should be able to write a
+function which would take a library name and a C header file name as
+arguments and create a new GCL image with the library linked in and
+all its exported functions accessible via lisp wrappers in a new
+package of the same name as the library.
+
+In more detail:
+
+1) read the piped output of 'nm' or 'nm --dynamic' on the library and
+ collect the exported symbols
+
+2) make a readtable which can parse the header file to read the
+ prototypes. Paul do you know of such a parser already available?
+
+2.5) make a package with the same name as the library
+
+3) translate the information in 2) directly into a defentry line
+
+4) proclaim the function, write an compiler::inline entry to optimize
+ the call.
+
+5) export the symbols in the new package
+
+6) (compiler::link (list "defentries.o") "new_image" "package_maker.lisp"
+ "-lfoo -lbar")
+
+
+For the standard C argument types, this should work with no further
+effort. The problem is that structure arguments, double pointers
+(e.g. **), etc. will need new 'object_to_...' utilities in cmpaux.c,
+care should be taken with external functions which may call malloc,
+and defstruct calls would likely need to be constructed for each
+typedef struct to make many functions usable.
+
+Beyond this I just wanted to repeat the outstanding linker limitation
+and cc Aurelien in case he might have ideas -- our internal linker is
+static. Would it be possible to detect a symbol which could not be
+statically relocated, but could nonetheless be found with dlsym in the
+currently used shared libs, use that address for the current session,
+and alter the dynamic linker table of the running executable to mark
+this symbol for treatment by ld.so on subsequent execution after an
+unexec/save-system?
+
+The biggest complaint about lisp is the (lack of) library support, and
+the idea of reimplementing everything in lisp appears to me to be a
+definite non-starter. Were such a modular approach to external C libs
+attainable, one could dispense with separate support for xgcl, pargcl,
+etc. and greatly simplify future maintenance.
+
+\start
+Date: Tue, 8 Jun 2004 07:27:20 -0400
+From: root
+To: mike.thomas@brisbane.paradigmgeo.com
+Subject: [Axiom-developer] Re: Axiom on Windows
+Cc: bill.page1@sympatico.ca, camm@enhanced.com
+
+Mike,
+
+Fantastic.
+
+The loading output messages can be turned off with
+)set message autoload off
+
+The second output strings appear to be for the Saturn
+interface (which is now techexplorer). These can also
+be turned off but my running copy doesn't have the
+code so I can't find the correct msg string. I'll look
+at it in work later today.
+
+Great stuff though. Very encouraging.
+Thanks for the effort.
+
+\start
+Date: 08 Jun 2004 11:48:58 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+Greetings!
+
+root writes:
+
+> ok, so to summarize, if I understand correctly:
+>
+> there needs to be a layering in the mnt/linux subdirectory based on
+>
+> (1) system-dependent
+> code and data, that achieves a "minimum install image"
+> (because some people just want a runnable axiom sans anything else)
+>
+> (2) system-independent
+> code and data that is necessary to run the system
+> (because debian doesn't want to have 12 copies of this)
+>
+> (3) system independent
+> data that is useful but optional
+> (because some people just want a runnable system)
+> (because debian doesn't want to have 12 copies)
+>
+> The build process needs to build (1) and package for many target systems
+> The build process needs to build (2) and package it once
+> The build process needs to build (3) and package it once.
+>
+> Did I understand correctly?
+>
+
+Yes, this is basically correct. A few clarifications:
+
+1) You need not do anything in mnt/linux if you don't deem it
+ necessary/advisable yourself -- the Debian package rules can take
+ care of this as axiom stands.
+
+2) system-independent stuff needs to go under /usr/share,
+ system-dependent stuff under /usr/lib. The sensible way to do this
+ is to have one directory for axiom under /usr/lib, aggregate each
+ category into separate subdirectories, as is mostly done at present
+ (e.g. input has system-independent files only), move the
+ subdirectory as a whole into the right place and symlink it back
+ into the main file layout hierarchy. The aggregation minimizes the
+ number of needed symlinks.
+
+3) There may also be system-dependent optional stuff -- it depends on
+ the program. I.e. there is a two by two grid, with the
+ required/optional designation determined by a judgment call based
+ on experience using of the program, and the dependent/independent
+ designation being a function of the file type. This said, there
+ is some flexibility with system-independent files which are small.
+
+4) You are exactly correct regarding the build process -- the various
+ ports only compile the binary-dependent packages. The
+ binary-independent packages are built by the maintainer and
+ uploaded only once.
+
+\start
+Date: Tue, 8 Jun 2004 11:00:23 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] debian layout
+Cc: Frederic.Lehobey@free.fr, dmentre@linux-france.org
+
+ok. i get it now. i was being thick.
+i'll give it some thought.
+i already have the axiom build set up in this way
+for the various intermediate subdirs (src/int/obj/mnt)
+so it is likely that i can hack it so there can be
+build options for the 4 parts of the grid.
+
+of course, there is no such thing as a simple job.
+
+\start
+Date: Tue, 8 Jun 2004 10:08:27 -0400
+From: Tim Daly
+To: mechvel@botik.ru
+Subject: [Axiom-developer] axiom download
+
+create a file in your home directory
+an .ssh directory with a file called "config" containing:
+
+.ssh/config
+
+Host *.gnu.org
+ Protocol=2
+ Compression=yes
+ CompressionLevel=6
+ StrictHostKeyChecking=no
+
+
+Then type:
+
+cd /tmp <=== where you want to put the axiom sources
+export CVS_RSH=ssh
+cvs -d:ext:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom
+cd axiom
+export AXIOM=/tmp/axiom/mnt/linux
+ ^^^^ where you put the axiom sources
+export PATH=$AXIOM/bin:$PATH
+make
+
+When the make completes type:
+
+axiom
+
+\start
+Date: Tue, 08 Jun 2004 19:45:40 +0200
+From: David MENTRE
+To: "Mike Thomas"
+Subject: Re: [Axiom-developer] Axiom on Windows
+Cc: Camm Maguire , Bill Page
+
+Hello Mike,
+
+While I'm not a strong proponent of Windows (to say the least), I do
+find a Windows port of Axiom of great importance for both Axiom and free
+software in general. I therefore applause your hard work.
+
+"Mike Thomas" writes:
+
+> Using local database c:/cvs/head/axiom/src/share/algebra/compress.daase..
+> Using local database c:/cvs/head/axiom/src/share/algebra/interp.daase..
+> Using local database
+> c:/cvs/head/axiom/src/share/algebra/operation.daase..
+> Using local database c:/cvs/head/axiom/src/share/algebra/category.daase..
+> Using local database c:/cvs/head/axiom/src/share/algebra/browse.daase..
+> (1) ->
+> Error: Caught fatal error [memory may be damaged]
+> Fast links are on: do (si::use-fast-links nil) for debugging
+> Error signalled by RETURN.
+> Broken at APPLY. Type :H for Help.
+> BOOT>>cp: cannot stat `c:/cvs/head/axiom/int/algebra/*.daase': No such file
+> or directory
+> make[3]: *** [c:/cvs/head/axiom/int/algebra/dbcomplete] Error 1
+
+It seems to me that the glob '*.daase' has not been expanded somewhere.
+
+On my own copy of Axiom, I have:
+browse.daase category.daase compress.daase interp.daase operation.daase
+
+So, either the .daase file are not properly made or the globing is not
+done. Have you more input on this?
+
+\start
+Date: Tue, 08 Jun 2004 19:54:40 +0200
+From: David MENTRE
+To: "Mike Thomas"
+Subject: Re: [Axiom-developer] Axiom on Windows
+Cc: Camm Maguire , Bill Page
+
+Mike, have you a log of the whole build process?
+
+\start
+Date: 08 Jun 2004 15:53:06 -0400
+From: Camm Maguire
+To: "Mike Thomas"
+Subject: [Axiom-developer] Re: Axiom on Windows
+Cc: Bill Page
+
+Greetings!
+
+"Mike Thomas" writes:
+
+> Hi Tim/Bill.
+>
+> I'm very close to getting a truncated Axiom running on Windows using the
+> pending GCL 2.6.2 release code - (no sockets, Unixisms, XWindows stuff; had
+> to restart make twice as it couldn't hack the pace etc). It's a mess but I
+> couldn't contain my excitement!
+>
+> After getting through the algebra layer and making the algebra docs, GCL
+> finally barfed at the point of rebuilding the databases as set out below
+> (due to a path issue I think); Lisp debugger debug log below for Camm.
+>
+
+See comments below.
+
+> I decided to press ahead, copying these files:
+>
+> c:/cvs/head/axiom/src/share/algebra/browse.daase
+> c:/cvs/head/axiom/src/share/algebra/category.daase
+> c:/cvs/head/axiom/src/share/algebra/compress.daase
+> c:/cvs/head/axiom/src/share/algebra/interp.daase
+> c:/cvs/head/axiom/src/share/algebra/operation.daase
+>
+> into "c:/cvs/head/axiom/mnt/windows/algebra" and the command summary into
+> "mnt/windows/lib".
+>
+
+yes, one can copy these files into place and avoid the database
+rebuild. There is another way that Tim described on the Axiom list
+some time ago which I have forgotten. On ia64 mips mipsel alpha and
+hppa, where we have no save-system, this step exceeds the open file
+descriptor limit (1024) with all the calls to dlopen, so we do
+something similar there for Debian.
+
+> miketh@WATER /c/cvs/head/axiom/src/algebra
+> $ ../../mnt/windows/bin/AXIOMsys.exe
+> GCL (GNU Common Lisp) 2.6.2 CLtL1 Jun 8 2004 13:12:41
+> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
+> Binary License: GPL due to GPL'ed components: (UNEXEC)
+> Modifications of this banner must retain notice of a compatible license
+> Dedicated to the memory of W. Schelter
+>
+> Use (help) to get some basic information on how to use GCL.
+> AXIOM Computer Algebra System
+> Version of Tuesday June 8, 2004 at 13:25:54
+> ----------------------------------------------------------------------------
+> -
+> Issue )copyright to view copyright notices.
+> Issue )summary for a summary of useful system commands.
+> Issue )quit to leave AXIOM and return to shell.
+> ----------------------------------------------------------------------------
+> -
+>
+> (1) -> )lisp (make-databases "" nil)
+>
+
+I am unsure if this is the right command. But in any case, one needs
+to set (possibly several) environment variables, at least
+AXIOM=$(pwd)/mnt/windows, before running this.
+
+It looks like the 'nil' you find below is either that supplied as an
+argument above or results from the missing environment. In any case,
+should this persist, it would be helpful (for someone, not you
+hopefully, you overworked soul!) to repeat the below with
+(si::use-fast-links nil) and under gdb with --enable-debug passed to
+the GCL configure and build.
+
+Take care,
+
+> Error: Caught fatal error [memory may be damaged]
+> Fast links are on: do (si::use-fast-links nil) for debugging
+> Error signalled by RETURN.
+> Broken at APPLY. Type :H for Help.
+> BOOT>>:bt
+>
+> #0 APPLY {loc0=# system:universal-error-handler>,loc1=:error
+> ,loc2=nil,l...} [ihs ]
+> #1 APPLY {loc0=# system:universal-error-handler>,loc1=:error
+> ,loc2=nil,l...} [ihs=19]
+> #2 LAMBDA {} [ihs=16]
+> #3 systemError {g160176="Can't change the current directory to
+> \"NIL\".",loc1> "System error",lo...} [ihs=15]
+> #4 LAMBDA {"NIL"=nil,} [ihs=8]
+> #5 MAKE-DATABASES {ext="",g170243=nil,g170208="",loc3=nil,loc4=((|dir|
+> "NIL"))
+> ,loc5=make-database,...} [ihs=7]
+> #6 RESTART {loc0=nil,loc1=nil,loc2=nil,loc3=# make-databases
+> >} [ihs=6]
+> #7 TOP-LEVEL
+> {loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7> "c:/cvs/head/ax...} [ihs=5]
+> #8 FUNCALL {loc0=#} [ihs=4]
+> NIL
+> BOOT>>
+
+\start
+Date: 08 Jun 2004 15:55:12 -0400
+From: Camm Maguire
+To: "Mike Thomas"
+Subject: [Axiom-developer] Re: Axiom on Windows
+Cc: Bill Page
+
+Greetings! Mike this is very exciting! Someone should back off the C
+optimization with an --enable-debug GCL build, and report any
+persisting segfault with a gdb backtrace, time of course permitting!
+
+Such an example might even run under wine, as it does not fork any
+subprocesses.
+
+Take care,
+
+"Mike Thomas" writes:
+
+> PS.
+>
+> I hacked a way around the TeX output by redirecting to a file. I couldn't
+> resist trying some examples from the Axiom book; net result is that it's all
+> a bit wobbly, but it does recover from errors and the results seem to accord
+> with the book. Thanks to you all for this most excellent software package,
+> Auriferous Aximatic Artificers:
+>
+>
+> (6) -> integrate((x**2+2*x+1)/((x+1)**6+1),x)
+>
+> 3 2
+> atan(x + 3x + 3x + 1)
+> (6) -----------------------
+> 3
+> (7) -> integrate(1/(x**2 + a),x)
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MRATFAC.o for package
+> MRationalFactorize
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MULTFACT.o for package
+> MultivariateFactorize
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/INNMFACT.o for package
+> InnerMultFact
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MULTSQFR.o for package
+> MultivariateSquareFree
+>
+> 2 +---+
+> (x - a)\|- a + 2a x +-+
+> log(---------------------) x\|a
+> 2 atan(-----)
+> x + a a
+> (7) [--------------------------,-----------]
+> +---+ +-+
+> 2\|- a \|a
+> (8) -> y := operator =92y
+>
+> (8) y
+> (9) -> deq := x**3 * D(y x, x, 3) + x**2 * D(y x, x, 2) - 2 * x * D(y x, x)
+> + 2
+> * y x = 2 * x**4
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/EQ.o for domain
+> Equation
+>
+> 3 ,,, 2 ,, , 4
+> (9) x y (x) + x y (x) - 2xy (x) + 2y(x)= 2x
+>
+> (10) -> solve(deq, y, x)
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEEF.o for package
+> ElementaryFunctionODESolver
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEINT.o for package
+> ODEIntegration
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO.o for domain
+> LinearOrdinaryDifferentialOperator
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/AUTOMOR.o for domain
+> Automorphism
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ORESUP.o for domain
+> SparseUnivariateSkewPolynomial
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LODEEF.o for package
+> ElementaryFunctionLODESolver
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LODOCAT-.o for domain
+> LinearOrdinaryDifferentialOperatorCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/OREPCAT-.o for domain
+> UnivariateSkewPolynomialCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO1.o for domain
+> LinearOrdinaryDifferentialOperator1
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODERAT.o for package
+> RationalLODE
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LODO2.o for domain
+> LinearOrdinaryDifferentialOperator2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEPRIM.o for package
+> PrimitiveRatDE
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ICDEN.o for package
+> InnerCommonDenominator
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/FLAGG2.o for package
+> FiniteLinearAggregateFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/BALFACT.o for package
+> BalancedFactorisation
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/OREPCTO.o for package
+> UnivariateSkewPolynomialCategoryOps
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/BOUNDZRO.o for package
+> BoundIntegerRoots
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/BRILL.o for package
+> BrillhartTests
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/FLOAT.o for domain
+> Float
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GALFACTU.o for package
+> GaloisGroupFactorizationUtilities
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/FPS-.o for domain
+> FloatingPointSystem&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/RNS-.o for domain
+> RealNumberSystem&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GALUTIL.o for package
+> GaloisGroupUtilities
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/UPDECOMP.o for package
+> UnivariatePolynomialDecompositionPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GHENSEL.o for package
+> GeneralHenselPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/UTS.o for domain
+> UnivariateTaylorSeries
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/STREAM.o for domain
+> Stream
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/UTSODETL.o for package
+> UTSodetools
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/UTSODE.o for package
+> UnivariateTaylorSeriesODESolver
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ITAYLOR.o for domain
+> InnerTaylorSeries
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/STTAYLOR.o for package
+> StreamTaylorSeriesOperations
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/VECTCAT-.o for domain
+> VectorCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/YSTREAM.o for package
+> ParadoxicalCombinatorsForStreams
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LIST2.o for package
+> ListFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LZSTAGG-.o for domain
+> LazyStreamAggregate&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/STREAM2.o for package
+> StreamFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/APPLYORE.o for package
+> ApplyUnivariateSkewPolynomial
+>
+> (10)
+> 5 3 2 3 2 3 3 2
+> x - 10x + 20x + 4 2x - 3x + 1 x - 1 x - 3x -
+> 1
+> [particular= --------------------,basis> [-------------,------,------------]]
+>
+> 15x x x x
+>
+> Error: Caught fatal error [memory may be damaged]
+> Fast links are on: do (si::use-fast-links nil) for debugging
+> Error signalled by RETURN.
+> Broken at APPLY. Type :H for Help.
+> BOOT>>:q
+> (10) -> deq := (x**2 + 1) * D(y x, x, 2) + 3 * x * D(y x, x) + y x = 0
+>
+> 2 ,, ,
+> (10) (x + 1)y (x) + 3xy (x) + y(x)= 0
+>
+> (11) -> solve(deq, y, x)
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MATRIX.o for domain
+> Matrix
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/IIARRAY2.o for domain
+> InnerIndexedTwoDimensionalArray
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MATCAT-.o for domain
+> MatrixCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MCDEN.o for package
+> MatrixCommonDenominator
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ARR2CAT-.o for domain
+> TwoDimensionalArrayCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MATCAT2.o for package
+> MatrixCategoryFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LSMP.o for package
+> LinearSystemMatrixPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MATLIN.o for package
+> MatrixLinearAlgebraFunctions
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/IMATLIN.o for package
+> InnerMatrixLinearAlgebraFunctions
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/REDORDER.o for package
+> ReductionOfOrder
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODERTRIC.o for package
+> RationalRicDE
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ODEPRRIC.o for package
+> PrimitiveRatRicDE
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/NLINSOL.o for package
+> NonLinearSolvePackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/RETSOL.o for package
+> RetractSolvePackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/SYSSOLP.o for package
+> SystemSolvePackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/DMP.o for domain
+> DistributedMultivariatePolynomial
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/OVAR.o for domain
+> OrderedVariableList
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/DIRPROD.o for domain
+> DirectProduct
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/PUSHVAR.o for package
+> PushVariables
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GDMP.o for domain
+> GeneralDistributedMultivariatePolynomial
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/DIRPCAT-.o for domain
+> DirectProductCategory&
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GROEBSOL.o for package
+> GroebnerSolve
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/POLTOPOL.o for package
+> PolToPol
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/HDP.o for domain
+> HomogeneousDirectProduct
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/HDMP.o for domain
+> HomogeneousDistributedMultivariatePolynomial
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GB.o for package
+> GroebnerPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GBINTERN.o for package
+> GroebnerInternalPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LGROBP.o for package
+> LinGroebnerPackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GENMFACT.o for package
+> GeneralizedMultivariateFactorize
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MPCPF.o for package
+> MPolyCatPolyFactorizer
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/GENUFACT.o for package
+> GenUFactorize
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/POLY2.o for package
+> PolynomialFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/MPRFF.o for package
+> MPolyCatRationalFunctionFactorizer
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/NTPOLFN.o for package
+> NumberTheoreticPolynomialFunctions
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/PNTHEORY.o for package
+> PolynomialNumberTheoryFunctions
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/RDETR.o for package
+> TranscendentalRischDE
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/FSINT.o for package
+> FunctionSpaceIntegration
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/EFSTRUC.o for package
+> ElementaryFunctionStructurePackage
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/INTEF.o for package
+> ElementaryIntegration
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/ZLINDEP.o for package
+> IntegerLinearDependence
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/LINDEP.o for package
+> LinearDependence
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/VECTOR2.o for package
+> VectorFunctions2
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/COMBINAT.o for package
+> IntegerCombinatoricFunctions
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/INTPAF.o for package
+> PureAlgebraicIntegration
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/INTG0.o for package
+> GenusZeroIntegration
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/UPCDEN.o for package
+> UnivariatePolynomialCommonDenominator
+> Loading c:/cvs/head/axiom/mnt/windows/algebra/CDEN.o for package
+> CommonDenominator
+>
+> +------+
+> | 2
+> 1 log(\|x + 1 - x)
+> (11) [particular= 0,basis= [---------,------------------]]
+> +------+ +------+
+> | 2 | 2
+> \|x + 1 \|x + 1
+>
+> Error: Caught fatal error [memory may be damaged]
+> Fast links are on: do (si::use-fast-links nil) for debugging
+> Error signalled by RETURN.
+> Broken at APPLY. Type :H for Help.
+> BOOT>>:q
+> (11) ->
+
+\start
+Date: 08 Jun 2004 15:57:33 -0400
+From: Camm Maguire
+To: David MENTRE
+Subject: Re: [Axiom-developer] Axiom on Windows
+Cc: Mike Thomas , Bill Page
+
+Greetings!
+
+David MENTRE writes:
+
+> Hello Mike,
+>
+> While I'm not a strong proponent of Windows (to say the least), I do
+> find a Windows port of Axiom of great importance for both Axiom and free
+> software in general. I therefore applause your hard work.
+>
+> "Mike Thomas" writes:
+>
+> > Using local database c:/cvs/head/axiom/src/share/algebra/compress.daase..
+> > Using local database c:/cvs/head/axiom/src/share/algebra/interp.daase..
+> > Using local database
+> > c:/cvs/head/axiom/src/share/algebra/operation.daase..
+> > Using local database c:/cvs/head/axiom/src/share/algebra/category.daase..
+> > Using local database c:/cvs/head/axiom/src/share/algebra/browse.daase..
+> > (1) ->
+> > Error: Caught fatal error [memory may be damaged]
+> > Fast links are on: do (si::use-fast-links nil) for debugging
+> > Error signalled by RETURN.
+> > Broken at APPLY. Type :H for Help.
+> > BOOT>>cp: cannot stat `c:/cvs/head/axiom/int/algebra/*.daase': No such file
+> > or directory
+> > make[3]: *** [c:/cvs/head/axiom/int/algebra/dbcomplete] Error 1
+>
+> It seems to me that the glob '*.daase' has not been expanded somewhere.
+>
+
+I wish it were this simple, but unfortunately, I think it likely that
+the crash is happening earlier, the *.daase files are not being
+written, and the copy in the build scripts is therefore failing.
+
+Take care,
+
+> On my own copy of Axiom, I have:
+> browse.daase category.daase compress.daase interp.daase operation.daase
+>
+> So, either the .daase file are not properly made or the globing is not
+> done. Have you more input on this?
+
+\start
+Date: Wed, 9 Jun 2004 09:44:07 +1000
+From: "Mike Thomas"
+To: "Camm Maguire"
+Subject: [Axiom-developer] RE: [Gcl-devel] Re: Axiom on Windows
+
+Hi Camm.
+
+| yes, one can copy these files into place and avoid the database
+| rebuild. There is another way that Tim described on the Axiom list
+| some time ago which I have forgotten. On ia64 mips mipsel alpha and
+| hppa, where we have no save-system, this step exceeds the open file
+| descriptor limit (1024) with all the calls to dlopen, so we do
+| something similar there for Debian.
+
+OK, thanks for that advice.
+
+| > (1) -> )lisp (make-databases "" nil)
+| >
+|
+| I am unsure if this is the right command.
+
+It's transcribed from the Makefile.
+
+| But in any case, one needs
+| to set (possibly several) environment variables, at least
+| AXIOM=$(pwd)/mnt/windows, before running this.
+
+Both AXIOM and PATH had been set according to the configure message.
+
+| It looks like the 'nil' you find below is either that supplied as an
+| argument above or results from the missing environment. In any case,
+| should this persist, it would be helpful (for someone, not you
+| hopefully, you overworked soul!) to repeat the below with
+| (si::use-fast-links nil) and under gdb with --enable-debug passed to
+| the GCL configure and build.
+
+As it happened, before I worked out that my GCL source tree was being
+overwritten I set --enable-debug in the makefile pamphlet to try and catch
+the crash that was manifesting with the standard Axiom lisp source. If I
+get a chance over the coming few days I'll try looking further.
+
+\start
+Date: Tue, 08 Jun 2004 19:54:28 -0400
+From: William Sit
+To: Tim Daly , axiom-developer@nongnu.org
+Subject: [Axiom-developer] Software Archaeology
+
+Hi Tim:
+
+I came across the email by
+
+[Axiom-developer] Patches (?) for sum/product and sqrt
+Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
+From: "m.rubey"
+To: axiom-developer@nongnu.org
+
+(aside: I suppose that the messages on the axiom site are sequenced, so it would
+be convenient if this sequence number is part of the message broadcast, perhaps
+added to the subject line like [axiom=developer xxxxx]. Using this reference may
+save a lot of bandwidth since it is easy to lookup (how about also a http
+link?))
+
+and was trying to trace some of the code by Bronstein (dvdsum). It then occurs
+to me that what is needed is a full documentation for undocumented Axiom code,
+which means reconstructing the thoughts behind the design, etc, as well as the
+mathematics. This I thought should be termed "software archaeology" (like
+reading the papyrus). So there "should" be funding source for such an endeavor.
+I google the term and came up with one single item: an abstract of a talk by one
+Grady Booch, who happens to be an IBM Fellow (since 2003). He is quite keen on
+software archaeology and maintains a blog. Here's the URLs:
+
+http://www.booch.com/architecture/blog.jsp (read his June 7 blog; he has a
+project called computer history museum and recommends reading Knuth's literate
+programming)
+
+http://www-306.ibm.com/software/rational/bios/booch.html (this is the IBM Fellow
+and IBM Rational site on him)
+
+
+http://www.cs.colostate.edu/~bieman/bmac/abstracts.html#Booch (this is the
+abstract of his talk in 2002 on software archaeology).
+
+Since I did not find any funding source, but he is a big shot ... you get the
+idea. I would have written him for info, but you are the lead developer and you
+were an IBMer.
+
+I'll write separately on Rubey's reported bug (but for now, the problem is not
+Bronstein's, in Axiom 2.3, each new()$Symbol generates a new variable name and
+Bronstein used dummy:=new()$Symbol to define the iterating variable in product
+and summation. The problem is from the upper limit of the summation being
+numerical rather than a symbol.)
+
+\start
+Date: Wed, 9 Jun 2004 10:04:28 +1000
+From: "Mike Thomas"
+To: "Page, Bill"
+Subject: [Axiom-developer] RE: [Gcl-devel] RE: Axiom on Windows
+Cc: Camm
+
+Hi Bill.
+
+| Your results are fantastic!!! You have every right to
+| be pleased.
+
+I still feel good a day later - I hadn't expected such good luck!
+
+Thanks to yourself, Tim, David, Camm and the other people who passed on
+congratulations. Apart from the advantage of having a working Windows GCL,
+most of the patches were based on your preexisting work, and of course
+without the long term patient help of Mr Maguire, I wouldn't have had the
+working GCL. So really, it was a team effort, as they say.
+
+
+| Yes, I can wait until GCL 2.6.2 is finished, but when
+| you have a moment I really would appreciate hearing
+| what you had to change. If I look at my old notes I may
+| be able to find some of the path changes that I had to
+| make in my last (failed) attempt.
+
+I'll compile a patch list for you later in the week - most of it is arrant
+hackery.
+
+One thing to note for the future portability of Axiom is that a few months
+ago it became apparent that on some (but not all) Windows 98 machines (not
+NT and friends) GCL will not work if built with the ONCRPC XDR extension, so
+for the time being I avoided XDR.
+
+| Great work!
+
+\start
+Date: Wed, 9 Jun 2004 10:14:36 +1000
+From: "Mike Thomas"
+To:
+Subject: [Axiom-developer] RE: [Gcl-devel] Re: Axiom on Windows
+
+| Fantastic.
+
+Thanks Tim.
+
+| The loading output messages can be turned off with
+| )set message autoload off
+
+Yes - worked perfectly.
+
+| Great stuff though. Very encouraging.
+| Thanks for the effort.
+
+You also - Your recent mention of 500 pages of documentation typing sounds
+pretty dedicated to me!
+
+\start
+Date: Wed, 9 Jun 2004 10:24:44 +1000
+From: "Mike Thomas"
+To: "David MENTRE"
+Subject: RE: [Axiom-developer] Axiom on Windows
+Cc: Camm Maguire , Bill Page
+
+Hi David.
+
+Sure do - in three parts due to the "make" restarts. I'll email separately
+to Bill and yourself shortly. Its 0.5 Mb as a tar.bz2.
+
+\start
+Date: Wed, 9 Jun 2004 15:37:29 +1000
+From: "Mike Thomas"
+To: "Page, Bill"
+Subject: [Axiom-developer] RE: [Gcl-devel] RE: Axiom on Windows
+Cc: Bill Page
+
+Hi Bill.
+
+As promised here is a CVS diff - I got stuck on a real life problem this
+afternoon and did this to procrastinate. The build logs have been sent
+separately to yourself and David M.
+
+1. The source tree was HEAD from a few days ago. It is critical that you
+use the compiler and binutils listed in point 10 below.
+
+2. Open an MSYS bash shell and cd to the top of the source.
+
+3. export AXIOM=/c/cvs/head/axiom/mnt/windows
+
+4. export PATH=$AXIOM/bin:$PATH
+
+5. Patch source tree as shown below - some of those patches circumvent the
+GCL source archive untar and patch steps.
+
+6. Insert a GCL Version_2_6_2c2 source tree into "lsp" and rename as
+"lsp/gcl-2.6.2a"
+
+7. Patch that new GCL source tree by hand in view of the deleted patch steps
+in "lsp/Makefile.pamphlet" mentioned in 5 above. Maybe this isn't
+necessary, I just assumed patch would not be smart enough to apply the
+patches in potentially altered files. I didn't bother with the compiler
+warning suppression patches to save time, as you can see from the logs I
+sent.
+
+8. Apply the "lsp/Makefile.pamphlet" patch for "h/linux.defs" to
+"h/mingw.defs".
+
+9. If memory serves I then let "make" have at it. It crashed a couple of
+times but I believe that this is a bug which has since been fixed - my MSYS
+is fairly old now; 1.09.
+
+10. It is critical that you use MinGW32 gcc 3.3.1 and binutils 2.14.90;
+otherwise GCL will not work properly.
+
+11. I haven't checked the C source hacks yet for stupid errors which might
+be contributing to the general wobbliness of the new Windows Axiom
+executable I have in front of me - we may be lucky. Normally the CLtl1 GCL
+build is fairly stable on Windows so I'm a bit surprised - even more so as I
+had previously thought that Axiom was using the ANSI build.
+
+I hope this is all I did; when I look back, it doesn't seem like much.
+
+Please ask if you have queries and good luck.
+
+Cheers
+
+Mike Thomas.
+
+? axiom_build_logs.tar.bz2
+? diff.txt
+? int
+? junk.txt
+? lastBuildDate
+? make.log
+? make.log.last
+? make1.log
+? make2.log
+? make3.log
+? Makefile.windows
+? make_clean.log
+? mnt
+? noweb
+? obj
+? rubbish.stex
+? test.lsp
+? update.log
+? wk
+? lsp/gcl-2.6.2a
+? lsp/gcldir
+? lsp/Makefile
+? lsp/Makefile.dvi
+? src/Makefile
+? src/Makefile.dvi
+? src/algebra/make.exe.stackdump
+? src/algebra/Makefile
+? src/algebra/Makefile.dvi
+? src/boot/Makefile
+? src/boot/Makefile.dvi
+? src/interp/Makefile
+? src/interp/Makefile.dvi
+? src/lib/Makefile
+? src/lib/Makefile.dvi
+? src/scripts/Makefile
+? src/scripts/Makefile.dvi
+? src/share/Makefile
+? src/share/Makefile.dvi
+? zips/gcl-2.6.2a.tgz-
+cvs diff: Diffing .
+Index: Makefile
+===================================================================
+RCS file: /cvsroot/axiom/axiom/Makefile,v
+retrieving revision 1.8
+diff -r1.8 Makefile
+1c1
+< SPD=$(shell pwd)
+---
+> SPD=$(shell pwd -W)
+17c17
+< ZIPS=${SPD}/zips
+---
+> ZIPS=${shell pwd}/zips
+59a60,62
+> cp ${ZIPS}/noweb.src.Makefile.patch . ; \
+> patch cd ${OBJ}/noweb/src ; \
+Index: Makefile.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/Makefile.pamphlet,v
+retrieving revision 1.20
+diff -r1.20 Makefile.pamphlet
+1305a1306,1354
+>
+> \subsection{Makefile.windows}
+> Annoyingly enough it seems that GCL uses a default extension of .lsp
+> rather than .lisp so we add the {\bf LISP} variable here. We need to
+> depend on the default extension behavior because the system build
+> will load either the interpreted or compiled form of a file depending
+> on which is available. This varies at different stages of the build.
+> <>> # System dependent Makefile for the Intel/Windows/MSYS platform
+> # Platform variable
+> PLF:=MSYSplatform
+> # C compiler flags
+> CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+> #CCF:=-g -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}
+> # Loader flags
+> LDF:= -L/usr/X11R6/lib
+> # C compiler to use
+> CC:=gcc
+> AWK=awk
+> RANLIB=ranlib
+> TOUCH=touch
+> TAR=tar
+> AXIOMXLROOT=${AXIOM}/compiler
+> O=o
+> BYE=bye
+> LISP=lsp
+> DAASE=${SRC}/share
+>
+> ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB}
+\
+> TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE}
+\
+> LISP=${LISP} DAASE=${DAASE}
+>
+> all: rootdirs noweb srcsetup lspdir srcdir
+> @echo 45 Makefile.windows called
+> @echo 46 Environment : ${ENV}
+> @echo 47 finished system build on `date` | tee >lastBuildDate
+>
+> <>
+> <>
+> <>
+> <>
+> <>
+> <>
+> <>
+> <>
+>
+> @
+>
+>
+cvs diff: Diffing license
+cvs diff: Diffing lsp
+Index: lsp/Makefile.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/lsp/Makefile.pamphlet,v
+retrieving revision 1.7
+diff -r1.7 Makefile.pamphlet
+39a40,42
+> @(cd ${GCLVERSION}/h ; \
+> echo 3a applying EXTRAS patch to h/mingw.defs ; \
+> patch <${SPD}/zips/${GCLVERSION}.h.mingw.defs.patch )
+62,63c65
+< echo 3 applying EXTRAS patch to h/linux.defs ; \
+< patch <${SPD}/zips/${GCLVERSION}.h.linux.defs.patch )
+---
+> echo 3 NOT applying EXTRAS patch to h/linux.defs )
+100,101c102
+< echo 6 applying libspad.a patch to unixport/makefile ; \
+< patch <${SPD}/zips/${GCLVERSION}.unixport.makefile.patch )
+---
+> echo 6 NOT applying libspad.a patch to unixport/makefile )
+126,127c127
+< echo 7 applying toploop patch to unixport/init_gcl.lsp ; \
+< patch <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.in.patch )
+---
+> echo 7 NOT applying toploop patch to unixport/init_gcl.lsp )
+207,208c207
+< echo 11 applying tail-recursive noise patch ; \
+< patch <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
+---
+> echo 11 NOT applying tail-recursive noise patch )
+210,211c209
+< echo 12 applying tail-recursive noise patch ; \
+< patch <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
+---
+> echo 12 NOT applying tail-recursive noise patch )
+266c264
+<
+
+./configure --enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=128
+*1024 ; \
+---
+>
+
+./configure --enable-debug --enable-vssize=65536*2 --enable-maxpage=128*102
+4; \
+297d294
+< @tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+351d347
+< @tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+453d448
+< @tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+cvs diff: Diffing lsp/ccl
+cvs diff: Diffing lsp/ccl/src
+cvs diff: Diffing lsp/ccl/src/axbase
+cvs diff: Diffing lsp/ccl/src/axbase/compiler
+cvs diff: Diffing lsp/ccl/src/axbase/compiler/lib
+cvs diff: Diffing lsp/ccl/src/boot
+cvs diff: Diffing lsp/ccl/src/caxbase
+cvs diff: Diffing lsp/ccl/src/cclbase
+cvs diff: Diffing lsp/ccl/src/cslbase
+cvs diff: Diffing lsp/ccl/src/scripts
+cvs diff: Diffing lsp/ccl/src/util
+cvs diff: Diffing src
+cvs diff: Diffing src/algebra
+cvs diff: Diffing src/booklets
+cvs diff: Diffing src/boot
+cvs diff: Diffing src/clef
+cvs diff: Diffing src/doc
+cvs diff: Diffing src/doc/msgs
+cvs diff: Diffing src/doc/ps
+cvs diff: Diffing src/etc
+cvs diff: Diffing src/include
+cvs diff: Diffing src/input
+cvs diff: Diffing src/interp
+Index: src/interp/patches.lisp.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/interp/patches.lisp.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 patches.lisp.pamphlet
+452a453,455
+> #+(not (and KCL :winnt))
+> (progn
+>
+497a501
+> )
+Index: src/interp/sockio.lisp.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/interp/sockio.lisp.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 sockio.lisp.pamphlet
+48a49,50
+> #+(not (and KCL :winnt))
+> (progn
+251c253
+<
+---
+> )
+cvs diff: Diffing src/lib
+Index: src/lib/XDither.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/XDither.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 XDither.c.pamphlet
+49a50
+> #ifndef _WIN32
+307a309
+> #endif /* _WIN32 */
+Index: src/lib/XShade.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/XShade.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 XShade.c.pamphlet
+49a50
+> #ifndef _WIN32
+285c286
+<
+---
+> #endif /* _WIN32 */
+Index: src/lib/XSpadFill.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/XSpadFill.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 XSpadFill.c.pamphlet
+64a65
+> #ifndef _WIN32
+376c377
+<
+---
+> #endif /* _WIN32 */
+Index: src/lib/bsdsignal.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/bsdsignal.c.pamphlet,v
+retrieving revision 1.5
+diff -r1.5 bsdsignal.c.pamphlet
+46a47,49
+> \section{Windows}
+> The signal function is not available under Windows.
+>
+66a70,72
+> #if defined ( _WIN32 )
+> return (SignalHandlerFunc) -1;
+> #else
+83a90
+> #endif /* _WIN32 */
+Index: src/lib/cfuns-c.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/cfuns-c.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 cfuns-c.c.pamphlet
+167a168
+> #ifndef _WIN32
+176a178
+> #endif /* _WIN32 */
+178a181
+> #ifndef _WIN32
+187a191
+> #endif /* _WIN32 */
+205a210
+> #ifndef _WIN32
+214a220
+> #endif /* _WIN32 */
+Index: src/lib/fnct_key.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/fnct_key.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 fnct_key.c.pamphlet
+46a47,48
+> \section{Windows}
+> These functions are not implemented in Windows.
+49a52
+> #ifndef _WIN32
+85a89
+> #endif /* _WIN32 */
+99a104
+> #ifndef _WIN32
+107a113
+> #endif /* _WIN32 */
+123a130
+> #ifndef _WIN32
+189a197
+> #endif /* _WIN32 */
+204a213
+> #ifndef _WIN32
+223a233
+> #endif /* _WIN32 */
+235a246,248
+> #ifdef _WIN32
+> return 0;
+> #else
+251a265
+> #endif /* _WIN32 */
+272a287
+> #ifndef _WIN32
+393a409
+> #endif /* _WIN32 */
+Index: src/lib/pixmap.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/pixmap.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 pixmap.c.pamphlet
+46a47,48
+> /section{Windows}
+> The function pixmap is not available under Windows/MSYS.
+49a52
+> #ifndef _WIN32
+377a381
+> #endif /* _WIN32 */
+Index: src/lib/sockio-c.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/sockio-c.c.pamphlet,v
+retrieving revision 1.4
+diff -r1.4 sockio-c.c.pamphlet
+51c51
+<
+---
+> #ifndef _WIN32
+1434a1435
+> #endif /* _WIN32 */
+Index: src/lib/spadcolors.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/spadcolors.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 spadcolors.c.pamphlet
+49c49
+<
+---
+> #ifndef _WIN32
+599a600
+> #endif /* _WIN32 */
+Index: src/lib/util.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/util.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 util.c.pamphlet
+49a50
+> #ifndef _WIN32
+207a209
+> #endif /* _WIN32 */
+Index: src/lib/wct.c.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/lib/wct.c.pamphlet,v
+retrieving revision 1.3
+diff -r1.3 wct.c.pamphlet
+57a58
+> #ifndef _WIN32
+870a872
+> #endif /* _WIN32 */
+cvs diff: Diffing src/scripts
+cvs diff: Diffing src/scripts/tex
+cvs diff: Diffing src/share
+cvs diff: Diffing src/share/algebra
+cvs diff: Diffing src/share/algebra/DEPENDENTS.DAASE
+cvs diff: Diffing src/share/algebra/USERS.DAASE
+cvs diff: Diffing src/share/doc
+cvs diff: Diffing src/share/doc/hypertex
+cvs diff: Diffing src/share/doc/hypertex/pages
+cvs diff: Diffing src/share/doc/msgs
+cvs diff: Diffing zips
+cvs diff: cannot find zips/gcl-2.6.2a.tgz
+
+\start
+Date: Wed, 09 Jun 2004 02:49:21 -0400
+From: William Sit
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] RE: learning in public
+Cc: "Page, Bill"
+
+Hi Bertfried:
+
+You may already be aware of this, but that is not obvious from your discussions.
+So, just in case.
+
+Regarding Clifford Algebra etc, Axiom already has some built in packages (unless
+otherwise indicated, all done by Stephen Watt before 1991).
+
+QFORM QuadraticForm in clifford.spad
+CLIF Clifford Algebra in clifford.spad
+ (over any field K and quadratic form on K^n)
+GRMOD Graded Module in carten.spad
+GRALG Graded Algebra in carten.spad
+CARTEN CartesianTensor in carten.spad (tensor algebra)
+CARTEN2 CartesianTensorFunction2 in carten.spad
+SYMFUNC SymmetricFunctions in efstruc.spad (by Manuel Bronstein)
+PRTITION Partition in prtition.spd (by William Burge)
+SYMPOLY SymmetryPolynomial in prtition.spad (by Wiliam Burge)
+BMODULE BiModule in catdef.spad (probably by Watt also)
+
+Granted, this may not be enough for your purpose, but surely they point to the
+way this WAS done and may make additional structures easier to build.
+
+
+It is also possible that other people may have unpublished implementation of
+structures like Hopf algebra, Shuffle Algebra, Grassmann Algebra or Spin Algebra
+already (perhaps Larry Lambe or Michel Petitot? I am fairly sure Petitot has
+implemented Shuffle Algebra, which is close to Hopf algebra).
+
+> Formal definition
+>
+> ... bla bla ...
+>
+> such that the following diagram commutes:
+>
+> V ----> C(q)
+> | /
+> | / Exists and is unique
+> | /
+> v v
+> A
+>
+>
+>> Indeed, this construction is categorial, but not algorithmic. Hence almost
+>> useless for computer algebra.
+
+On the contrary, such universal objects are the key to construction of free
+objects and morphisms in the category (examples are vector spaces where you can
+define morphisms by specifying only values on a basis; but also works for higher
+algebras such as free shuffle algebra) and the non-free ones are done by forming
+quotients.
+
+> Look at the (anti)commutation of two grade one elements, its symmetric by
+> construction, so
+>
+> a (x) b + b (x) a = 2g(a,b)
+>
+> has to have a symmetric bilinear form. To generalize this, you need an
+> _order relation_ on the grade one elements, to decide if you expand for
+> a (x) b (or for b (x) a), say we take lexicographic order and lets assume
+> e_i < e_j if i the effects with the linear ordering of teh bases (grade one space), this
+> is quite a peculiar and problemetic thing to do!
+
+CliffordAlgebra(n,K,Q) in Axiom is a domain constructor, where n is dimension of
+V= K^n, K a field, and Q a quadratic form on V, is defined using the canonical
+basis e(i), i=1..n on V (but it should be easy to modify the source to let this
+basis be a parameter linked to Q) with identities: e(i)*e(j) = - e(j)*e(i) and
+e(i)*e(i) = Q(e(i)). This gives rise to a corresponding canonical basis for the
+Clifford Algebra, which has dimension 2^n (all products formed from any subset
+of the vector space basis).
+
+To have different order relation or grading (filtration), it would be best to
+modify the source to allow an additional parameter or two. For example, in
+polynomial algebra, different term ordering can be done in GDMP (Generalized
+Distributed Multivariate Polynomial), which is a domain constructor by modifying
+DMP or HDMP. A CliffordAlgebra CATEGORY is needed if the REPRESENTATION of the
+SAME (mathematically) algebra changes (or when the code for the basic operations
+will be changed; for example if there are more efficient algortihms when the
+points are ordered). For polynomial algebra, a category is created so that
+different representations (DMP, POLY, SMP) can be used.
+
+> My Problem:
+
+> Still I am not able to envision a data structure complex enough to hold
+> the problem and simple enough not to make everything totally unmanagable.
+> A good start would be to write an AXIOM package for supersymmetric
+> bi-commutative Hopf algebras, if thats done, cliffordization is relatively
+> easy to implement.
+
+I suggest starting with generalizing the present CliffordAlgebra to include in
+order:
+(1) arbitrary symmetric bilinear form (may need SymmetricAlgebra, but may be not
+by using SYMPOLY)
+(2) grading (and/or order) (using GRALG and GRMOD)
+(3) bimodule structure using BIMODULE
+
+Then when needed, create Hopf Algebra based on this experience.
+
+BTW, I am also "learning in public" (but not as diligent as Tim).
+
+\start
+Date: Wed, 9 Jun 2004 09:59:55 +0200 (CEST)
+From: "m.rubey"
+To: William Sit
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+Concerning Software Archaeology, I agree. However, much of the code --
+especially COMBF -- is very easy to understand. Therefore I suppose the
+best thing is to write documentation, both on new and old code, as bugs
+are discovered and fixed. In this spirit I volunteer to document those
+functions in COMBF and FS that I understand now. Before I do so, I only
+ask for a "go ahead" by some key developer, because I don't want to waste
+my time.
+
+Unfortunately, I also have to say that I'm a little bit disappointed: I
+submitted a patch which fixes a problem that turned up in Wester's
+test-suite -- no reaction. I posted some questions -- no reaction. A
+simple (private) "sorry, I don't know - interesting question" or "sorry, I
+don't know, - but it's a stupid question anyway" would help a lot. At the
+moment, there aren't that many developers around so that it would result
+in flooding my email account.
+
+On the other hand, I'm very happy that I received this email now...
+
+> I'll write separately on Rubey's reported bug (but for now, the problem
+> is not Bronstein's, in Axiom 2.3, each new()$Symbol generates a new
+> variable name and Bronstein used dummy:=new()$Symbol to define the
+> iterating variable in product and summation. The problem is from the
+> upper limit of the summation being numerical rather than a symbol.)
+
+I believe this is not quite correct: His line 145 of
+combfunc.spad.pamphlet reads
+
+ dummy := new()$SE :: F
+
+Therefore (I believe), when COMBF is first read, "dummy" is assigned
+("immediately") a new symbol, once and for all. Thus, everywhere where
+"dummy" is used, the *same* symbol is inserted. In particular, all sums
+and all products use the same iteration variable. Clearly, when sums and
+products are nested and evaluation takes place, problems occur.
+
+Meanwhile I tested my patch and it works quite well, so I'll submit it
+now. As I said, the only problem remains when you use the symbol
+which will be generated next somewhere in the sum (or product). I don't
+know how to fix this, but this is a problem which should be fixed in
+new()$Symbol. By the way, there are references to this problem in
+fspace.spad...
+
+The reason I did not submit the patch earlier was, that I just changed
+job, so I had no time to test it. I don't want to submit untested patches.
+
+The problem in dvdsum is unrelated, easier to understand but more
+difficult to fix, as I wrote in my bug report
+
+http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9216
+
+The problem is that I don't know how to return
+
+D(sum(f(i),i=1..x),x)
+
+unevaluated. Some trials resulted in ugly and partially wrong results, see
+reports
+
+http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9215
+
+and
+
+http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9218
+
+Therefore, no patch.
+
+I'll write about the other things a little later
+
+\start
+Date: Wed, 9 Jun 2004 18:08:36 +1000
+From: "Mike Thomas"
+To: "Camm Maguire"
+Subject: [Axiom-developer] RE: [Gcl-devel] Re: Axiom on Windows
+Cc: Bill Page
+
+Hi Camm/Tim.
+
+| It looks like the 'nil' you find below is either that supplied as an
+| argument above or results from the missing environment. In any case,
+| should this persist, it would be helpful (for someone, not you
+| hopefully, you overworked soul!) to repeat the below with
+| (si::use-fast-links nil)
+
+I should have thought to try that sorry (gdb further down):
+
+Here is a Windows command prompt session in which I switch off
+C:\Documents and Settings\miketh>set AXIOM=c:\cvs\head\axiom\mnt\windows
+
+C:\Documents and Settings\miketh>path
+c:\cvs\head\axiom\mnt\windows\bin;%path%
+
+C:\Documents and Settings\miketh>AXIOMsys.exe
+GCL (GNU Common Lisp) 2.6.2 CLtL1 Jun 8 2004 13:12:41
+Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
+Binary License: GPL due to GPL'ed components: (UNEXEC)
+Modifications of this banner must retain notice of a compatible license
+Dedicated to the memory of W. Schelter
+
+Use (help) to get some basic information on how to use GCL.
+ AXIOM Computer Algebra System
+ Version of Tuesday June 8, 2004 at 13:25:54
+----------------------------------------------------------------------------
+-
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+----------------------------------------------------------------------------
+-
+
+(1) -> )lisp (si::use-fast-links nil)
+
+Value = NIL
+(1) -> )lisp (make-databases "" nil)
+
+Error: Caught fatal error [memory may be damaged]
+Error signalled by |SATURNSAYERRORLY|.
+Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
+BOOT>>:bt
+
+#0 APPLY {loc0=#,loc1=:error,loc2=nil,l...} [ihs=32]
+#1 APPLY {loc0=#,loc1=:error,loc2=nil,l...} [ihs=31]
+#2 LAMBDA {} [ihs=28]
+#3 pushSatOutput
+{loc0=|line|,loc1=#,loc2=#,loc3=#,loc4=#
+,loc...} [ihs=27]
+#4 saturnSayErrorly {errorlabel="System error",msg=(" " "Can't change
+the current directory to \"N...} [ihs=26]
+#5 sayErrorly {errorlabel="System error",msg=(" " "Can't change the
+current directory to \"N...} [ihs=25]
+#6 errorSupervisor1 {loc0=|SystemError|,loc1="Can't change the current
+directory to \"NIL\".",loc2=|...} [ihs=24]
+#7 errorSupervisor {loc0=|SystemError|,loc1="Can't change the current
+directory to \"NIL\"."} [ihs=23]
+#8 systemError {g160176="Can't change the current directory to \"NIL\"."}
+[ihs=22]
+#9 LAMBDA {"NIL"=nil,} [ihs=15]
+#10 CHDIR
+{loc0="NIL",loc1=:error,loc2=nil,loc3=localdatabase,loc4="",loc5="Can't
+change t...} [ihs=14]
+#11 LOCALDATABASE {filelist=nil,options=((|dir|
+"NIL")),make-database?=make-database,loc3="NIL",fi...} [ihs=13]
+#12 MAKE-DATABASES {ext="",g170243=nil,g170208=""} [ihs=12]
+#13 nplisp {loc0=nil,loc1=nil,loc2=nil,loc3=#} [ihs=11]
+#14 handleNoParseCommands {unab=|lisp|,string="lisp (make-databases \"\"
+nil)",loc2=(|lisp| |pquit| |quit|...} [ihs=10
+]
+#15 doSystemCommand {string="lisp (make-databases \"\" nil)",line="lisp
+(make-databases \"\" nil)"} [ihs=9]
+#16 ExecuteInterpSystemCommand {string=")lisp (make-databases \"\"
+nil)",loc1=0} [ihs=8]
+#17 ncloopCommand {line=")lisp (make-databases \"\"
+nil)",n=1,loc2=1,loc3=(")lisp (si::use-fast-li...} [ihs=7]
+#18 RESTART {} [ihs=6]
+#19 TOP-LEVEL
+{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="c:/cvs/hea
+d/ax...} [ihs=5]
+#20 FUNCALL {loc0=#} [ihs=4]
+NIL
+BOOT>>
+
+================================================================================
+So you are right - it is the niul passed in as an argument being treated as
+a string?
+
+And with gdb:
+
+
+================================================================================
+$ gdb ./mnt/windows/bin/AXIOMsys.exe
+GNU gdb 6.0
+Copyright 2003 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain
+conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB. Type "show warranty" for details.
+This GDB was configured as "i686-pc-mingw32"...
+(gdb) r
+Starting program: c:\cvs\head\axiom/./mnt/windows/bin/AXIOMsys.exe
+GCL (GNU Common Lisp) 2.6.2 CLtL1 Jun 8 2004 13:12:41
+Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
+Binary License: GPL due to GPL'ed components: (UNEXEC)
+Modifications of this banner must retain notice of a compatible license
+Dedicated to the memory of W. Schelter
+
+Use (help) to get some basic information on how to use GCL.
+ AXIOM Computer Algebra System
+ Version of Tuesday June 8, 2004 at 13:25:54
+----------------------------------------------------------------------------
+-
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+----------------------------------------------------------------------------
+-
+
+(1) -> )lisp (make-databases "" nil)
+
+Program received signal SIGSEGV, Segmentation fault.
+0x0045e2ad in equal (x=0x0, y=0x103d945c) at predicate.c:496
+496 if ((t = type_of(x)) != type_of(y))
+(gdb) bt
+#0 0x0045e2ad in equal (x=0x0, y=0x103d945c) at predicate.c:496
+#1 0x104fdbed in ?? ()
+(gdb)
+===============================================================================
+Late for the train as usual.
+
+\start
+Date: Wed, 9 Jun 2004 07:41:24 -0400
+From: root
+To: rubey@geometrie.tuwien.ac.at
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+Martin,
+
+>Concerning Software Archaeology, I agree. However, much of the code --
+>especially COMBF -- is very easy to understand. Therefore I suppose the
+>best thing is to write documentation, both on new and old code, as bugs
+>are discovered and fixed. In this spirit I volunteer to document those
+>functions in COMBF and FS that I understand now. Before I do so, I only
+>ask for a "go ahead" by some key developer, because I don't want to waste
+>my time.
+
+You have my permission (though you don't need it) to document parts
+of the system you understand. See src/interp/setvart and
+src/interp/setvars for examples.
+
+>Unfortunately, I also have to say that I'm a little bit disappointed: I
+>submitted a patch which fixes a problem that turned up in Wester's
+>test-suite -- no reaction. I posted some questions -- no reaction. A
+>simple (private) "sorry, I don't know - interesting question" or "sorry, I
+>don't know, - but it's a stupid question anyway" would help a lot. At the
+>moment, there aren't that many developers around so that it would result
+>in flooding my email account.
+
+Your email hasn't been ignored. It's just queued behind others.
+I know it feels like it's being ignored, a feeling email tends to
+generate. The best path is to file a bug report on the axiom website.
+That makes a permanent record. It may already be there as David Mentre
+manages that.
+
+As to the actual state of your questions... I looked at the code
+initially when you sent the problem but didn't understand it well
+enough to comment. Then when your patch arrived it got queued in
+the list of patches to apply. I'm currently working on replying/fixing
+a very large system hole. There was a mail question about
+numericalIntegration and I'm working to fix that problem (the fix
+essentially involves building a replacement for the missing NAG libs
+which has morphed into deeper changes).
+
+For domain questions like this one of three events occur. Either
+someone has an answer directly and replies, you find a fix and
+send it to me and it (eventually) gets applied, or I study the
+problem and generate a fix. The last case takes a lot of time since
+Axiom knows a lot more math than I do (witness the last few emails
+about Clifford Algebras which I can barely read). Documentation is
+sorely needed. I try to document everything I touch (yet another
+source of time lag).
+
+I apologize for not at least sending you an acknowledgement that
+I recieved your mail. I assure you that I read everything that goes by
+and track it as best I can.
+
+\start
+Date: Wed, 9 Jun 2004 13:07:58 +0200 (CEST)
+From: "m.rubey"
+To: root
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+Thanks a lot for this mail. Docs will follow end of this week. (i.e., I
+will replace my patches with patches to the pamphlet files.)
+
+Martin
+
+On Wed, 9 Jun 2004, root wrote:
+
+> Martin,
+>
+> >Concerning Software Archaeology, I agree. However, much of the code --
+> >especially COMBF -- is very easy to understand. Therefore I suppose the
+> >best thing is to write documentation, both on new and old code, as bugs
+> >are discovered and fixed. In this spirit I volunteer to document those
+> >functions in COMBF and FS that I understand now. Before I do so, I only
+> >ask for a "go ahead" by some key developer, because I don't want to waste
+> >my time.
+>
+> You have my permission (though you don't need it) to document parts
+> of the system you understand. See src/interp/setvart and
+> src/interp/setvars for examples.
+>
+> >Unfortunately, I also have to say that I'm a little bit disappointed: I
+> >submitted a patch which fixes a problem that turned up in Wester's
+> >test-suite -- no reaction. I posted some questions -- no reaction. A
+> >simple (private) "sorry, I don't know - interesting question" or "sorry, I
+> >don't know, - but it's a stupid question anyway" would help a lot. At the
+> >moment, there aren't that many developers around so that it would result
+> >in flooding my email account.
+>
+> Your email hasn't been ignored. It's just queued behind others.
+> I know it feels like it's being ignored, a feeling email tends to
+> generate. The best path is to file a bug report on the axiom website.
+> That makes a permanent record. It may already be there as David Mentre
+> manages that.
+>
+> As to the actual state of your questions... I looked at the code
+> initially when you sent the problem but didn't understand it well
+> enough to comment. Then when your patch arrived it got queued in
+> the list of patches to apply. I'm currently working on replying/fixing
+> a very large system hole. There was a mail question about
+> numericalIntegration and I'm working to fix that problem (the fix
+> essentially involves building a replacement for the missing NAG libs
+> which has morphed into deeper changes).
+>
+> For domain questions like this one of three events occur. Either
+> someone has an answer directly and replies, you find a fix and
+> send it to me and it (eventually) gets applied, or I study the
+> problem and generate a fix. The last case takes a lot of time since
+> Axiom knows a lot more math than I do (witness the last few emails
+> about Clifford Algebras which I can barely read). Documentation is
+> sorely needed. I try to document everything I touch (yet another
+> source of time lag).
+>
+> I apologize for not at least sending you an acknowledgement that
+> I recieved your mail. I assure you that I read everything that goes by
+> and track it as best I can.
+
+\start
+Date: Wed, 9 Jun 2004 08:19:24 -0400
+From: root
+To: rubey@geometrie.tuwien.ac.at
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+Martin,
+
+Excellent. I'll prioritize your changes so they get done in THIS lifetime :-)
+While I'm begging could I ask you to create/modify/document an input file
+that tests the domains a bit better? -- t
+
+\start
+Date: Wed, 9 Jun 2004 15:39:02 +0400
+From: "Serge D. Mechveliani"
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] output format
+
+Dear Axiom supporters,
+
+Thank you,
+I have installed Axiom from CVS on our RedHat Linux 9 machine.
+This makes it
+ Axiom Version of June 9, 2004.
+
+I find Axiom useful because it has a rich mathematical library.
+
+So far, I have a small question of how to print a polynomial,
+polynomial factorization "to line".
+
+The program a.input is of kind
+
+ P := MPOLY([p,e,s], Integer)
+ ...
+ ft = factor f
+ )spool axres
+ output ft;
+ )spool off
+
+
+The commands > axiom
+ ...
+ (1) -> )r a.input
+yield
+ ---------------------------------------------------------------
+ -
+ (s - 1)(s + 1)
+ *
+ 4 3 2 3
+ p + (2e + (24s - 4)e)p
+ +
+ 6 2 4
+ (e + (60s - 6)e + ... )
+ +
+ ...
+ *
+ p
+ +
+ 8 2 6 4 2 4
+ e + (112s - 2)e + (1120s - 120s + 1)e
+ ....
+
+ )spool off
+
+
+ >> System error:
+ Already in dribble (to axres).
+ ------------------------------------------------------------
+
+
+1. What may be this `error'?
+
+2. I would also like to have the output of kind
+
+ " - (s-1) * (s+1) * (p^4 +(2*e^3 + (24*s^2 - 4)*e)*p^3 * ...) * ...
+ "
+
+For example, my DoCon program can read this format ...
+
+2.1 It prints these polynomials like for (Z[e])[p]:
+ " (e^2 + 2e)*p "
+ How to print it like for Z[p,e]:
+ " 2*p*e + e^2 "
+ ?
+
+\start
+Date: Wed, 9 Jun 2004 13:46:06 +0200 (CEST)
+From: "m.rubey"
+To: root
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+On Wed, 9 Jun 2004, root wrote:
+
+> Martin,
+>
+> Excellent. I'll prioritize your changes so they get done in THIS lifetime :-)
+
+Thanks a lot.
+
+> While I'm begging could I ask you to create/modify/document an input file
+> that tests the domains a bit better? -- t
+
+I'm not quite sure what you're asking for... What I had in mind is that I
+document those functions in COMBF, FS, ... that I understand (via your
+pamphlet mechanism).
+
+I also thought about writing a file that produces the bug/error with the
+unpatched version, and runs nicely :-) with the patched version.
+
+Please expand.
+
+\start
+Date: Wed, 9 Jun 2004 08:39:25 -0400
+From: root
+To: rubey@geometrie.tuwien.ac.at
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+in src/input are a set of pamphlet files which contain test cases for
+algebra code. these are run at system build time (and eventually will
+have a regression-test mechanism built around them). if you can, i'd
+like you to write whatever algebra you have into either an existing
+pamphlet file or a new one so we can test the system better. --t
+
+\start
+Date: Wed, 9 Jun 2004 08:44:41 -0400
+From: root
+To: mechvel@botik.ru
+Subject: Re: [Axiom-developer] output format
+
+Serge,
+
+>So far, I have a small question of how to print a polynomial,
+>polynomial factorization "to line".
+>
+>The program a.input is of kind
+>
+> P := MPOLY([p,e,s], Integer)
+> ...
+> ft = factor f
+> )spool axres
+> output ft;
+> )spool off
+>
+>
+>The commands > axiom
+> ...
+> (1) -> )r a.input
+>yield
+
+.....[snip].....
+
+>
+> )spool off
+>
+>
+> >> System error:
+> Already in dribble (to axres).
+
+This error message is coming from the underlying lisp image (in
+lsp/gcl-2.6.2a/lsp/gcl_iolib.lsp), not from Axiom. I don't understand
+yet why it occurs but I'll look into it.
+
+
+> ------------------------------------------------------------
+>
+>
+>1. What may be this `error'?
+>
+>2. I would also like to have the output of kind
+>
+> " - (s-1) * (s+1) * (p^4 +(2*e^3 + (24*s^2 - 4)*e)*p^3 * ...) * ...
+> "
+>
+
+Axiom does not, as far as I know, have a "linear" output representation.
+
+\start
+Date: Wed, 9 Jun 2004 08:58:06 -0400
+From: root
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] status
+
+*,
+
+Martin has highlighted a major failing on my part, that is, communications.
+I'll try to collect and make available the "state of the state", what is
+being worked on, what is queued, etc so there is some transparency on
+the effort. --t
+
+\start
+Date: Wed, 09 Jun 2004 14:30:08 +0200
+From: Daniel Augot
+To: "Serge D. Mechveliani"
+Subject: Re: [Axiom-developer] output format
+
+Serge D. Mechveliani wrote:
+
+> Dear Axiom supporters,
+> 2. I would also like to have the output of kind
+>
+> " - (s-1) * (s+1) * (p^4 +(2*e^3 + (24*s^2 - 4)*e)*p^3 * ...) * ...
+> "
+>
+> For example, my DoCon program can read this format ...
+>
+> 2.1 It prints these polynomials like for (Z[e])[p]:
+> " (e^2 + 2e)*p "
+> How to print it like for Z[p,e]:
+> " 2*p*e + e^2 "
+> ?
+>
+> Thank you in advance for the help,
+>
+> -----------------
+> Serge Mechveliani
+> mechvel@botik.ru
+
+Dear Serge,
+
+You may wish to use the InputForm domain, where you can find some
+bizarre functions. In your case, "unparse" may help you, as follows.
+
+Best regards,
+
+Daniel
+
+~ $ axiom
+ AXIOM Computer Algebra System
+ Version of Tuesday May 25, 2004 at 17:08:19
+-----------------------------------------------------------------------------
+ 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) -> p:=(a+b+y)^2*y+1-(x+y+z)^4
+ Loading /local/augot/axiom/mnt/linux/algebra/UPMP.o for package
+ UnivariatePolynomialMultiplicationPackage
+
+ (1)
+ 4 3 2 2 2
+ - z + (- 4y - 4x)z + (- 6y - 12x y - 6x )z
+ +
+ 3 2 2 3 4 3 2 2
+ (- 4y - 12x y - 12x y - 4x )z - y + (- 4x + 1)y + (- 6x + 2b + 2a)y
+ +
+ 3 2 2 4
+ (- 4x + b + 2a b + a )y - x + 1
+ Type: Polynomial Integer
+(2) -> pi:=p::InputForm
+ Loading /local/augot/axiom/mnt/linux/algebra/INFORM.o for domain
+ InputForm
+ Loading /local/augot/axiom/mnt/linux/algebra/SEX.o for domain
+ SExpression
+ Loading /local/augot/axiom/mnt/linux/algebra/POLYLIFT.o for package
+ PolynomialCategoryLifting
+ Loading /local/augot/axiom/mnt/linux/algebra/DFLOAT.o for domain
+ DoubleFloat
+ Loading /local/augot/axiom/mnt/linux/algebra/SEXOF.o for domain
+ SExpressionOf
+
+ (2)
+ (+
+
+ (+
+
+ (+ (+ (* - 1 (** z 4)) (* (+ (* - 4 y) (* - 4 x)) (** z 3)))
+ (* (+ (+ (* - 6 (** y 2)) (* (* - 12 x) y)) (* - 6 (** x 2))) (** z 2)))
+
+
+ (*
+
+ (+
+
+ (+ (+ (* - 4 (** y 3)) (* (* - 12 x) (** y 2)))
+ (* (* - 12 (** x 2)) y))
+
+ (* - 4 (** x 3)))
+
+ z)
+ )
+
+
+ (+
+
+ (+
+
+ (+ (+ (* - 1 (** y 4)) (* (+ (* - 4 x) 1) (** y 3)))
+ (* (+ (* - 6 (** x 2)) (+ (* 2 b) (* 2 a))) (** y 2)))
+
+ (* (+ (* - 4 (** x 3)) (+ (+ (** b 2) (* (* 2 a) b)) (** a 2))) y))
+
+ (+ (* - 1 (** x 4)) 1))
+ )
+ Type: InputForm
+(3) -> unparse(pi)
+ Loading /local/augot/axiom/mnt/linux/algebra/FST.o for domain
+ FortranScalarType
+ Loading /local/augot/axiom/mnt/linux/algebra/FT.o for domain
+ FortranType
+ Loading /local/augot/axiom/mnt/linux/algebra/SYMS.o for domain
+ TheSymbolTable
+ Loading /local/augot/axiom/mnt/linux/algebra/SYMTAB.o for domain
+ SymbolTable
+ Loading /local/augot/axiom/mnt/linux/algebra/TABLE.o for domain
+ Table
+ Loading /local/augot/axiom/mnt/linux/algebra/HASHTBL.o for domain
+ HashTable
+ Loading /local/augot/axiom/mnt/linux/algebra/INTABL.o for domain
+ InnerTable
+ Loading /local/augot/axiom/mnt/linux/algebra/KDAGG-.o for domain
+ KeyedDictionary&
+ Loading /local/augot/axiom/mnt/linux/algebra/VOID.o for domain Void
+
+ (3)
+ "(-z**4)+((-4*y)+(-4*x))*z**3+((-6*y*y)+(-12*x*y)+(-6*x*x))*z*z+((-4*y**3)+(-
+ 12*x*y*y)+(-12*x*x*y)+(-4*x**3))*z+(-y**4)+((-4*x)+1)*y**3+((-6*x*x)+2*b+2*a)
+ *y*y+((-4*x**3)+b*b+2*a*b+a*a)*y+(-x**4)+1"
+ Type: String
+
+(4) -> )sh InputForm
+ InputForm is a domain constructor
+ Abbreviation for InputForm is INFORM
+ This constructor is not exposed in this frame.
+ Issue )edit /local/augot/axiom/mnt/linux/../../src/algebra/INFORM.spad to see algebra source code for INFORM
+
+------------------------------- Operations --------------------------------
+ #? : % -> Integer ?*? : (%,%) -> %
+ ?**? : (%,Integer) -> % ?+? : (%,%) -> %
+ ?/? : (%,%) -> % ?=? : (%,%) -> Boolean
+ 1 : () -> % 0 : () -> %
+ atom? : % -> Boolean binary : (%,List %) -> %
+ car : % -> % cdr : % -> %
+ coerce : % -> OutputForm convert : SExpression -> %
+ convert : % -> SExpression convert : OutputForm -> %
+ convert : DoubleFloat -> % convert : Integer -> %
+ convert : Symbol -> % convert : String -> %
+ convert : List % -> % declare : List % -> Symbol
+ destruct : % -> List % ?.? : (%,List Integer) -> %
+ ?.? : (%,Integer) -> % eq : (%,%) -> Boolean
+ expr : % -> OutputForm flatten : % -> %
+ float : % -> DoubleFloat float? : % -> Boolean
+ hash : % -> SingleInteger integer : % -> Integer
+ integer? : % -> Boolean interpret : % -> Any
+ lambda : (%,List Symbol) -> % latex : % -> String
+ list? : % -> Boolean null? : % -> Boolean
+ pair? : % -> Boolean string : % -> String
+ string? : % -> Boolean symbol : % -> Symbol
+ symbol? : % -> Boolean unparse : % -> String
+ ?~=? : (%,%) -> Boolean
+ ?**? : (%,NonNegativeInteger) -> %
+ compile : (Symbol,List %) -> Symbol
+ function : (%,List Symbol,Symbol) -> %
+
+
+\start
+Date: Wed, 09 Jun 2004 08:56:31 -0400
+From: William Sit
+To: "m.rubey"
+Subject: [Axiom-developer] Patches
+Cc: "Bronstein, Manuel"
+
+Hi Martin:
+
+Thanks for your reply. I am sorry that I reply to your post so late (actually, I
+have not caught up with these posts and I only read them once in a while). 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
+
+Note this was because before I clear all, I had defined %B and did a
+New()$SYMBOL that gives %C.
+
+(3) -> G1419::SYMBOL
+ G1419
+
+(4) -> symbol(GENSYM()$Lisp)
+ G84337
+
+All output are of type Symbol.
+
+I also got the product summation display correctly without error message, unless
+the upper limit is a constant. Thus I think Bronstein's use of new()$Symbol is
+correct, but somewhere in the open source version, new()$Symbol get clobbered.
+Of course, you can patch Bronstein's code to force a new symbol each time, but
+other packages that use new()$Symbol will still fail, as you recognized. I
+believe the source of the error is more subtle and probably does not come from
+new()$Symbol either.
+
+Another reason why I think the error does not come from the source code is
+because any iteration in Axiom, the iterating variable is a dummy (and
+supposedly unique and local in scope). (Can Tim affirm this?)
+
+Bug Report #9216:
+
+Regarding dvdsum, I find it hard to follow Bronstein's code
+(CombinatorialFunction constructor in combfunc.spad), because I need to trace
+all the packages to figure out what opdsum does (it seems to be a hold to do
+recursion, but I am not sure and opdsum is not an exported function, neither is
+dvdsum). Assuming it is just a summation, mathematically speaking, then my guess
+is dvdsum does the following: it takes two arguments, a list with five
+parameters, and a symbol. Using Bronstein notation in the code (without regard
+to type, just mathematical and forget all the coercions), the first is
+[f,k,y,g,h], all belonging to some function space F, such as Expression Integer
+and the second is x. Here
+
+f is the function to be summed with dummy variable k,
+k is the dummy (for summation),
+y is some symbol
+g is the lower limit of summation, presumably a function of x
+h is the upper limit of summation, presumably a function of x
+x is the symbol with respect to which differentiation is to be done
+
+
+What the code dvdsum does, assuming odpsum is just summation, is to return the
+following: d/dx means differentiation wrt x (not the d in the code)
+
+0 if the variable y retracts to x, otherwise the formula:
+
+d(h)/dx f(h) - d(g)/dx f(g) + summation(d(f)/dx, k = g..h)
+
+
+I have no clue what this formula means, for example, what is the role of y?
+however, I hesitate to say it is wrong because Bronstein is quite careful, both
+as a mathematician and a wizard in Axiom and Aldor. dvdsum occurs only three
+times in the source, once in the signature, once in the definition, and once in
+an obscure setProperty statement related to opdsum. It is not exported and
+therefore not usable by any other package. But it is possibly used via opdsum
+which is defined as operator("%defsum"), an operator with 5 parameters defined
+in CommonFunctions package. I do not understand the design of that package.
+(Manuel, please help!)
+
+I don't know what dvdsum is supposed to return (so I can't say it is correct or
+not), but you interpret it as differentiating the sum with respect to x (as is
+clear from your bug reports). So I did the following experiment: I input the
+following code, which is a "standalone" version of dvdsum that can be read into
+the interpreter (assuming, opdsum is simply summation):
+
+
+EI==>Expression Integer
+dvdsum(l:List EI, x:Symbol):EI= x = retract(y:= third l)@Symbol => 0
+ k := retract(d:=second l)@(Kernel EI)
+ differentiate(h:=third rest rest l,x)*eval(f:=first l, k, h)
+ - differentiate(g:=third rest l, x)*eval(f,k,g)
+ + sum(differentiate(f,x),d::Symbol=g..h)
+
+Now try
+
+dvdsum([i^2, i, y, x^2, x^3],x)
+
+ 8 5
+ 3x - 2x
+
+but
+
+D(sum(i^2, i=x^2..x^3),x)
+
+ 8 5 3 2
+ (18x + 6x + 12x + 3x - 2x)
+ ------------------------------
+ 6
+
+which is correct (this can be done because we know how to sum i^2). So it seems
+the story is more complicated.
+
+In any case, to differentiate a symbolic summation, where the
+independent variable x can appear ANYWHERE (in f, in g, or in h), is hopeless.
+We cannot expect answers in all cases. We know it is not always possible to have
+close form summation, let alone differentiating them. Things like the above can
+work, but
+
+D(sum(1/i, i=1..x),x)
+
+would be impossible to differentiate without a closed form formula. Even when a
+term by term differentiation makes sense,
+
+ D(sum(1/i, i=x^2..x^3))
+
+Axiom gives the wrong answer 1/x. Unfortunately, it agrees with
+
+ dvdsum([1/i,i,y,x^2,x^3],x)
+
+So it seems under some circumstances (so far the no answer cases), dvdsum is
+called to differentiate a sum and that's when it gives wrong answers.
+
+----------------
+Bug Report #9215:
+
+ sum(box(i),i=a..b)
+
+returns the answer correctly, but the outputForm missed a pair of parenthesis
+aa-1 should be a(a-1);
+
+ box(sum(i),i=1..n)
+
+also returns correctly, because after sum is evaluated to (n^2+n)/2, an
+(invisible) box is placed around it. Note the box is useful ONLY when there is
+an operator operating on the box content. The only way this is easy to use is
+when the operator takes one argument, such as sin, cos, log. The argument can be
+a list of course.
+
+---------------
+Bug Report 9218:
+
+I believe the CombinatorialFunctions package is not meant to do what may be
+called indefinite summation, only definite summations (hence the name %defsum).
+Note that the result from
+
+eval(D(f(x),x),f,y+->sum(g(i,y),i=a..y))
+
+ %defsum (g(%A,%%01),%A,i,a,x)
+
+comes from dvdsum again and is consistent with the formula I gave above, except
+that I would not expect %%01 but rather just x.
+
+
+\start
+Date: Wed, 9 Jun 2004 09:04:28 -0400
+From: Tim Daly
+To: daniel.augot@inria.fr
+Subject: [Axiom-developer] unparse
+
+cool. I didn't know unparse existed. --t
+
+
+\start
+Date: Wed, 9 Jun 2004 16:27:49 +0200 (CEST)
+From: "m.rubey"
+To: William Sit
+Subject: [Axiom-developer] Re: Patches
+Cc: "Bronstein, Manuel"
+
+On Wed, 9 Jun 2004, William Sit wrote:
+
+> 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
+>
+> Note this was because before I clear all, I had defined %B and did a
+> New()$SYMBOL that gives %C.
+>
+> (3) -> G1419::SYMBOL
+> G1419
+>
+> (4) -> symbol(GENSYM()$Lisp)
+> G84337
+>
+> All output are of type Symbol.
+
+In fact, I was hoping that the NAG version would do this. I suspect this
+is a GCL issue. I will send Camm Maguire a message.
+
+> I also got the product summation display correctly without error
+> message, unless the upper limit is a constant.
+
+This is the same in the Open Source version. The problem appears only when
+*both* of the limits are constants.
+
+> Thus I think Bronstein's use of new()$Symbol is correct, but somewhere
+> in the open source version, new()$Symbol get clobbered. Of course, you
+> can patch Bronstein's code to force a new symbol each time, but other
+> packages that use new()$Symbol will still fail, as you recognized. I
+> believe the source of the error is more subtle and probably does not
+> come from new()$Symbol either.
+
+I don't think that this is the case.
+
+> Another reason why I think the error does not come from the source code is
+> because any iteration in Axiom, the iterating variable is a dummy (and
+> supposedly unique and local in scope). (Can Tim affirm this?)
+
+If I understand correctly, dummy := new()$SE::F assigns a new symbol to
+the variable "dummy" once and for all. So, if I'm not mistaken, the policy of
+axiom which you describe is violated in COMBF, and probably in other
+packages too. It is not so unlikely that this produces errors only very
+rarely, since errors will only occur if you nest procedures from one
+package -- and not even in this case they show up unconditionally. I will
+try to produce errors in other packages that use dummy := new()$Symbol.
+BTW, line 625-6 of fspace.spad seems to refer to this problem too...
+
+-- cannot use new()$Symbol because of possible re-instantiation
+ gendiff := "%%0"::SY
+
+.....
+
+However, since I'm using axiom only since a few weeks, it is quite
+possible that I'm mistaken.
+
+> Bug Report #9216:
+>
+> Regarding dvdsum, I find it hard to follow Bronstein's code
+> (CombinatorialFunction constructor in combfunc.spad), because I need to
+> trace all the packages to figure out what opdsum does (it seems to be a
+> hold to do recursion, but I am not sure and opdsum is not an exported
+> function, neither is dvdsum).
+
+opdsum is a variable holding the operator %defsum. The line
+
+evaluate(opdsum, iidsum)
+
+in COMBF instructs axiom to evaluate %defsum using the procedure iidsum.
+In other words, everywhere you see opdsum in the code, axiom will call
+iidsum upon evaluation.
+
+> Assuming it is just a summation, mathematically speaking, then my guess
+> is dvdsum does the following: it takes two arguments, a list with five
+> parameters, and a symbol. Using Bronstein notation in the code (without
+> regard to type, just mathematical and forget all the coercions), the
+> first is [f,k,y,g,h], all belonging to some function space F, such as
+> Expression Integer and the second is x. Here
+>
+> f is the function to be summed with dummy variable k,
+> k is the dummy (for summation),
+> y is some symbol
+> g is the lower limit of summation, presumably a function of x
+> h is the upper limit of summation, presumably a function of x
+> x is the symbol with respect to which differentiation is to be done
+
+This is what I strongly believe, too.
+
+> What the code dvdsum does, assuming odpsum is just summation, is to
+> return the following: d/dx means differentiation wrt x (not the d in the
+> code)
+>
+> 0 if the variable y retracts to x, otherwise the formula:
+>
+> d(h)/dx f(h) - d(g)/dx f(g) + summation(d(f)/dx, k = g..h)
+
+Yes.
+
+> I have no clue what this formula means, for example, what is the role of y?
+
+y plays no role, since it is used *only* for display. This is the
+philosophy behind all the operators that use a dummy var. (called
+-- operators whose second argument is a dummy variable
+ dummyvarop1 := [opdiff,opalg, opint, opsum, opprod]
+-- operators whose second and third arguments are dummy variables
+ dummyvarop2 := [opdint, opdsum, opdprod]
+
+in op.spad)
+
+I think that the reason for doing this is to be able to let a standard
+eval (such as the eval in FS) evaluate applications of these operators,
+but I#m not at all sure about this. I think we should ask Bronstein.
+
+> however, I hesitate to say it is wrong because Bronstein is quite
+> careful, both as a mathematician and a wizard in Axiom and Aldor.
+> dvdsum occurs only three times in the source, once in the signature,
+> once in the definition, and once in an obscure setProperty statement
+> related to opdsum.
+
+the setProperty statement
+
+setProperty(opdsum,SPECIALDIFF,dvdsum@((List F,SE)->F) pretend None)
+
+instructs axiom to use dvdsum for differentiating %defsum. Lines 766-8 of
+fspace.spad read
+
+ -- SPECIALDIFF contains a map (List %, Symbol) -> %
+ -- it is used when the usual chain rule does not apply,
+ -- for instance with implicit algebraics.
+
+> ----------------
+> Bug Report #9215:
+>
+> sum(box(i),i=a..b)
+>
+> returns the answer correctly, but the outputForm missed a pair of parenthesis
+> aa-1 should be a(a-1);
+>
+> box(sum(i),i=1..n)
+>
+> also returns correctly, because after sum is evaluated to (n^2+n)/2, an
+> (invisible) box is placed around it. Note the box is useful ONLY when
+> there is an operator operating on the box content. The only way this is
+> easy to use is when the operator takes one argument, such as sin, cos,
+> log. The argument can be a list of course.
+
+I thought that box would simply prevent axiom from doing evaluation. I
+still don't understand.
+
+> ---------------
+> Bug Report 9218:
+>
+> I believe the CombinatorialFunctions package is not meant to do what may
+> be called indefinite summation, only definite summations (hence the name
+> %defsum).
+
+I don't understand the relation of this to my bug report. Sorry.
+
+> Note that the result from
+>
+> eval(D(f(x),x),f,y+->sum(g(i,y),i=a..y))
+>
+> %defsum (g(%A,%%01),%A,i,a,x)
+>
+> comes from dvdsum again and is consistent with the formula I gave above,
+> except that I would not expect %%01 but rather just x.
+
+The %%01 is the dummy variable used for differentiation (see line 625 of
+fspace.spad).
+
+Thanks for your effort, I'm sure we'll fix all this!
+
+\start
+Date: Wed, 09 Jun 2004 19:04:22 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] Software Archaeology/Patches
+
+root writes:
+
+> Your email hasn't been ignored. It's just queued behind others.
+
+I confirm for my side.
+
+> I know it feels like it's being ignored, a feeling email tends to
+> generate. The best path is to file a bug report on the axiom website.
+> That makes a permanent record. It may already be there as David Mentre
+> manages that.
+
+Unfortunatly, I'm a bit lagged on that side.
+
+And, more importantly, I'm fairly incompetent regarding Axiom algebra
+code.
+
+So Martin, your bug report wasn't forgotten but I had not appropriate
+response at that time.
+
+But you're right that I should give proper feedback.
+
+
+\start
+Date: Wed, 9 Jun 2004 17:13:26 -0400
+From: root
+To: alenka_zajka@mail.ru
+Subject: [Axiom-developer] Re: MONET Axiom front end -- half way to success
+
+Elena,
+
+If you do:
+
+)set output length 254
+
+and then use unparse (see the attached) you can get the output
+in a flat form.
+
+Tim
+
+
+==================================================================
+
+You may wish to use the InputForm domain, where you can find some
+bizarre functions. In your case, "unparse" may help you, as follows.
+
+Best regards,
+
+Daniel
+
+(1) -> p:=(a+b+y)^2*y+1-(x+y+z)^4
+
+
+ (1)
+ 4 3 2 2 2
+ - z + (- 4y - 4x)z + (- 6y - 12x y - 6x )z
+ +
+ 3 2 2 3 4 3 2 2
+ (- 4y - 12x y - 12x y - 4x )z - y + (- 4x + 1)y + (- 6x + 2b + 2a)y
+ +
+ 3 2 2 4
+ (- 4x + b + 2a b + a )y - x + 1
+ Type: Polynomial Integer
+(2) -> pi:=p::InputForm
+
+ (2)
+ (+
+
+ (+
+
+ (+ (+ (* - 1 (** z 4)) (* (+ (* - 4 y) (* - 4 x)) (** z 3)))
+ (* (+ (+ (* - 6 (** y 2)) (* (* - 12 x) y)) (* - 6 (** x 2))) (** z 2)))
+
+
+ (*
+
+ (+
+
+ (+ (+ (* - 4 (** y 3)) (* (* - 12 x) (** y 2)))
+ (* (* - 12 (** x 2)) y))
+
+ (* - 4 (** x 3)))
+
+ z)
+ )
+
+
+ (+
+
+ (+
+
+ (+ (+ (* - 1 (** y 4)) (* (+ (* - 4 x) 1) (** y 3)))
+ (* (+ (* - 6 (** x 2)) (+ (* 2 b) (* 2 a))) (** y 2)))
+
+ (* (+ (* - 4 (** x 3)) (+ (+ (** b 2) (* (* 2 a) b)) (** a 2))) y))
+
+ (+ (* - 1 (** x 4)) 1))
+ )
+ Type: InputForm
+(3) -> unparse(pi)
+
+ (3)
+ "(-z**4)+((-4*y)+(-4*x))*z**3+((-6*y*y)+(-12*x*y)+(-6*x*x))*z*z+((-4*y**3)+(-
+ 12*x*y*y)+(-12*x*x*y)+(-4*x**3))*z+(-y**4)+((-4*x)+1)*y**3+((-6*x*x)+2*b+2*a)
+ *y*y+((-4*x**3)+b*b+2*a*b+a*a)*y+(-x**4)+1"
+ Type: String
+
+(4) -> )sh InputForm
+ InputForm is a domain constructor
+ Abbreviation for InputForm is INFORM
+ This constructor is not exposed in this frame.
+ Issue )edit /local/augot/axiom/mnt/linux/../../src/algebra/INFORM.spad to see algebra source code for INFORM
+
+------------------------------- Operations --------------------------------
+ #? : % -> Integer ?*? : (%,%) -> %
+ ?**? : (%,Integer) -> % ?+? : (%,%) -> %
+ ?/? : (%,%) -> % ?=? : (%,%) -> Boolean
+ 1 : () -> % 0 : () -> %
+ atom? : % -> Boolean binary : (%,List %) -> %
+ car : % -> % cdr : % -> %
+ coerce : % -> OutputForm convert : SExpression -> %
+ convert : % -> SExpression convert : OutputForm -> %
+ convert : DoubleFloat -> % convert : Integer -> %
+ convert : Symbol -> % convert : String -> %
+ convert : List % -> % declare : List % -> Symbol
+ destruct : % -> List % ?.? : (%,List Integer) -> %
+ ?.? : (%,Integer) -> % eq : (%,%) -> Boolean
+ expr : % -> OutputForm flatten : % -> %
+ float : % -> DoubleFloat float? : % -> Boolean
+ hash : % -> SingleInteger integer : % -> Integer
+ integer? : % -> Boolean interpret : % -> Any
+ lambda : (%,List Symbol) -> % latex : % -> String
+ list? : % -> Boolean null? : % -> Boolean
+ pair? : % -> Boolean string : % -> String
+ string? : % -> Boolean symbol : % -> Symbol
+ symbol? : % -> Boolean unparse : % -> String
+ ?~=? : (%,%) -> Boolean
+ ?**? : (%,NonNegativeInteger) -> %
+ compile : (Symbol,List %) -> Symbol
+ function : (%,List Symbol,Symbol) -> %
+
+
+\start
+Date: Thu, 10 Jun 2004 18:01:22 +1000
+From: "Mike Thomas"
+To: "Bill Page"
+Subject: RE: [Axiom-developer] Axiom on Windows
+Cc: Camm Maguire
+
+Hi Bill.
+
+Armed with a better understanding of Axiom I rebuilt with:
+
+1. The release version of MSYS (1.10) - fixes make.exe crashes.
+2. Latest MinGW runtime library 3.3.
+3. Stopped using the GCL 2.6.2c2 stable CVS source tree.
+4. Hand altered the Axiom GCL source tree with backported critical Windows
+fixes.
+5. Fixed some return value oversights caused by my hacking in the Axiom C
+library.
+6. Maximum number of files raised from 512 with "_setmaxstdio ( 2048 )" in
+"o/main.c".
+
+Unfortunately I still had to copy things by hand due to that earlier
+reported seg-fault, but at least the build went a little more smoothly.
+
+The regression tests ran with just under 40 seg faults during the run.
+
+\start
+Date: Thu, 10 Jun 2004 08:12:46 -0400
+From: William Sit
+To: "m.rubey"
+Subject: [Axiom-developer] Bugs in combfunc.spad and partial patch
+Cc: "Bronstein, Manuel"
+
+Hi Martin:
+
+Thanks for the detail explanations. The following discussion relates to
+combfunc.spad (by Bronstein) and bug report 9218. I am changing the thread
+heading to reflect the context of this discussion (previous thread: Patches)
+
+> -- cannot use new()$Symbol because of possible re-instantiation
+> gendiff := "%%0"::SY
+
+Could this be in the open source version, something gets re-instantiated when it
+shouldn't? It seems Bronstein thinks it is ok to use one dummy within a package,
+but worries when two or more are instantiated (hence the %% instead of %, which
+appears in the output of Bug Report #9218).
+
+> If I understand correctly, dummy := new()$SE::F assigns a new symbol to
+> the variable "dummy" once and for all. So, if I'm not mistaken, the policy of
+> axiom which you describe is violated in COMBF, and probably in other
+> packages too. It is not so unlikely that this produces errors only very
+> rarely, since errors will only occur if you nest procedures from one
+> package ...
+
+I agree with you on both. The first is so that the two occurrences of dummy in a
+loop gets compiled into the same variable.
+
+The second, about the violation, is subtle. Of course, it is wrong to code:
+
+ [[k for k in 1..5] for k in 1..6]
+
+because it is expected that the body of the loop will involve the outer k and it
+is not possible in general to figure out which k the k in the inner body refers
+to. So my "local principle" cannot be automatically enforced in a nested loop:
+there is no way to reassign the inner k or the outer k to a new variable to make
+it work. I think, however, the Axiom compiler or interpreter should give a
+warning or error flag on this one (currently, it just gives an answer).
+
+However, it is perfectly ok to do:
+
+ k:= 7
+ foo(i)==[k for k in 1..i]
+ bar(t,j)==[t for k in 1..j]
+
+and call bar(foo(2),3). One is allowed to reuse k as long as it is not nested
+even if the functions are later composed and k is also globally defined. Now
+Bronstein's case is in theory similar but really not. In combfunc.spad, if I
+did not miss any count, Bronstein never used nested loops with the same dummy
+identifier. There are only four functions (product, summation; each with dual
+signatures) using the identifier dummy, each time in a simple "loop" (see
+later). It was in the interpreter when in your example, a nested loop was used
+with two functions by composing product with summation. But surely, there is
+nothing wrong in the code to use the same iteration variable in different loop
+constructs that are not nested.
+
+So where is the error? I think it lies in two facts:
+
+(a) the identifier dummy is not a Symbol, but coerced into F (a domain such as
+Expression Integer), and
+
+(b) Bronstein did not use the identifier dummy directly in a for-loop, because
+it would not be allowed if the lower or upper limits of the summation (or
+product) are not retractible to integers (say functions of x and therefore
+"indefinite") in a for-construction.
+
+A trace of the functions (thanks for your helpful pointers) iidsum (for integer
+to integer definite summation, I suppose) shows that when the limits are both
+integers, a simple term by term summation is used to evaluate the sum, and the
+code is a simple for-loop with a symbol identifier as the loop variable. When
+either one is anything else, the function idsum (for indefinite summation?) is
+called which simply holds the sum unevaluated (kernel(opdsum,l)).
+
+Thus the compiler did not treat the identifier dummy as a local variable but as
+a global variable (inspection of code.lsp confirms this).
+
+So there are four problems to be fixed:
+
+(0) new()$Symbol should generate a new one each time it is used (this bug does
+not exist in Axiom 2.3 NAG, and seems unrelated to Bug Report 9218)
+
+(1) the identifier dummy needs to be different for EACH INVOCATION of the four
+functions in combfunc.spad (two product and two summation functions), not just
+for each FUNCTION, because one can still compose product with product as in
+ product(product(i*j, i=a..b),j=c..d)
+
+The fix is not to use four separate dummy identifiers, but rather to IN-LINE
+new()$Symbol with a LOCAL identifier in each of the four functions, AND WHEN
+COMBINED WITH the fix (0), this problem can be resolved. See proposed patch at
+end (tested in NAG version). Note: the same kind of fix should probably be done
+in fspace.spad.
+
+BTW, currently, even in NAG version, such compositions where product may be
+replaced by summation, gave wrong results (as well as wrong displays for lack of
+needed parenthesis -- to see true returned results, )set output tex on. So:
+
+(1a) wrap outputs in product or summation in parenthesis for correct display:
+example of error (ignore error in the value):
+
+ )set output tex on
+ product(summation(i*j, i=a..b),j=c..d)
+
+(2) the formula for differentiating a sum (in dvdsum) needs to be revised and
+the call to dvdsum (or its equivalences) should return an unevaluated expression
+when the summation cannot be evaluated in close form. A similar problem probably
+also exist for differentiation a product.
+
+
+> > ----------------
+> > Bug Report #9215:
+> >
+> > sum(box(i),i=a..b)
+> >
+> > returns the answer correctly, but the outputForm missed a pair of parenthesis
+> > aa-1 should be a(a-1);
+> >
+> > box(sum(i),i=1..n)
+> >
+> > also returns correctly, because after sum is evaluated to (n^2+n)/2, an
+> > (invisible) box is placed around it. Note the box is useful ONLY when
+> > there is an operator operating on the box content. The only way this is
+> > easy to use is when the operator takes one argument, such as sin, cos,
+> > log. The argument can be a list of course.
+>
+> I thought that box would simply prevent axiom from doing evaluation. I
+> still don't understand.
+
+box is a function, so all its arguments are evaluated before being passed. What
+box prevents evaluation is the function of which it is the argument. So in the
+first example, sum(box(i),i=a..b), there is NO function of which box(i) is an
+argument. It is not easy to wrap two arguments in the box without destroying the
+syntax, since box takes only one argument. Now if you were to try
+ factor((x-1)*(x-2))
+and
+ factor(box((x-1)*(x-2)))
+you will see the difference. In the first case, the answer is factored, in the
+second case it is not. In each case, the two given factors were multiplied
+before passing to box, but in the second case, factor does not apply.
+
+> > ---------------
+> > Bug Report 9218:
+> >
+> > I believe the CombinatorialFunctions package is not meant to do what may
+> > be called indefinite summation, only definite summations (hence the name
+> > %defsum).
+>
+> I don't understand the relation of this to my bug report. Sorry.
+>
+> > Note that the result from
+> >
+> > eval(D(f(x),x),f,y+->sum(g(i,y),i=a..y))
+> >
+> > %defsum (g(%A,%%01),%A,i,a,x)
+> >
+> > comes from dvdsum again and is consistent with the formula I gave above,
+> > except that I would not expect %%01 but rather just x.
+>
+
+What I meant was that from the trace of the code, Bronstein wants to leave a
+summation unevaluated if either of the summation limit is "indefinite" (in his
+code, this means not an integer). I am not sure under what condition he intended
+dvdsum to be invoked, but as you pointed out, the formula encoded in dvdsum can
+only be true under certain conditions. Now it seems that every time a summation
+cannot be evaluated, dvdsum is called, giving wrong results in the cases we
+tried. The eval example above is mathematically equivalent (at least I think
+that was your intention because f is just an unknown operator) to
+
+ D(sum(g(i,x),i=a..x),x) which gives
+
+summation (displayed) from i=a to x of the partial with respect to the second
+argument of g at (i,x) plus g(x,x), which is following the formula in dvdsum
+because the lower limit is independent of x. Normally, eval is not executed
+until all its arguments are evaluated first. Now Bronstein implements diffEval
+in fspace.spad, so eval probably should not perform a substitution
+differentially (replacing f and differentiate). It should not have succeeded in
+any substitution since f no longer "appear" in f'(x) --- at least that is the
+case in Mathematica or Maple. In Axiom, it seems the substitution is still made.
+So the answer should be the same as above, with two terms: a summation and
+g(x,x).
+
+> The %%01 is the dummy variable used for differentiation (see line 625 of
+> fspace.spad).
+
+Are you suggesting that
+
+ %defsum (g(%A,%%01),%A,i,a,x)
+
+means sum from i=a to x the partial of g with respect the second variable
+evaluated at (i,x)? What happened to g(x,x)? This is not consistent with:
+
+eval(D(f(x),x),f,y+->sum(g(i+y),i=a..y))
+
+which gives
+
+ %defsum (g(%A+%%01),%A,i,a,x)
+
+All this is garbage-in garbage-out because such operations were probably not
+intended. But this is only a conjecture (that is what archeologists do). We can
+follow the code, but it does not make sense to me.
+
+William
+------
+Proposed fix for (1) (tested for NAG version) with the following inputs:
+
+ product(summation(i*j), i=a..b), j=c..d)
+
+and similar variations. However, I have NOT tested whether this will affect
+other computations! (It should not, but who knows?)
+
+Patch for combfunc.spad:
+
+Step 1. Delete line
+ dummy := new()$SE::F
+
+Step 2. Replace the definition of product, summation by:
+
+ product(x:F, i:SE) ==
+-- opprod [eval(x, k := kernel(i)$K, dummy), dummy, k::F]
+++ opprod [eval(x, k := kernel(i)$K, h:=new()$SE::F), h, k::F]
+
+ summation(x:F, i:SE) ==
+-- opsum [eval(x, k := kernel(i)$K, dummy), dummy, k::F]
+++ opsum [eval(x, k := kernel(i)$K, h:=new()$SE::F), h, k::F]
+
+ product(x:F, s:SegmentBinding F) ==
+ k := kernel(variable s)$K
+-- opdprod [eval(x, k, dummy), dummy, k::F, lo segment s, hi segment s]
+++ opprod [eval(x, k, h:=new()$SE::F), h, k::F, lo segment s, hi segment s]]
+
+ summation(x:F, s:SegmentBinding F) ==
+ k := kernel(variable s)$K
+-- opdsum [eval(x, k, dummy), dummy, k::F, lo segment s, hi segment s]
+++ opdsum [eval(x, k, h:=new()$SE::F), h, k::F, lo segment s, hi segment s]]
+
+
+\start
+Date: Thu, 10 Jun 2004 08:43:20 -0400
+From: William Sit
+To: "m.rubey" , "Bronstein, Manuel"
+Subject: Re: [Axiom-developer] Bugs in combfunc.spad and partial patch
+
+Hi Martin:
+
+My sincere apology for not noticing the patch (3121) sumprod.patch you posted.
+(The reason was that patch was not attached to the email #9057:
+
+-------- Original Message --------
+Subject: [Axiom-developer] Patches (?) for sum/product and sqrt
+Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
+From: "m.rubey"
+To: axiom-developer@nongnu.org
+...
+---------
+So my previous analysis was not necessary. My patch at the end of the previous
+message was essentially the same as yours.
+
+\start
+Date: Thu, 10 Jun 2004 06:35:20 -0400
+From: Tim Daly
+To: bill.page1@sympatico.ca
+Subject: [Axiom-developer] ideas on algebra of tainted points
+
+Bill,
+
+He was looking for your email address...
+
+Tim
+
+------- Start of forwarded message -------
+Date: Thu, 10 Jun 2004 06:28:00 +1200
+To: Tim Daly
+From: Craig Carey
+Subject: Can't subscribe to mailing list; ideas on algebra of tainted
+ points
+Cc: Bertfried Fauser
+
+CCed to Mr Fauser under a special axiomatic principle I am not
+disclosing (maybe the axiom is wrong).
+
+
+I attempted to subscribe to 2 Axiom mailing lists. My attempts
+failed with this error message:
+
+- ----------------------------------------
+Axiom-developer Subscription results
+You must supply a valid email address.
+- ----------------------------------------
+ From URL: http://lists.nongnu.org/mailman/subscribe/axiom-developer
+
+The only information I had entered into the form was my e-mail
+address.
+
+I see Mr Fauser wrote. E.g. wrote this:
+
+"iii) u _| ( v _| w) = (u /\ v) _| w (left action on the module V^)"
+ http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00006.html
+
+The _| is like a projection onto a flat except that the projected part
+is rotated by 90 degrees:
+(A _| B) = (Sum r,s)(A[r].B[s])[s-r].(r<=s)
+ where x[r] is the part of x that is the product of r vectors.
+ i.j = -j.i; i.j = +1. I say so here: http://www.ijs.co.nz/polytopes.htm
+
+Mr Fauser might have to do some coding himself. E.g. Clifford algebra
+does not have polytopes to rotate since lacking a "<" less-than operator,
+yet being antisymmetric, it is mainly about rotating. In logic,
+rotations don't occur but shearing might.
+
+It could be a special case of logic, i.e. extended this:
+ 1 polytopes
+ 2 polytopes with real-values. This seems too difficult since Exists
+ creates polynomials and roots are solved since Exists of And's, is
+ Min-ing triangle functions.
+ Booleans are replaced with non-negative reals, and:
+ x And y = Min(x,y), x Or y = Max(x,y). 'Not' has to be deleted.
+ Could define "<" onto polytopes.
+ 3 next, polytopes contain vectors.
+ 4 next, the extension is have Clifford/etc. numbers inside of
+ polytopes.
+
+That is a bit general. I need not look beyond the software problems
+involved in implementing the algebra is to Hopf algebras, what
+polytopes are to points (joke). Still no evidence that Mr Grassmann's
+failure was due to the lack of computers, as far a I can assess.
+
+Mathematica has got pattern matching.
+
+I don't have Mr Page's e-mail address.
+
+- --
+
+My Tope solver now includes the O.R. Double-description/Chernikova
+algorithm made in France by LeVerge of irisa.fr a decade ago. I merely
+make it look like my solver is all symbolic but the breakthrough was
+to:
+ * impose restrictions on the user (no parameterized polytopes for the
+ shadow operator. (Bagnali calls it the "image" operator:
+ http://www.cs.unipr.it/ppl/ )
+
+ * copy in a Operations Research algorithm and give it a fully
+ symbolic front-end.
+
+ * not needed but present is no support for quadratics, e.g.
+ "Exists x)(0
+To: research@ijs.co.nz
+Subject: [Axiom-developer] Re: Multiple solvers behind a command line GUI
+
+Craig,
+
+I gather from you email messages that you have a computer algebra
+system. Which one is it? Where can I find it?
+
+\start
+Date: Thu, 10 Jun 2004 15:27:30 -0700 (PDT)
+From: Clifton Williamson
+To: daly@idsi.net, mechvel@botik.ru
+Subject: Re: [Axiom-developer] output format
+
+To stop output to a file, type
+
+)spool )off
+
+Even simpler, you can just type
+
+)spool
+
+The command
+
+)spool off
+
+is telling the system to direct output to a file
+called 'off'. This causes problems when you are
+already spooling to a different file.
+
+Clifton
+
+--- root wrote:
+> Serge,
+>
+>
+> >So far, I have a small question of how to print a
+> polynomial,
+> >polynomial factorization "to line".
+> >
+> >The program a.input is of kind
+> >
+> > P := MPOLY([p,e,s], Integer)
+> > ...
+> > ft = factor f
+> > )spool axres
+> > output ft;
+> > )spool off
+> >
+> >
+> >The commands > axiom
+> > ...
+> > (1) -> )r a.input
+> >yield
+>
+> .....[snip].....
+>
+> >
+> > )spool off
+> >
+> >
+> > >> System error:
+> > Already in dribble (to axres).
+>
+> This error message is coming from the underlying
+> lisp image (in
+> lsp/gcl-2.6.2a/lsp/gcl_iolib.lsp), not from Axiom. I
+> don't understand
+> yet why it occurs but I'll look into it.
+>
+>
+> >
+>
+------------------------------------------------------------
+> >
+> >
+> >1. What may be this `error'?
+> >
+> >2. I would also like to have the output of kind
+> >
+> > " - (s-1) * (s+1) * (p^4 +(2*e^3 + (24*s^2 -
+> 4)*e)*p^3 * ...) * ...
+> > "
+> >
+>
+> Axiom does not, as far as I know, have a "linear"
+> output representation.
+
+\start
+Date: Thu, 10 Jun 2004 19:46:51 -0400
+From: root
+To: clifton_williamson@yahoo.com
+Subject: Re: [Axiom-developer] output format
+Cc: mechvel@botik.ru
+
+duh. i knew that :-)
+it's amazing but once I saw
+
+)spool off
+
+I couldn't remember
+
+)spool )off
+
+Thanks for the answer.
+
+\start
+Date: Fri, 11 Jun 2004 07:05:16 +0200 (CEST)
+From: Bertfried Fauser
+To: William Sit
+Subject: Re: [Axiom-developer] RE: learning in public
+Cc: "Page, Bill" , Bertfried.Fauser@uni-konstanz.de
+
+On Wed, 9 Jun 2004, William Sit wrote:
+
+> QFORM QuadraticForm in clifford.spad
+> CLIF Clifford Algebra in clifford.spad
+> (over any field K and quadratic form on K^n)
+> GRMOD Graded Module in carten.spad
+> GRALG Graded Algebra in carten.spad
+> CARTEN CartesianTensor in carten.spad (tensor algebra)
+> CARTEN2 CartesianTensorFunction2 in carten.spad
+> SYMFUNC SymmetricFunctions in efstruc.spad (by Manuel Bronstein)
+> PRTITION Partition in prtition.spd (by William Burge)
+> SYMPOLY SymmetryPolynomial in prtition.spad (by Wiliam Burge)
+> BMODULE BiModule in catdef.spad (probably by Watt also)
+
+Dear Prof Sit,
+
+ thats a good starting point. I was able only of the sym functions
+and clifford/quadratic forms categories. I will try to understand whats
+going on there. Perhaps I can "morph" some code into what I want to do.
+
+> On the contrary, such universal objects are the key to construction of free
+> objects and morphisms in the category (examples are vector spaces where you can
+> define morphisms by specifying only values on a basis; but also works for higher
+> algebras such as free shuffle algebra) and the non-free ones are done by forming
+> quotients.
+
+Indeed, the value of universal constructions is beyond any doubt, but
+they usually are not algorithmical. So not useful for implementations.
+
+> To have different order relation or grading (filtration), it would be best to
+> modify the source to allow an additional parameter or two. For example, in
+> polynomial algebra, different term ordering can be done in GDMP (Generalized
+> Distributed Multivariate Polynomial), which is a domain constructor by modifying
+> DMP or HDMP. A CliffordAlgebra CATEGORY is needed if the REPRESENTATION of the
+> SAME (mathematically) algebra changes (or when the code for the basic operations
+> will be changed; for example if there are more efficient algortihms when the
+> points are ordered). For polynomial algebra, a category is created so that
+> different representations (DMP, POLY, SMP) can be used.
+
+OK, that are further good hints where to look for a starting point.
+
+> I suggest starting with generalizing the present CliffordAlgebra to include in
+> order:
+> (1) arbitrary symmetric bilinear form (may need SymmetricAlgebra, but may be not
+> by using SYMPOLY)
+> (2) grading (and/or order) (using GRALG and GRMOD)
+> (3) bimodule structure using BIMODULE
+>
+> Then when needed, create Hopf Algebra based on this experience.
+
+Unfortunately, I see it rather the other way arround. If I need clifford
+stuff, I can use our Clifford/Bigebra package. So doing a new atack to the
+problem, I will try to do something rather fundamental, otherwise its not
+woth the time effort, since I am computationally on a large subset. The
+same point prevents me from trying "simply" to do an impementation of
+Clifford/Bigebra in AXIOM.
+
+My colleague, Rafal Ablamowicz, is using windows, so I will probably
+benefit from a windows port and see with great pleasure that there is big
+progress.
+
+So, the name of the game is to write a (Hopf algebra powered) super
+symmetric multilinear algebra package, which allows to itereate itself.
+This includes:
+* Grassmann and Symmetric algebras (superalgebras) [these are naturally Hopf]
+* Symmetric functions [see Rota/Stein Plethystics algebras as cited in the
+ previous mail and math-ph/0308043
+* implementation of a twist deformation of these structures
+* further functionality, like antipode, twists, etc
+* representations
+* ....
+
+I will try to make a start :-)
+
+\start
+Date: Fri, 11 Jun 2004 10:48:52 +0200 (CEST)
+From: "m.rubey"
+To: William Sit
+Subject: Re: [Axiom-developer] Bugs in combfunc.spad and partial patch
+
+This is really my fault. From now on, I will insert a comment also in the
+Bug Report referring to the proposed patch. (In fact, this should be done
+automatically, I think)
+
+On the other hand, I like your patch better, since it is more in line with
+the rest of axiom code...
+
+Thanks,
+
+Martin
+
+
+On Thu, 10 Jun 2004, William Sit wrote:
+
+> Hi Martin:
+>
+> My sincere apology for not noticing the patch (3121) sumprod.patch you posted.
+> (The reason was that patch was not attached to the email #9057:
+>
+> -------- Original Message --------
+> Subject: [Axiom-developer] Patches (?) for sum/product and sqrt
+> Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
+> From: "m.rubey"
+> To: axiom-developer@nongnu.org
+> ...
+> ---------
+> So my previous analysis was not necessary. My patch at the end of the previous
+> message was essentially the same as yours.
+
+\start
+Date: Fri, 11 Jun 2004 12:32:10 +0200 (CEST)
+From: "m.rubey"
+To: William Sit
+Subject: [Axiom-developer] Re: Bugs in combfunc.spad and partial patch
+Cc: "Bronstein, Manuel"
+
+On Thu, 10 Jun 2004, William Sit wrote:
+
+> Note: the same kind of fix should probably be done in fspace.spad.
+
+probably. TIM: Where should we note this? Maybe it would be good to have a
+list where we could note such things on savannah.
+
+> BTW, currently, even in NAG version, such compositions where product may
+> be replaced by summation, gave wrong results (as well as wrong displays
+> for lack of needed parenthesis -- to see true returned results, )set
+> output tex on. So:
+>
+> (1a) wrap outputs in product or summation in parenthesis for correct display:
+> example of error (ignore error in the value):
+>
+> )set output tex on
+> product(summation(i*j, i=a..b),j=c..d)
+
+I noticed this to. Bug report on the way
+
+> (2) the formula for differentiating a sum (in dvdsum) needs to be
+> revised and the call to dvdsum (or its equivalences) should return an
+> unevaluated expression when the summation cannot be evaluated in close
+> form. A similar problem probably also exist for differentiation a
+> product.
+
+I thought about this a little further. At first I thought that
+differentiating a sum with respect to one of its bound should yield an
+error!
+
+The reason was, that this construct is not well-defined, since sum as a
+function of one of the bounds (say the upper) is (should be, I'll comment
+on this a little later) a function from the integers into some space:
+
+n+->sum(f(i,a,n),i=a..n)
+
+Therefore, there is no such thing as a differential!
+
+For example, usually we say that
+
+sum(i,i=1..n) should give n*(n+1)/2
+
+but I don't see any good reason, why it shouldn't be
+
+n*(n+1)/2*cos(2*n*%pi)
+
+which has a very different derivative with respect to n...
+
+However: both Maple 8 and Mathematica 5 return the result unevaluated, so
+we could do so, too. (However I don't know how to do it...)
+
+Furthermore: If we decide to yield an error, sums that can be evaluated in
+closed form will still give the "expected" (in the naive sense) result.
+Thus, this might be somewhat inconsistent...
+-----------------------------------------------------------------------------
+
+The one thing which really got me going on all this is the following: I
+wrote a program that *wants* to spit out things like
+
+sum(product(f(i),i=1..j),j=1..n),
+
+where f is a rational function in i, with coefficients in some (specified)
+infinite field.
+
+Unfortunately, it turned out that this is not possible in axiom at the
+moment: sum (and product too) take an "Expression" as their first
+argument, and 2*x^3::POLY PF 3 is *not* an expression, since EXPR takes an
+OrderedSet as argument, which PF 5 is not. (curiously, a::EXPR CHAR is
+valid. I was also surprised to find that Complex ORDSET has ORDSET, namely
+lexicographically.)
+
+Now, there are several things that I do not quite understand:
+
+* Why does EXPR ask for an OrderedSet?
+
+* Why don't we have EXPR POLY INT but only EXPR INT? Maybe the reason for
+this is that there is an operation ** in EXPR?
+
+* How can I adapt EXPR so that I can have sums of POLY PF 5?
+
+Consider
+
+2*x^3::POLY PF 3
+
+should the 3 in x^3 be an element of PF 3 (i.e., be equal to zero) or
+should it be an integer? Currently there is no exponentiation where the
+exponent could be from PF 3, except of a highly suspicious
+
+ [21] (D,D1) -> D from D
+ if D has UTSCAT D1 and D1 has RING and D1 has FIELD
+
+(As an aside: Indeed, strange things happen when we use this ^:
+
+ (x::UPXS(PF 5,x,0))^(4::PF 5)
+
+ >> Error detected within library code:
+ "log of function with singularity"
+
+)
+
+Well, thinking about it, this doesn't seem to be a problem. The user can
+always specify which operation should be used.
+
+* I think that the modeline of sum *should* be
+
+(D1->EXPR Something, SEGBIND D1)->EXPR Something where D1 has ORDSET.
+
+Sorry for so many questions...
+
+> > > ----------------
+> > > Bug Report #9215:
+> > >
+> > > sum(box(i),i=a..b)
+> > >
+> > > returns the answer correctly, but the outputForm missed a pair of
+> > > parenthesis aa-1 should be a(a-1);
+> > >
+> > > box(sum(i),i=1..n)
+> > >
+> > > also returns correctly, because after sum is evaluated to (n^2+n)/2, an
+> > > (invisible) box is placed around it. Note the box is useful ONLY when
+> > > there is an operator operating on the box content. The only way this is
+> > > easy to use is when the operator takes one argument, such as sin, cos,
+> > > log. The argument can be a list of course.
+> >
+> > I thought that box would simply prevent axiom from doing evaluation. I
+> > still don't understand.
+>
+> box is a function, so all its arguments are evaluated before being passed. What
+> box prevents evaluation is the function of which it is the argument. So in the
+> first example, sum(box(i),i=a..b), there is NO function of which box(i) is an
+> argument. It is not easy to wrap two arguments in the box without destroying the
+> syntax, since box takes only one argument. Now if you were to try
+> factor((x-1)*(x-2))
+> and
+> factor(box((x-1)*(x-2)))
+> you will see the difference. In the first case, the answer is factored, in the
+> second case it is not. In each case, the two given factors were multiplied
+> before passing to box, but in the second case, factor does not apply.
+
+Thanks for this explanation! This should go into the docs!
+
+All the best, Martin
+
+I did not yet have time to think about the following, hence no comment...
+> > > ---------------
+> > > Bug Report 9218:
+> > >
+> > > I believe the CombinatorialFunctions package is not meant to do what may
+> > > be called indefinite summation, only definite summations (hence the name
+> > > %defsum).
+> >
+> > I don't understand the relation of this to my bug report. Sorry.
+> >
+> > > Note that the result from
+> > >
+> > > eval(D(f(x),x),f,y+->sum(g(i,y),i=a..y))
+> > >
+> > > %defsum (g(%A,%%01),%A,i,a,x)
+> > >
+> > > comes from dvdsum again and is consistent with the formula I gave above,
+> > > except that I would not expect %%01 but rather just x.
+> >
+>
+> What I meant was that from the trace of the code, Bronstein wants to
+> leave a summation unevaluated if either of the summation limit is
+> "indefinite" (in his code, this means not an integer). I am not sure
+> under what condition he intended dvdsum to be invoked, but as you
+> pointed out, the formula encoded in dvdsum can only be true under
+> certain conditions. Now it seems that every time a summation cannot be
+> evaluated, dvdsum is called, giving wrong results in the cases we tried.
+> The eval example above is mathematically equivalent (at least I think
+> that was your intention because f is just an unknown operator) to
+>
+> D(sum(g(i,x),i=a..x),x) which gives
+>
+> summation (displayed) from i=a to x of the partial with respect to the
+> second argument of g at (i,x) plus g(x,x), which is following the
+> formula in dvdsum because the lower limit is independent of x. Normally,
+> eval is not executed until all its arguments are evaluated first. Now
+> Bronstein implements diffEval in fspace.spad, so eval probably should
+> not perform a substitution differentially (replacing f and
+> differentiate). It should not have succeeded in any substitution since f
+> no longer "appear" in f'(x) --- at least that is the case in Mathematica
+> or Maple. In Axiom, it seems the substitution is still made. So the
+> answer should be the same as above, with two terms: a summation and
+> g(x,x).
+>
+> > The %%01 is the dummy variable used for differentiation (see line 625 of
+> > fspace.spad).
+>
+> Are you suggesting that
+>
+> %defsum (g(%A,%%01),%A,i,a,x)
+>
+> means sum from i=a to x the partial of g with respect the second variable
+> evaluated at (i,x)? What happened to g(x,x)? This is not consistent with:
+>
+> eval(D(f(x),x),f,y+->sum(g(i+y),i=a..y))
+>
+> which gives
+>
+> %defsum (g(%A+%%01),%A,i,a,x)
+>
+> All this is garbage-in garbage-out because such operations were probably
+> not intended. But this is only a conjecture (that is what archeologists
+> do). We can follow the code, but it does not make sense to me.
+>
+> William
+> ------
+> Proposed fix for (1) (tested for NAG version) with the following inputs:
+>
+> product(summation(i*j), i=a..b), j=c..d)
+>
+> and similar variations. However, I have NOT tested whether this will affect
+> other computations! (It should not, but who knows?)
+>
+> Patch for combfunc.spad:
+>
+> Step 1. Delete line
+> dummy := new()$SE::F
+>
+> Step 2. Replace the definition of product, summation by:
+>
+> product(x:F, i:SE) ==
+> -- opprod [eval(x, k := kernel(i)$K, dummy), dummy, k::F]
+> ++ opprod [eval(x, k := kernel(i)$K, h:=new()$SE::F), h, k::F]
+>
+> summation(x:F, i:SE) ==
+> -- opsum [eval(x, k := kernel(i)$K, dummy), dummy, k::F]
+> ++ opsum [eval(x, k := kernel(i)$K, h:=new()$SE::F), h, k::F]
+>
+> product(x:F, s:SegmentBinding F) ==
+> k := kernel(variable s)$K
+> -- opdprod [eval(x, k, dummy), dummy, k::F, lo segment s, hi segment s]
+> ++ opprod [eval(x, k, h:=new()$SE::F), h, k::F, lo segment s, hi segment s]]
+>
+> summation(x:F, s:SegmentBinding F) ==
+> k := kernel(variable s)$K
+> -- opdsum [eval(x, k, dummy), dummy, k::F, lo segment s, hi segment s]
+> ++ opdsum [eval(x, k, h:=new()$SE::F), h, k::F, lo segment s, hi segment s]]
+
+\start
+Date: 11 Jun 2004 09:57:41 -0400
+From: Camm Maguire
+To: "m.rubey"
+Subject: Re: [Axiom-developer] Re: Patches
+Cc: "Bronstein, Manuel"
+
+Greetings!
+
+"m.rubey" writes:
+
+> On Wed, 9 Jun 2004, William Sit wrote:
+>
+> > 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
+> >
+> > Note this was because before I clear all, I had defined %B and did a
+> > New()$SYMBOL that gives %C.
+> >
+> > (3) -> G1419::SYMBOL
+> > G1419
+> >
+> > (4) -> symbol(GENSYM()$Lisp)
+> > G84337
+> >
+> > All output are of type Symbol.
+>
+> In fact, I was hoping that the NAG version would do this. I suspect this
+> is a GCL issue. I will send Camm Maguire a message.
+>
+
+Please excuse me, I'm a bit late to this thread. If you suspect a GCL
+error here, and preferably can boil it down to a simple lisp example,
+I'd be happy to take a look.
+
+\start
+Date: Fri, 11 Jun 2004 11:25:38 -0400
+From: William Sit
+To: "m.rubey"
+Subject: Re: [Axiom-developer] Bugs in combfunc.spad and partial patch
+
+"m.rubey" wrote:
+
+> On the other hand, I like your patch better, since it is more in line with
+> the rest of axiom code...
+
+True, however, personally, I program in your style (that is, define the
+variables on separate lines). The reason is, one should not rely on the order in
+which arguments of a function is to be evaluated, because sometime in the
+future, the packages may be recompiled for parallel machines, and there is a
+chance that the arguments may be evaluated in parallel. Also, the "Bronstein
+style" of inline definition makes the lines longer and harder to read. So he
+used inline only when the line still "fits".
+
+\start
+Date: Fri, 11 Jun 2004 12:15:57 -0400
+From: root
+To: wyscc@cunyvm.cuny.edu, rubey@geometrie.tuwien.ac.at, camm@enhanced.com
+Subject: Re: [Axiom-developer] Bugs in combfunc.spad and partial patch
+
+re: the patch.
+
+I remember that we had a similar problem with symbols that turned out
+to be a problem in the underlying lisp. As soon as I can get this
+ISSAC CD (deadline today) and one other task out of the way I'll look
+into it further.
+
+\start
+Date: Fri, 11 Jun 2004 20:29:09 +0200
+From: David MENTRE
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] [crystal] Vital: an example of interactive computational environment
+
+Hello,
+
+In the context of the Crystal, zero learning curve editor and similar
+interactive environment, here is a pointer on Vital, an interactive
+environment for the Haskell language:
+
+http://www.cs.kent.ac.uk/projects/vital/overview/index.html
+
+Vital represents results as both textual and graphical forms, allowing
+direct user drag and drop. It saves the session result as a standard
+Haskell program with graphical layout as comments.
+
+It might give few ideas for the Crystal editor of the next 30 years. ;)
+
+\start
+Date: Fri, 11 Jun 2004 15:53:19 -0400
+From: root
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] algebras <=> groups
+
+Axiom arranges algebras based on categorical properties such as
+associative, commutative, has one or multiple zeros, etc. The
+same is true, it appears, in group theory.
+
+It appears to me that there must be a group associated with every
+algebra with an isomorphism (the group rules have exact analogs
+in the algebra rules, the group elements have exact analogs in
+the algebra and vice-versa).
+
+(a) Is this true?
+(b) Can you point me at a reference that details this?
+
+If we were to do group theory in Axiom it would be unbelievably
+sweet to arrange the group category structure side by side with
+the algebra category structure.
+
+That would allow the "lifting" trick (e.g. solving a matrix problem
+by mapping each matrix to the group element, using a group theorem,
+and then mapping back to the answer or vice-versa). It would also
+immediately give us algorithmic power to answer group questions in
+the algebra (e.g. showing a word is the identity by mapping it to
+matrices, combining the results, and mapping back the identity
+matrix).
+
+This identification of group theory with algebra would also solve
+the problem I've been pestering you about (of the categorical ordering
+of groups based on properties).
+
+\start
+Date: Fri, 11 Jun 2004 16:52:08 -0400
+From: root
+To: wyscc@cunyvm.cuny.edu
+Subject: Re: [Axiom-developer] algebras <=> groups
+Cc: gilbert@sci.ccny.cuny.edu
+
+Bill,
+
+The thought was triggered by this quote:
+
+ Groups and algebras have this in common, that they each employ a process
+ of multiplication that is associative but not necessarily commutative.
+ The problem that immediately suggests itself, then, is to examine the
+ connection between the two theories. This connection is quite intimate,
+ for connected with every finite group there is an associated algebra
+ called the group algebra. It is sometimes called after Frobenius, who
+ published a number of papers exploring this problem, the Frobenius
+ algebra of the group.
+
+Littlewood, D.E. "The Skeleton Key of Mathematics" p107
+
+\start
+Date: Fri, 11 Jun 2004 20:44:13 +0200 (CEST)
+From: Bertfried Fauser
+To: root
+Subject: Re: [Axiom-developer] algebras <=> groups
+
+On Fri, 11 Jun 2004, root wrote:
+
+Dear Tim,
+
+> Axiom arranges algebras based on categorical properties such as
+> associative, commutative, has one or multiple zeros, etc. The
+> same is true, it appears, in group theory.
+>
+> It appears to me that there must be a group associated with every
+> algebra with an isomorphism (the group rules have exact analogs
+> in the algebra rules, the group elements have exact analogs in
+> the algebra and vice-versa).
+>
+> (a) Is this true?
+No,
+> (b) Can you point me at a reference that details this?
+Hence no pointer.
+
+A group has the following AXIOMS:
+
+0) G is a set with a selfaction GxG -> G on it
+i) this action is associative Gx (GxG) = (GxG) xG
+ii) existence of a unit e, e xG =G = Gx e elementwise
+iii) existence of a unique inverse ()^-1 : G -> G such that
+ h x g = e and one calles h = g^(-1)
+
+
+An algebra is build over a module (vector space)
+
+A vectorspace is an abelian group of elements called vectors enriched by
+the action of the scalars from R the vectors are build over. This abelian
+group models the addition of an algebra. As a module the vector space is
+identified with the algebra and denoted say A.
+
+The multiplication of an algebra is a (possibly non associative) map
+m : A x A -> A, so that this map is R-linear in both arguments
+(Compatibility with teh addition, This definition is found (including the
+nonassociativity, in the A1 Extension theory of Hermann Grassmann,
+though he has not yet a word for the structure). In general an algebra
+multiplication is not a group, since
+i) m may be nonassociative -> no group analog, see theory of "loops"
+ii) m may not have a unit at all, hence inverses cannot be defined
+iiI) In almost all interesting cases A has not inverses for _any_ element
+in A (check for a/the zero!)
+
+The subset of lements which are multiplicatively invertible called the
+group of units. R*=R\{0} as set. But zero is the unit element of the
+additively writen group of addition and cannot be neglected.
+
+Hence while a group has a unique and very well behaved connectivity, an
+algebra has a much more interesting multiplication. Nevertheless, your
+feeling that group and algebra structures are quite close together is not
+so wrong. A categorial explanation how addition and multiplication are
+connected (and are connected with the recursion, natural numbers, and
+proof by induction) can be found in the recent Book of Lawvere/Rosenbrugh,
+Sets for mathematics, Cambridge Univ Press, 2003.
+
+> If we were to do group theory in Axiom it would be unbelievably
+> sweet to arrange the group category structure side by side with
+> the algebra category structure.
+>
+> That would allow the "lifting" trick
+
+There is such a trick, as described in the book cited. Lets assume you
+have a sucessor map suc which will be iterated to yield addition
+
+ suc : x <- x+1
+ add : x <- (suc^n)(x)
+
+The multiplication can be understood as teh iteration of addition though
+
+ mul : x <- (add^m)(n,x=0)
+
+evaluated at zero. Here fun^n does mean fun(fun(fun(...)...), n-times.
+
+This to implement in general would be marvelous, I am currently thinking
+of vast generalizations of these structures, but doing symbolic algebra
+with these structurs is bejond my ability.
+
+\start
+Date: Fri, 11 Jun 2004 17:37:19 -0400
+From: William Sit
+To: "m.rubey"