\start
Date: Tue, 1 Jun 2004 07:22:57 -0400
From: Tim Daly
To: Bill Page
Subject: Re: learning in public

Bill,

Email should be fixed now.

\start
Date: Tue, 1 Jun 2004 07:36:02 -0400
From: Tim Daly
To: list
Subject: 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: Bill Page
To: Tim Daly
Subject: RE: learning in public

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.

> Bill,
> 
> Email should be fixed now.

\start
Date: Tue, 1 Jun 2004 10:21:34 -0400
From: Tim Daly
To: Bill Page
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 12:47:51 -0400 
From: Bill Page
To: Tim Daly
Subject: website <-> latex

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.

> 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: Bill Page
Subject: Re: website <-> latex

Page, Bill [Bill Page] 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: Bill Page
Subject: 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: Bill Page
To: Bertfried Fauser
Subject: Mozilla FireFox

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: Tim Daly
To: Bertfried Fauser
Subject: re: learning in public
Cc: Bill Page

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: Bill Page
To: Bertfried Fauser
Subject: re: learning in public

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
To: Bill Page
Subject: Re: 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: Bill Page
Subject: 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
Subject: Re: website <-> latex
Cc: Bill Page

>  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: Michel Lavaud
Subject: RE: website <-> latex

On Wednesday, June 02, 2004 6:27 AM 
Michel Lavaud 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: list
Subject: 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: Michel Lavaud
Subject: RE: website <-> latex

On Thursday, June 03, 2004 4:04 AM Michel Lavaud
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: Michel Lavaud
Subject: 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: Martin Rubey
To: list
Subject: (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: list
Subject: Playing with Axiom

--3MwIy2ne0vdjdPXF

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: Martin Rubey
To: Bob McElrath
Subject: Re: 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: Tim Daly
To: Martin Rubey
Subject: Re: Playing with Axiom
Cc: Bob McElrath

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: Tim Daly
To: Bob McElrath
Subject: Re: 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: Tim Daly
Subject: Re: Playing with Axiom

Tim Daly 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: Tim Daly
To: Bill Page
Subject: plone/python/axiom

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: Tim Daly
To: list
Subject: 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: Tim Daly
Subject: 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: Mark Pleszkoch
Subject: 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 mentre

savannah-hackers@gnu.org writes:

> User Full Name:   Mark Pleszkoch
> User Name:   mpleszko
> User Email:   Mark Pleszkoch
>
> 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 Maguire
Subject: debian layout

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 Maguire
Subject: 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: list
Subject: Re: OpenMath
Cc: Mike Dewar, Alenka Zajka

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: OpenMath
Cc: Alenka Zajka

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: OpenMath
Cc: Alenka Zajka

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: debian layout
Cc: Frederic Lehobey, David Mentre

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: Mike Dewar
Subject: Re: OpenMath
Cc: Alenka Zajka

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 Maguire
Subject: Re: debian layout
Cc: Frederic Lehobey, David Mentre

>  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: Mike Dewar
Subject: Re: OpenMath
Cc: Alenka Zajka

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: Tim Daly
Subject: 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: OpenMath
Cc: Alenka Zajka

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: debian layout
Cc: Camm Maguire, Frederic Lehobey, David Mentre

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
Subject: Re: debian layout
Cc: Camm Maguire, Frederic Lehobey, David Mentre

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: debian layout
Cc: Frederic Lehobey, David Mentre

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 Maguire
Subject: Re: debian layout
Cc: Frederic Lehobey, David Mentre

>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: debian layout
Cc: Frederic Lehobey, David Mentre

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 <v6kk1hg02@sneakemail.com>
To: list
Subject: 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: Frederic Lehobey
To: Camm Maguire
Subject: Re: debian layout
Cc: David Mentre

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: Tim Daly
To: Frederic Lehobey
Subject: Re: debian layout
Cc: Camm Maguire, David Mentre

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: list
Subject: 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=#<compiled-function
system:universal-error-handler>,loc1=:error
,loc2=nil,l...} [ihs ]
#1   APPLY {loc0=#<compiled-function
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=#<compiled-function
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=#<compiled-function system:top-level>} [ihs=4]
NIL
BOOT>>

\start
Date: Tue, 8 Jun 2004 16:51:30 +1000
From: Mike Thomas
To: Mike Thomas
Subject: RE: Axiom on Windows
Cc: Camm Maguire, Bill Page

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: Bill Page
To: Bertfried Fauser
Subject: RE: learning in public
Cc: Bill Page

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: Bill Page
To: Mike Thomas
Subject: 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.

> 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: Tim Daly
To: Mike Thomas
Subject: re: Axiom on Windows
Cc: Bill Page, Camm Maguire

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: list
Subject: 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: Bill Page
Subject: 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<j. Then one can generalize. However, one has to deal with
the effects with the linear ordering of teh bases (grade one space), this
is quite a peculiar and problemetic thing to do!

>   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: Tim Daly
Subject: 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: Tim Daly
To: Mike Thomas
Subject: Re: Axiom on Windows
Cc: Bill Page, Camm Maguire

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: Tim Daly
Subject: Re: debian layout
Cc: Frederic Lehobey, David Mentre

Greetings!

Tim Daly 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 Maguire
Subject: Re: debian layout
Cc: Frederic Lehobey, David Mentre

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: Serge D. Mechveliani
Subject: 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 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 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: 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=#<compiled-function
> system:universal-error-handler>,loc1=:error
> ,loc2=nil,l...} [ihs ]
> #1   APPLY {loc0=#<compiled-function
> 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=#<compiled-function
> 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=#<compiled-function system:top-level>} [ihs=4]
> NIL
> BOOT>>

\start
Date: 08 Jun 2004 15:55:12 -0400
From: Camm Maguire
To: Mike Thomas
Subject: 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 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: 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
Subject: Software Archaeology

Hi Tim:
         
I came across the email by 

Patches (?) for sum/product and sqrt
Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
From: Martin Rubey
To: list

(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: Bill Page
Subject: RE: [Gcl-devel] RE: Axiom on Windows
Cc: Camm Maguire

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: Tim Daly
Subject: 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 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: Bill Page
Subject: RE: [Gcl-devel] RE: Axiom on Windows

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 <noweb.src.Makefile.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.
> <<Makefile.windows>>> # 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
>
> <<rootdirs>>
> <<noweb.windows>>
> <<literate commands>>
> <<srcsetup>>
> <<src>>
> <<lsp>>
> <<document>>
> <<clean>>
>
> @
>
>
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
Subject: RE: learning in public
Cc: Bill Page

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<j. Then one can generalize. However, one has to deal with
> 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: Martin Rubey
To: William Sit
Subject: Re: 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: 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=#<compiled-function
system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=32]
#1   APPLY {loc0=#<compiled-function
system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=31]
#2   LAMBDA {} [ihs=28]
#3   pushSatOutput
{loc0=|line|,loc1=#<OBJNULL>,loc2=#<OBJNULL>,loc3=#<OBJNULL>,loc4=#<OBJNULL>
,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=#<compiled-function
make-databases>} [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=#<compiled-function system:top-level>} [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: Tim Daly
To: Martin Rubey
Subject: Re: 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: Martin Rubey
To: Tim Daly
Subject: Re: 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: Tim Daly
To: Martin Rubey
Subject: Re: 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: list
Subject: 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: Martin Rubey
To: Tim Daly
Subject: Re: 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: Tim Daly
To: Martin Rubey
Subject: Re: 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: Tim Daly
To: Serge D. Mechveliani
Subject: Re: 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: Tim Daly
To: list
Subject: 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: output format 

Serge D. Mechveliani <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
> Serge D. Mechveliani

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: Martin Rubey
Subject: Patches
Cc: Manuel Bronstein

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
Subject: unparse

cool. I didn't know unparse existed. --t


\start
Date: Wed, 9 Jun 2004 16:27:49 +0200 (CEST)
From: Martin Rubey
To: William Sit
Subject: Re: Patches
Cc: Manuel Bronstein

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: Tim Daly
Subject: Re: Software Archaeology/Patches

Tim Daly 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: Tim Daly
To: Alenka Zajka
Subject: 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 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: Martin Rubey
Subject: Bugs in combfunc.spad and partial patch
Cc: Manuel Bronstein

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: Martin Rubey, Manuel Bronstein
Subject: Re: 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: Patches (?) for sum/product and sqrt
Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
From: Martin Rubey
To: list
...
---------
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 Page
Subject: 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 <research@ijs.co.nz>
Subject: Can't subscribe to mailing list; ideas on algebra of tainted
  points
Cc: Bertfried Fauser <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<x*x)".

- --

I just uploaded my project to tope.tigris.org.

- --

I mention this for Mr Fauser who might have missed this when reviewing
all existing systems. Notes:

(1) The offline "Bear" Dirac algebra program of Tkachov and for (CERN, etc.)
physicists:
   http://www.inr.ac.ru/~ftkachov/projects/bear/dirac.htm
 
(2) On teaching Russia (i.e. their physics students) to prefer the
fast failing Oberon language (actually the narrowly free Blackbox
GUI compiler, it seemed):
   http://www.inr.ac.ru/~info21/info/fvtjmlc2003.htm
------- End of forwarded message -------

\start
Date: Thu, 10 Jun 2004 06:50:00 -0400
From: Tim Daly
To: Craig Carey
Subject: 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: Tim Daly, Serge D. Mechveliani
Subject: Re: 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

--- Tim Daly 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: Tim Daly
To: Clifton Williamson
Subject: Re: output format
Cc: Serge D. Mechveliani

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: learning in public
Cc: Bill Page, Bertfried Fauser

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: Martin Rubey
To: William Sit
Subject: Re: 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: Patches (?) for sum/product and sqrt
> Date: Tue, 25 May 2004 14:21:38 +0200 (CEST)
> From: Martin Rubey
> To: list
> ...
> ---------
> 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: Martin Rubey
To: William Sit
Subject: Re: Bugs in combfunc.spad and partial patch
Cc: Manuel Bronstein

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: Martin Rubey
Subject: re: Patches
Cc: Manuel Bronstein

Greetings!

Martin 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: Martin Rubey
Subject: Re: 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: Tim Daly
To: William Sit, Martin Rubey, Camm Maguire
Subject: Re: 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: list
Subject: [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: Tim Daly
To: list
Subject: 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: Tim Daly
To: William Sit
Subject: Re: algebras <=> groups
Cc: Gilbert Baumslag

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: Tim Daly
Subject: Re: 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: Martin Rubey
Subject: Re: Bugs in combfunc.spad and partial patch
Cc: Manuel Bronstein

Hi Martin:

You raised many issues. I am separating this reply into sections with dividing
lines, to make it look better. I think I found how to fix dvdsum.

--------------------------- Use of new()$Symbol in fspace.spad ---------------

"m.rubey" wrote:
> 
> 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.

I take this back after studying fspace.spad more. There the %%0i symbols are not
used as dummy variables in loops. gendiff (%%0) is used to generate a list of
new symbols that are needed and Bronstein generates them as %%0i where i can be
from 1 to n using symsub to concatenate gendiff with i. Whether the list of new
symbols need to be "of the same family" (in the sense of say arbitrary constants
C_1, ..., C_n) or not, I don't know. But they way it is, there should not be any
bug.

--------------------------- Display with parenthesis in OutputForm -----------
--------------------------- local patch in combfunc.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)
> 
> I noticed this to. Bug report on the way

The fix is not as easy as it seems. It is not clear whether the "bug" should be
fixed locally in combfunc.spad (a simple, temporary, but unsatisfactory fix is
to modify ddprod and ddsum with paren(...)) with limited effect, or globally in
OutputForm (outform.spad), where the bug was perhaps recognized:

    -- Todo:
    ...
    -- bug in product, paren blankSeparate []

The temperary fix is unsatisfactory because we should not SIMPLY add parenthesis
to EVERY summation or product.  This is a general problem and requires an
examination of the context to decide whether the parenthesis is necessary and
that may be subjective. (I find controlling the output in Mathematica equally
difficult, but generally, Mathematica did a much better job -- except in cases I
don't like :-). Since OutputForm is built bottom up (the responsibility of each
domain via coerce), it may be difficult to make the decision even if it can be
done objectively.

So may be when you report the bug, you can supply the temporary patch? Thanks.

---------
Temporary local patch in combfunc.spad:

  ddprod(l, x) ==
--  prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)
++  paren(prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O))

  ddsum(l, x) ==
--  sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)
++  paren(sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O))

--------------------------- Patch for dvdsum in combfunc.spad ---------------
> 
> > (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!

The meaning of differenting a sum with variable bounds can be understood this
way, by treating the RESULT as a function of the variable. For example, assuming
x takes integer values, 

  x +-> sum(f(i,x), i=x^2..x^3)

defines a function of x as f(x^2,x)+ f((x^2+1),x) + ... + f(x^3,x)
whose domain can be generalized to the real numbers or even complex numbers.
Then we may ask what is its derivative and we can actually write it down with a
summation. More generally, we want to compute

  D(sum(f(i,x),i=a(x)..b(x)),x)

which should give

  sum(D(f(a(x) + i,x),x), i=0..(b(x) - a(x)))

So if you accept this interpretation, here is my new dvdsum (which evaluates in
all cases!) Note: before calling dvdsum, the system already checks that the
lower and upper limits are functions of x, so no checking is needed here.

  dvdsum(l,x)==
    x = retract(y := third l)@SE => 0
    k := retract(d := second l)@K
    f := first l
    g := third rest l
    h := third rest rest l
    opdsum [differentiate(eval(f,k,g+d),x),d,y,0,h-g]

Test this:

  f := operator 'f
  D(sum(f(i,x), i=a..b),x)

I tried other differentiation and they seem fine.

  D(sum(x^i, i=0..n),x)
  D(sum(f(i,x), i=x^2..x^3)
  D(sum(x/i, i=x^2..x^3)

The patch leaves the summation unevaluated if it cannot be done (this is
automatic due to Bronstein's original implementation).

------------------------- Other forms of summation results ---------------------
> 
> 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...

Sure, but what you are doing is having two functions with domain the real
numbers (say) having the same restriction on integers. As long as you are using
integer inputs, they are the same. When you start differentiating, you CHOOSE a
generalization (there are many, and there may or may not be a canonical one)
that enlarges the domain. These two generalisations are different functions (of
the continuous variable n) even though they coincide on integers. You may
arbitrarily interpolate any function for non-integral inputs. Their derivatives
don't have to coincide for integer values of n (or even differentiable at
integer values, but in your example, they are and do agree, but only for
integers).

Also, equality (not just for functions) is a messy business.

---------------------- Mathematica's handling of Summation -------------------

> 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...)

This is true only if in 

  Sum[f[i,x], {i,a[x],b[x]}]

all the functions f, a, b are undefined. In many cases, Mathematica gives
results
that Axiom (with the patch above) cannot sum. For example, 
Mathematica even gives a result when f[i,x] = x/i in terms of polygamma
functions. Unfortunately, I cannot verify the result using integration. However,
I tried other simpler cases when a[x] and b[x] are known, and results are given
(Axiom can do those too), like Sum[i^2 x, {i,x^2, x^3}].

--------------------Discussion on Expression Constructor -------------------
-------------------- related: Segment, SegmentBinding ----------------------

> 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?

Good question. I am not sure about the answer. But here is my guess.
If we are to use EXPR R for the purpose of summation, then we need EXPR R to be
ordered so we can have segments. Even though construction of a segment does NOT
need an ordered set (so Segment PF 5 is perfectly legal), the real need is the
function expand from Segment(S), which requires S to be an OrderedRing (now in
Axiom, OrderedRing simply means the domain belongs to the category of Ring and
of OrderSet -- the order has nothing to do with the ring structure otherwise; so
since R is already a Ring in most cases, EXPR only need OrderedSet).  I believe
that is the origin. 

> 
> * 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?

I don't understand. Sure, I typed EXPR POLY INT and it is perfectly ok. Even
EXPR FRAC POLY INT, EXPR FRAC INT.

> * How can I adapt EXPR so that I can have sums of POLY PF 5?

The question is, why isn't PF 5 an OrderedSet? The answer is: it is cylcic, so
one would have 0 < 1 < 2 < 3 < 4 < 5 = 0. FiniteField does have some rudimentary
ordering based on SegmentBinding and StepThrough:

s:SegmentBinding PF 5:= i=1..5

SegmentBinding, like Segment, does NOT require an ordered set and logically it
may even seem that for the purpose of summation, one only needs to be able to
"StepThrough" the segment with a "nextItem" function (all these ARE available,
even for PF) But unfortunately, it is not even possible to expand a segment into
a list for PF 5 because expand requires OrderedSet. 

  t:Segment PF 5:=1..3
  [i for i in t]

because the built-in "for" only allows segments of integer values for the
iterator i (it will step through with any list though, including List PF 5).

So you may have to create something like OrderedPrimeField where the order
function is explicitly given as say, for p = 5: 0 < 1 < 2 < 3 < 4


> 
> 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 ...

If you are working with polynomials, then the 3 in x^3 should be a NNI, not
integer, and certainly not PF 3, even if the coefficients are from PF 3. It
makes perfectly good sense to compute 2^3 = 8 = 2 (mod 3). Currently, it is not
possible to compute exponents mod 3 because the PolynomialCategory only allows
OrderedAbelianMonoidSup domains as exponents and PF 3 is not ordered.

> 
> * 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...

That Something unfortunately needs to be an ordered set in order to expand
SEGBIND D1.

---------------------------- Documentation on box in combfunc.spad ----------
> 
> > > > ----------------
> > > > 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))  (corrected typo from previous message)
> > > >
> > > > 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!

I think the confusion was because the current description (see fspace.spad)
says:

box(f) returns f with a 'box' around it that prevents f from being evaluated
when operators are applied to it.

should have been

box(f) returns f with a 'box' around it that prevents the evaluation of an
operator when the operator is applied to f.

and similarly when box is applied to a list of arguments. However, box is
designed for operators (which are unexported and unary) and so it is difficult
in the interpreter to apply box to functions like sum that takes two arguments
(instead of a list to two elements). 
You certainly have my permission to adapt the above to the pamphlet.

\start
Date: Fri, 11 Jun 2004 19:42:56 -0400
From: William Sit
To: list
Subject: [Fwd: Re: Bugs in combfunc.spad and partial patch]

M. Rubey wrote:

> 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?

Actually, I think PolynomialCategory(PF 3, DIRPROD(2, PF 3), OVAR [x, y])
does not make mathematical sense, even if PF 3 were made into an OrderedSet.
In any domain belong to this supposed category, one would have

x * x^2 = x^3 = x^0 = 1

but x * x * x = x for any x in PF 3, so this contradiction means the laws of
exponents cannot hold in such a domain.

\start
Date: Sun, 13 Jun 2004 18:40:24 -0700 (PDT)
From: Mark Pleszkoch
To: list
Subject: Re: New user registration

David,

Thanks for the welcome.  I hope to get moving on this
towards the end of this month.  I will be trying to
install AXIOM on Windows, as that is the platform I
will need to work on for my SEI project.  I'm thinking
that cygwin is probably the best way to go.  Does
anyone have any experience with AXIOM under cygwin?

\start
Date: Sun, 13 Jun 2004 22:33:43 -0400
From: Tim Daly
To: Mark Pleszkoch
Subject: Re: New user registration

Mark,

I believe Bill Page has done some work in this direction.
He recommends mingw rather than cygwin.

\start
Date: Mon, 14 Jun 2004 10:33:59 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: output format
Cc: Serge D. Mechveliani

Actually, if you want a linear representation then you could try
)set output fortran on
however you will probably want to tweak the settings for Fortran
generation to turn off coercions of integers to floats and expression
segmentation.  Do
)set fortran
for more details.

Mike.

On Wed, Jun 09, 2004 at 08:44:41AM -0400, Tim Daly 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: Mon, 14 Jun 2004 20:00:41 +1000
From: Jason White
To: list
Subject: Re: output format

Mike Dewar writes:
 > Actually, if you want a linear representation then you could try
 > )set output fortran on

)set output tex on
is another alternative.

Even better would be an option to make the output format the same as
the input format. For me, this would be more readable than TeX or
Fortran, using a braille output device or synthetic speech. I don't
know whether such a mode would have any other applications or whether
there would be much interest in implementing it.

\start
Date: Mon, 14 Jun 2004 10:55:11 -0400
From: William Sit
To: Martin Rubey, Manuel Bronstein
Subject: Re: Bugs in combfunc.spad and partial patch

The patch supplied below by me would not work in all cases, as pointed out by
Martin that

  D(sum(f(i),i=0..x),x) 

would give a wrong answer. Worse, I believe now the interpretation is wrong as
well (at least in certain cases). So sorry. 

William
----------

William Sit wrote:

> --------------------------- Patch for dvdsum in combfunc.spad ---------------
 
> The meaning of differenting a sum with variable bounds can be understood this
> way, by treating the RESULT as a function of the variable. For example, assuming
> x takes integer values,
> 
>   x +-> sum(f(i,x), i=x^2..x^3)
> 
> defines a function of x as f(x^2,x)+ f((x^2+1),x) + ... + f(x^3,x)
> whose domain can be generalized to the real numbers or even complex numbers.
> Then we may ask what is its derivative and we can actually write it down with a
> summation. More generally, we want to compute
> 
>   D(sum(f(i,x),i=a(x)..b(x)),x)
> 
> which should give
> 
>   sum(D(f(a(x) + i,x),x), i=0..(b(x) - a(x)))
> 
> So if you accept this interpretation, here is my new dvdsum (which evaluates in
> all cases!) Note: before calling dvdsum, the system already checks that the
> lower and upper limits are functions of x, so no checking is needed here.
> 
>   dvdsum(l,x)==
>     x = retract(y := third l)@SE => 0
>     k := retract(d := second l)@K
>     f := first l
>     g := third rest l
>     h := third rest rest l
>     opdsum [differentiate(eval(f,k,g+d),x),d,y,0,h-g]
> 
> Test this:
> 
>   f := operator 'f
>   D(sum(f(i,x), i=a..b),x)
> 
> I tried other differentiation and they seem fine.
> 
>   D(sum(x^i, i=0..n),x)
>   D(sum(f(i,x), i=x^2..x^3)
>   D(sum(x/i, i=x^2..x^3)
> 
> The patch leaves the summation unevaluated if it cannot be done (this is
> automatic due to Bronstein's original implementation).

\start
Date: Mon, 14 Jun 2004 11:24:47 -0400
From: William Sit
To: Martin Rubey, Manuel Bronstein
Subject: Re: Bugs in combfunc.spad and partial patch

The interpretation for the sum is ok, but since x is not fixed, it cannot be
differentiated termwise (again, Martin pointed this out, but I was not paying
attention) because the sum does not have a constant number of terms.

William

> William Sit wrote:
> 
> > --------------------------- Patch for dvdsum in combfunc.spad ---------------
> 
> > The meaning of differenting a sum with variable bounds can be understood this
> > way, by treating the RESULT as a function of the variable. For example, assuming
> > x takes integer values,
> >
> >   x +-> sum(f(i,x), i=x^2..x^3)
> >
> > defines a function of x as f(x^2,x)+ f((x^2+1),x) + ... + f(x^3,x)
> > whose domain can be generalized to the real numbers or even complex numbers.
> > Then we may ask what is its derivative and we can actually write it down with a
> > summation. More generally, we want to compute
> >
> >   D(sum(f(i,x),i=a(x)..b(x)),x)
> >
> > which should give
> >
> >   sum(D(f(a(x) + i,x),x), i=0..(b(x) - a(x)))
> >
> > So if you accept this interpretation, here is my new dvdsum (which evaluates in
> > all cases!) Note: before calling dvdsum, the system already checks that the
> > lower and upper limits are functions of x, so no checking is needed here.
> >
> >   dvdsum(l,x)==
> >     x = retract(y := third l)@SE => 0
> >     k := retract(d := second l)@K
> >     f := first l
> >     g := third rest l
> >     h := third rest rest l
> >     opdsum [differentiate(eval(f,k,g+d),x),d,y,0,h-g]
> >
> > Test this:
> >
> >   f := operator 'f
> >   D(sum(f(i,x), i=a..b),x)
> >
> > I tried other differentiation and they seem fine.
> >
> >   D(sum(x^i, i=0..n),x)
> >   D(sum(f(i,x), i=x^2..x^3)
> >   D(sum(x/i, i=x^2..x^3)
> >
> > The patch leaves the summation unevaluated if it cannot be done (this is
> > automatic due to Bronstein's original implementation).

\start
Date: Mon, 14 Jun 2004 19:17:09 +0200
From: David Mentre
To: Mark Pleszkoch
Subject: Re: New user registration

Hello Mark,

Mark Pleszkoch writes:

> towards the end of this month.  I will be trying to
> install AXIOM on Windows, as that is the platform I
> will need to work on for my SEI project.  I'm thinking
> that cygwin is probably the best way to go.  Does
> anyone have any experience with AXIOM under cygwin?

Look at the axiom-developer mailing list archives. Mike has made a lot
of progress on this front recently. But apparently it is not for the
average hacker. :)

\start
Date: 14 Jun 2004 13:38:48 -0400
From: Camm Maguire
To: Mark Pleszkoch
Subject: Re: New user registration

Greetings!  mingw is the primary windows porting effort, and will
remain so for the foreseeable future.  Recently, a gcl user has been
working to get a cygwin build, which should not be too difficult.  If
you choose to go this route, please look at the thread on
gcl-devel@gnu.org -- we will happily assist you in your efforts (in
either case.

Take care,

Mark Pleszkoch writes:

> David,
> 
> Thanks for the welcome.  I hope to get moving on this
> towards the end of this month.  I will be trying to
> install AXIOM on Windows, as that is the platform I
> will need to work on for my SEI project.  I'm thinking
> that cygwin is probably the best way to go.  Does
> anyone have any experience with AXIOM under cygwin?

\start
Date: 14 Jun 2004 14:06:26 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: algebras <=> groups
Cc: Gilbert Baumslag

Greetings!  Bertfried already said it -- groups and algebras have an
intuitive connection through identifications of their multiplications,
but neither set is strictly contained within the other along this line
-- i.e. a famous non-associative algebra is the octonions, whereas a
group need not have a secondary combination rule which is not simply
an iteration of its multiplication (as is the case with matrix algebra
addition and multiplication).

This having been said, there are two enormous areas of practical
overlap:  

1) representation theory -- i.e. the categorization of the eigenspaces
   of an operator via its known multiplication rules with the elements
   of a 'symmetry' group

2) Lie groups, which are 'generated' by exponentiating the additive
   action of an (usually matrix vector) algebra.

It would be hard to overstate the significance of being able to
separate eigen solutions of a complex and intractable dynamic operator
from 'symmetry' arguments alone.

If one wishes to consider representation as opposed to group theory
per se, I believe the conditions for the existence of matrix algebra
representations of group over some vector space are quite broad,
perhaps even universal in the case of a finite group.

Take care,

Tim Daly writes:

> 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: Mon, 14 Jun 2004 20:00:30 +0200 (CEST)
From: Bertfried Fauser
To: Camm Maguire
Subject: Re: algebras <=> groups
Cc: Gilbert Baumslag

On 14 Jun 2004, Camm Maguire wrote:

Hi!

> This having been said, there are two enormous areas of practical
> overlap:
>
> 1) representation theory -- i.e. the categorization of the eigenspaces
>    of an operator via its known multiplication rules with the elements
>    of a 'symmetry' group
>
> 2) Lie groups, which are 'generated' by exponentiating the additive
>    action of an (usually matrix vector) algebra.
>
> It would be hard to overstate the significance of being able to
> separate eigen solutions of a complex and intractable dynamic operator
> from 'symmetry' arguments alone.

perhaps interesting in this sort of discussion is, that Hopf algebras
unite in some sense these two areas. In a Hopf algebra there are "group
like" elements functioning _exactly_ like a group and so called "primitive
elements" which resemble the algebraic side. However....

\start
Date: Mon, 14 Jun 2004 22:56:46 -0400
From: Tim Daly
To: list
Subject: bug report ... makeGraphImage

x:=[1,2,3,4,5,6,7,8,9]
y:=[1,2,3,4,5,6,7,8,9]
points:=[point[x.i,y,i]$Point(DoubleFloat)
graph:=makeGraphImage([points])

graph returns a symbol. to get a GraphImage you need to package call it:

graph:=makeGraphImage([points])$GRIMAGE

the makeGraphImage that returns a symbols should not be exposed.

\start
Date: Tue, 15 Jun 2004 12:33:23 +0000
From: Martin Rubey
To: William Sit
Subject: Re: EXPR POLY INT

Dear William,

William Sit writes:

 > So is this a bug? I am not sure, it may be good that the interpreter caught the
 > ambiguity and it may be bad that the compiler does not. The compiler actually
 > knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is
 > used, but we (human) will get all confused. Try:
 > 
 > )abb package TEST  Test
 > 
 > Test():Target==Implementation where
 >   EXPR ==> Expression
 >   POLY ==> Polynomial
 >   INT  ==> Integer
 >   Target ==> with
 >     f1: () -> EXPR POLY INT
 >     f2: () -> POLY INT
 >     f3: () -> EXPR POLY INT
 >     f4: () -> EXPR POLY INT
 >   Implementation ==> add
 >     a:=new()$Symbol
 >     b:=a ::EXPR POLY INT
 >     c:=a :: POLY INT
 >     f1()==b
 >     f2()==c
 >     f3()== (c*b)/b
 >     f4()== f3()/b
 > 
 > Note that if you check the signature of /, the compiler "knows" it is legally
 > used and the answer for f4() is c/b, not 1 (which should be the case
 > mathematically).
 
 Well, I get the fraction %A / %A. I'm not to sure whether the reason for this
 is, that axiom distinguishes the two %A's. I tried to find out why, however, I
 couldn't: in expr.spad, we have the definitions

  K   ==> Kernel %
  MP  ==> SparseMultivariatePolynomial(R, K)
  Rep := Fraction MP

  if R has IntegralDomain then
    x:% / y:%        == reduc(x /$Rep y, commonk(x, y))

and

    x:MP / y:MP == 
      reduc(x /$Rep y,commonk0(algkernels variables x,algkernels variables y))

When saying f4()$TEST, the former gets called (twice, once for f3 too): The
first time x is %A %A and y is %A and x /$Rep y gives %A / %A, the second time, 
x and y are both %A, and x /$Rep y gives %A / %A.

When I say a::EXPR INT/a, also the former gets called (once, of course),
x and y being a and x /$Rep y gives 1.

However, I was unable to find the definition which gets called for /$Rep. I
tried the definition in Fraction, and some others, to no avail...

\start
Date: Tue, 15 Jun 2004 08:52:57 -0400
From: Tim Daly
To: Martin Rubey
Subject: re: EXPR POLY INT

Martin, Bill,

I believe, but have not yet shown that, the problem is being caused by
the routine in the lisp layer.  I've been unable to get to this issue
yet due to my work schedule.

\start
Date: Tue, 15 Jun 2004 10:38:53 -0400
From: William Sit
To: Martin Rubey
Subject: Re: EXPR POLY INT

Just to keep the post by Martin in context. Here're the related exchanges:

Martin:
>  (1) -> a:EXPR POLY INT
>
>    Expression Polynomial Integer is not a valid type.

William:
> I wonder what generates the error message. 

Martin: 
> I found several possible sources, all in the boot code: The error code is
> S2IE004, so ...

William:

I am not good at boot code at all (this is one for Tim). The question is, what
call (not where the message came from) is invoked in the interpreter that is NOT
invoked in dom:=EXPR POLY INT but in (1) or a::EXPR POLY INT, or by the
compiler? One would think, in all cases, that EXPR POLY INT would be
instantiated BEFORE the : or :: or := operators. But it now seems that the
declaration : invokes some routines that
leads to the error.

 > )abb package TEST  Test
 > 
 > Test():Target==Implementation where
 >   EXPR ==> Expression
 >   POLY ==> Polynomial
 >   INT  ==> Integer
 >   Target ==> with
 >     myfunc: () -> EXPR POLY INT
 >   Implementation ==> add
 >     a:=new()$Symbol::EXPR POLY INT
 >     myfunc()==a
 > 
 > After compiling, I can do:
 > v:=myfunc()$TEST
 > v+v
 > convert(v)$(EXPR POLY INT)

Martin:

> Yes, I did that. I realised only later that axiom thinks it's not a valid
> type. The reason why I wanted it is: I have a Field F, do rational interpolation
> to get a function f(x) with coefficients in F. Finally, I generate
> sum(f(x),x=0..n). However, I also want to allow FRAC POLY INT for my field F...

William:

Whenever you use POLY constructor, you are including ALL symbols as
indeterminates (this is unlike some other domains like DMP where the variables
are specifically given). So it really does not make sense to consider your f(x)
as belonging to the domain EXPR FRAC POLY INT because the system gets confused
of where x belongs. Mathematically, it is like writing down k[a,b,c, ..., x,
...][x]. There is no way to replace the dummy x in f(x) by another symbol that
will work because ANY symbol is already included in POLY INT. So if you do want
F to be a rational function field, you will have to specify all its variables
and then the dummy variable needs a symbol different from those.

Actually, I think this also explains why a:EXPR POLY INT or a::EXPR POLY INT
causes problems with an error message. The symbol a can belong to POLY INT or be
part of EXPR (which includes in fact FRAC POLY). This ambiguity is why there is
an error. Simply constructing EXPR POLY INT without any computation is fine. 

So is this a bug? I am not sure, it may be good that the interpreter caught the
ambiguity and it may be bad that the compiler does not. The compiler actually
knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is
used, but we (human) will get all confused. Try:

)abb package TEST  Test

Test():Target==Implementation where
  EXPR ==> Expression
  POLY ==> Polynomial
  INT  ==> Integer
  Target ==> with
    f1: () -> EXPR POLY INT
    f2: () -> POLY INT
    f3: () -> EXPR POLY INT
    f4: () -> EXPR POLY INT
  Implementation ==> add
    a:=new()$Symbol
    b:=a ::EXPR POLY INT
    c:=a :: POLY INT
    f1()==b
    f2()==c
    f3()== (c*b)/b
    f4()== f3()/b

Note that if you check the signature of /, the compiler "knows" it is legally
used and the answer for f4() is c/b, not 1 (which should be the case
mathematically).
--------
added comment to last remark: Normally coercions must be explicit for the
compiler. But here, the compiler is "smart" in both c*b and in the subsequent /
for both f3 and f4.
So this may be a problem with the database for the interpreter.

Now some comment on the previous post of Martin:

> When saying f4()$TEST, the former gets called (twice, once for f3 too): The
> first time x is %A %A and y is %A and x /$Rep y gives %A / %A, the second time, 

you meant x /$Rep y gives %A, not "%A / %A"?

> x and y are both %A, and x /$Rep y gives %A / %A.

> When I say a::EXPR INT/a, also the former gets called (once, of course),
> x and y being a and x /$Rep y gives 1.

It is strange that the interpreter finds / for EXPR INT, but not for EXPR POLY
INT
when I do:

  b:=f1()$TEST
  c:=f2()$TEST
  d:=c*b/b  (/ not found in EXPR POLY INT, even though it should be; e.g. )show
does.)
  d:=f3()$TEST
  e:=d/b   (/ not found)
  POLY INT has IntegralDomain

    true

b gets %A (EXPR POLY INT), c gets %A (POLY INT), d gets %A (EXPR POLY INT).

\start
Date: Tue, 15 Jun 2004 17:28:38 +0000
From: Martin Rubey
To: William Sit
Subject: Re: EXPR POLY INT

William Sit writes:
 > Just to keep the post by Martin in context. Here're the related exchanges:

Oops, thanks a lot William.

 > > When saying f4()$TEST, the former gets called (twice, once for f3 too):
 > > The first time x is %A %A and y is %A and x /$Rep y gives %A / %A, the
 > > second time,
 > 
 > you meant x /$Rep y gives %A, not "%A / %A"?

Well, /$REP is called two times, once in /$EXPR calculating the result of f3,
then again in /$EXPR calculating the result of f4. Curiously, it "works" the
first time, but not the second time.

Good news: I now know how to find out which function gets called! I said

cd axiom--release--1--patch-12/int/algebra/
grep "(DEFUN [^ ]*;/;" */* | less

to get a list of all functions "/", this list I massaged in emacs to 
(trace |...|) the functions
and )lib the libraries,

AFTER calling f4()$TEST once. (Otherwise trace will answer that the function is
.)

So this is what I get:


(10) -> f4()$TEST

  1> (|EXPR;/;3$;14| ((1 #<vector 08f189f4> (1 0 1 %A (1 0 . 1))) 0 0 . 1) ((1 #<vector 08f189f4> (1 0 0 . 1)) 0 0 . 1) #<vector 09038e38>)
    2> (|FIELD-;/;3S;11| ((1 #<vector 08f189f4> (1 0 1 %A (1 0 . 1))) 0 0 . 1) ((1 #<vector 08f189f4> (1 0 0 . 1)) 0 0 . 1) #<vector 08f182bc>)
    <2 (|FIELD-;/;3S;11| ((0 1 %A (1 0 . 1)) 0 0 . 1))
  <1 (|EXPR;/;3$;14| ((0 1 %A (1 0 . 1)) 0 0 . 1))
  1> (|EXPR;/;3$;14| ((0 1 %A (1 0 . 1)) 0 0 . 1) ((1 #<vector 08f189f4> (1 0 0 . 1)) 0 0 . 1) #<vector 09038e38>)
    2> (|FIELD-;/;3S;11| ((0 1 %A (1 0 . 1)) 0 0 . 1) ((1 #<vector 08f189f4> (1 0 0 . 1)) 0 0 . 1) #<vector 08f182bc>)
    <2 (|FIELD-;/;3S;11| ((0 1 %A (1 0 . 1)) 1 #<vector 08f189f4> (1 0 0 . 1)))
  <1 (|EXPR;/;3$;14| ((0 1 %A (1 0 . 1)) 1 #<vector 08f189f4> (1 0 0 . 1)))

  1> (|OUTFORM;/;3$;59| %A %A #<vector 091c3284>)
  <1 (|OUTFORM;/;3$;59| ("/" %A %A))
         %A
   (10)  --
         %A
                                          Type: Expression Polynomial Integer

(11) -> a::EXPR INT/a

  1> (|EXPR;/;3$;14| ((1 #<vector 08c95ce8> (1 0 . 1)) 0 . 1) ((1 #<vector 08c95ce8> (1 0 . 1)) 0 . 1) #<vector 09007d58>)
    2> (|FIELD-;/;3S;11| ((1 #<vector 08c95ce8> (1 0 . 1)) 0 . 1) ((1 #<vector 08c95ce8> (1 0 . 1)) 0 . 1) #<vector 08c951f8>)
    <2 (|FIELD-;/;3S;11| ((0 . 1) 0 . 1))
  <1 (|EXPR;/;3$;14| ((0 . 1) 0 . 1))

   (11)  1

I was rather astonished to see that the FIELD version of / is called.

\start
Date: Tue, 15 Jun 2004 17:21:03 -0400
From: Tim Daly
To: Steve Coast
Subject: (no subject)

Steve,

I see you have started an Open Textbook and that it is mostly 
math and science. (http://www.opentextbook.org)

Axiom is a large, general purpose computer algebra system that is
free and open source (http://savannah.nongnu.org/projects/axiom).

Would you have any interest in working with our developers to 
build chapters that use Axiom? Most people these days use some
form of computer algebra system or symbolic calculator to solve
equations rather than doing them by hand.

You could accompany your textbook with a CD that has executable
examples.

\start
Date: Tue, 15 Jun 2004 10:42:16 -0400
From: Tim Daly
To: Martin Rubey
Subject: tracing

in order to trace function calls you can say:

)set message bottomup on

which will tell you the signatures the interpreter tried to use.
I'll add this to the README.

\start
Date: Wed, 16 Jun 2004 11:19:57 +0100
From: Steve Coast
To: Tim Daly
Subject: Re: your mail

* root (Tim Daly) wrote:
> Steve,
> 
> I see you have started an Open Textbook and that it is mostly 
> math and science. (http://www.opentextbook.org)
> 
> Axiom is a large, general purpose computer algebra system that is
> free and open source (http://savannah.nongnu.org/projects/axiom).
> 
> Would you have any interest in working with our developers to 
> build chapters that use Axiom? Most people these days use some
> form of computer algebra system or symbolic calculator to solve
> equations rather than doing them by hand.
> 
> You could accompany your textbook with a CD that has executable
> examples.

absolutely, this would be cool.

I'd like CAS sections that can be pulled in to the book or left out if
people want just a pure math view of the latex.

This could be very basic like 'now find these determinants and check
your answer with Axiom or big complex problems to be solved.

have fun,

Steve Coast

\start
Date: Wed, 16 Jun 2004 13:05:37 +0000
From: Martin Rubey
To: William Sit
Subject: Re: EXPR POLY INT

ok, now I understand what's the problem in Williams example:

)abb package TEST  Test

Test():Target==Implementation where
  EXPR ==> Expression
  POLY ==> Polynomial
  INT  ==> Integer
  Target ==> with
    f1: () -> EXPR POLY INT
    f2: () -> POLY INT
    f3: () -> EXPR POLY INT
    f4: () -> EXPR POLY INT
  Implementation ==> add
    a:=new()$Symbol
    b:=a ::EXPR POLY INT
    c:=a :: POLY INT
    f1()==b
    f2()==c
    f3()== (c*b)/b
    f4()== f3()/b

as you probably noted already:

(58) -> f1()$TEST::POLY INT
 
   Cannot convert from type Expression Polynomial Integer to Polynomial
      Integer for value
   %A

but

(59) -> f3()$TEST::POLY INT

   (59)  %A
                                                     Type: Polynomial Integer

Thus, in f1, (and b) the %A is a variable of the expression, in f3 it is a
coefficient of the expression. As you know, an expression is really a fraction
of SMPs, with variables being the "kernels" of the expression. So the
numerator of f1 (considered as fraction of SMPs) is the constant SMP %A, the
numerator of f3 (considered as fraction of SMPs) is the linear SMP in one
variable, which is %A.

It is quite clear, (as William noted), that this can only lead to trouble. So,
the real reason for EXPR POLY INT failing is, that the argument domain of EXPR
should be a domain without variables. 

For example, computing gcd(f1()$TEST,f3()$TEST) -- this is what happens in
f4()$TEST -- thus gives 1 instead of %A, f1()$TEST*f3()$TEST gives  %A %A
instead of %A^2 and so on.

I think there are two possibilities to fix this:

(1) provide a possibility to get the "variable free" domain of a domain, i.e.,

POLY INT, UP(x,POLY INT) both should yield INT

(2) make the coercion to EXPR smarter and swallow all variables...

I'm very unsure wether we should prefer (1) or (2), mainly because I still
don't understand the philosophy behind EXPR. Very briefly: I think we could
characterize EXPR R by saying that it is the space of functions whose variables
are allowed to take values in R or EXPR R. However, this is not quite complete:
In which domain are the numbers appearing in the expression?

For example

(7) -> 2.0*x^2*log(2*x)

             2
   (7)  2.0 x log(2.0 x)
                                                       Type: Expression Float

which is good, I believe. (Note that the square stayed square, not power 2.0)

Unfortunately I do not have browse, because I find it very difficult to imagine
other types and the example above is rather trivial. Maybe someone with the NAG
version could answer the following:

Are there domains with OrderedSet and IntegralDomain which are not
RetractableTo Integer?

\start
Date: Wed, 16 Jun 2004 09:15:48 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: EXPR POLY INT

Martin,

Historically EXPR was an attempt at creating a domain where the user
did not need to be concerned about types. There was (and still is)
great pressure from users of competing CA systems to be able to work
and let the interpreter worry about types. EXPR was an attempt at 
responding to that.

The best path is probably to avoid EXPR. Is there some function in 
EXPR that you need that does not exist elsewhere?

\start
Date: Wed, 16 Jun 2004 11:18:12 -0400
From: William Sit
To: Martin Rubey
Subject: Re: EXPR POLY INT

Hi Martin:

Your explanation on EXPR POLY INT is perfect.

> I think there are two possibilities to fix this:
> 
> (1) provide a possibility to get the "variable free" domain of a domain, i.e.,
> 
> POLY INT, UP(x,POLY INT) both should yield INT

Two comments: 

(1) Actually, there is a more general request for ages: that is, each
CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This
would have to be built like OutputForm form the bottom up because of nesting.
Lots of editing and a total rebuilt. Currently, when writing a constructor,
there is no way one can "descend" inside its parameters other than finding their
categorical property or attributes.

An argument against this is people may then write code that is not categorical.
But people can do anything they want anyway. The advantage is being able to
query about parameters can lead to more efficient code.

However, mathematically speaking, that is not the correct way to solve the
problem. The philosophy of Axiom is its generality. Thus EXPR R is a perfectly
good domain for any R in Join(OrderedSet, Ring) --- if ONLY EXPR could fake its
own name space for its kernel (er, variables or Symbol), which is equivalent
mathematically to taking transcendentals over R (from some universal extension,
say). This seems feasible and leads to my second comment.

(2) Note UP(x, POLY INT) is valid (in the interpreter) but not
POLY UP(x, INT) probably for the same reason as EXPR POLY INT. Now this should
be!

  )clear all
  a:POLY INT :=x
  b:UP('x,INT):='x
  differentiate(b,x)
  differentiate(b,a)
  b/a

Here one sees that just like TEST example in the compiler, the instantiation of
UP(x, POLY INT) creates internally a new symbol for 'x (but displays it as x)
separate from the x in POLY INT. In other words, UP has its own name space even
though the internal new symbol is still part of POLY INT. This trick of course
is used in all compilers to separate user variable from system variables. If the
new symbols are constructed randomly the chance of conflict is neglible. So, the
problem really lies with the user in choosing to DISPLAY results ambiguously.

On the other hand, why does the Interpreter behave differently for POLY UP(x,
INT) and UP(x, POLY INT)? The answer may lie in the fact that for POLY UP(x,
INT), the variable x is given, whereas in UP(x, POLY INT), no specific symbol is
given in POLY INT. It takes some deep tracing to see if this is true.

> 
> (2) make the coercion to EXPR smarter and swallow all variables...
> 
> I'm very unsure wether we should prefer (1) or (2), mainly because I still
> don't understand the philosophy behind EXPR. 

Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may be an
easier target to "fix".

Summary recommendation: All constructions should be allowed by creating suitable
name spaces to separate the computations. Users should not confuse themselves by
using the same variable name (for display) for the different name spaces.

> Very briefly: I think we could
> characterize EXPR R by saying that it is the space of functions whose variables
> are allowed to take values in R or EXPR R. However, this is not quite complete:
> In which domain are the numbers appearing in the expression?
> 
> For example
> 
> (7) -> 2.0*x^2*log(2*x)
> 
>              2
>    (7)  2.0 x log(2.0 x)
>                                                        Type: Expression Float
> 
> which is good, I believe. (Note that the square stayed square, not power 2.0)

But notice that the 2 in 2*x has to be coerced to Float even though Float has
RetractableTo INT.

> Are there domains with OrderedSet and IntegralDomain which are not
> RetractableTo Integer?

An integral domain of characteristic zero is always retractable to integer. On
the other hand, one of characteristic non-zero will contain a prime field which
is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
RetractableTo(%), not RetractableTo Integer).

\start
Date: Wed, 16 Jun 2004 10:24:31 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: tracing

Axiom has lisp code that can be used for tracing function calls.
the code lives in monitor.spad.pamphlet (and is actually documented!)

i haven't used it in a long time but the basic idea is that you want
to collect information about lisp functions in a particular file.
monitor reads the file, wraps each function in a trace.

see the function monitor-file which scans a file for all defuns
and when it finds one calls monitor-add.

in the function monitor-add we wrap the defun with in a trace call.
the trace call will call monitor-incr each time the function is called.
you could redefine monitor-incr and see the results you want.

in fact, if I had the time I could generalize the trace call
so the user could specify various trace arguments. 

I wrote it in order to improve Axiom's function calling so it 
currently only counts function calls.

\start
Date: Thu, 17 Jun 2004 06:51:05 +0200
From: Michel Lavaud
To: Tim Daly
Subject: Re:  Open book (was (no subject))

Hello Tim,

On 15 Jun 2004 at 17:21, root wrote:

> I see you have started an Open Textbook and that it is mostly 
> math and science. (http://www.opentextbook.org)

\start
Date: Thu, 17 Jun 2004 06:57:58 +0200
From: Michel Lavaud
To: Tim Daly
Subject: Re:  Open book (was (no subject))

Hello Tim,

On 15 Jun 2004 at 17:21, root wrote:

> I see you have started an Open Textbook and that it is mostly 
> math and science. (http://www.opentextbook.org)

What is the procedure to contribute ? I could not find it from the web site.

\start
Date: Thu, 17 Jun 2004 08:30:15 -0400
From: William Sit
To: Tim Daly
Subject: Re: EXPR POLY INT

root wrote:

>Martin,
>
> Historically EXPR was an attempt at creating a domain where the user
> did not need to be concerned about types. There was (and still is)
> great pressure from users of competing CA systems to be able to work
> and let the interpreter worry about types. EXPR was an attempt at
> responding to that.

I believe ANY is the domain to encompass all objects of arbitrary type and ANY
depends on manipulating Lisp values via SEX (I know that will get your
attention!) I think this is the work of Bob Sutor.

> The best path is probably to avoid EXPR. Is there some function in
> EXPR that you need that does not exist elsewhere?

EXPR is used for many constructions, for example, the algebraic closure of the
field of rational numbers, or the domain AlgebraicNumber in Axiom is represented
as EXPR INT. An understanding of EXPR is a must to do any computation with
algebraic numbers and that includes integration and differential equations. 

\start
Date: 17 Jun 2004 16:11:42 -0400
From: Camm Maguire
To: Tim Daly
Subject: Axiom on sparc solaris

Greetings!  As part of the gcl testing procedure, we've been trying to
test an axiom build on solaris.  There are some difficulties
associated with the fact that the standard tools, e.g. tar, have a
different syntax there, but once one gets around this, we get
something to the effect that the root module for Make.solaris is
missing. 

Pointers?

\start
Date: Thu, 17 Jun 2004 18:01:18 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom on sparc solaris

Camm,

What was the value of your AXIOM variable on the solaris platform?

\start
Date: 17 Jun 2004 18:50:39 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom on sparc solaris

Greetings!

export AXIOM=$(pwd)/mnt/solaris

Take care,

Tim Daly writes:

> Camm,
> 
> What was the value of your AXIOM variable on the solaris platform?

\start
Date: Fri, 18 Jun 2004 14:09:38 +0000
From: Martin Rubey
To: Manuel Bronstein
Subject: Re: Patches 

Dear Prof. Bronstein,

thanks a lot for your answer!

Manuel Bronstein writes:
 > - new()$Symbol is working properly in the NAG version, so 9298 is
 >   probably a lisp problem.

Good. I remember that somebody was building axiom on cmucl -- I think it was 
Juergen Weiss. Could he try to reproduce bug #9298 on cmucl? Camm Muguire (GCL)
already offered to track down the bug:

Camm Maguire wrote:
 > 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.

However, I don't know how to "boil it down" :-(

Manuel Bronstein writes:

 > - The line
 >       -- cannot use new()$Symbol because of possible re-instantiation
 >       gendiff := "%%0"::SY
 >   in fspace.spad is due to a problem with the axiom runtime: when a domain
 >   falls out of the runtime cache, it gets created again next time a function
 >   from that domain is called. This means that the top-level code of the
 >   domain is re-executed, and the globals are re-assigned.  The existing
 >   objects from that domain in your session remain unchanged.  This would
 >   cause the value of the gendiff symbol to change at random times, while
 >   previous values of gendiff would be stored in live objects, and that
 >   causes havoc.  If the runtime could guarantee that top-level code is
 >   called only once, then, I would have used new()$Symbol. But this
 >   re-instantiation problem forces hardwiring a specific symbol, I used %%O
 >   hoping that it would not conflict with user variables.

This goes to the docs. Thanks a lot!


 > - The definite summation operator %defsum takes 5 arguments as follows:
 >     f  - the expression being summed, depends on a dummy summation variable
 >     v  - the dummy summation variable
 >     k  - the symbol to use for the summation variable when displaying
 >     a  - the lower bound
 >     b  - the upper bound

 >   For differentiation, it is viewed as a function of the 3 arguments f,a,b
 >   and the chain rule is used, although my interpretation of the partial
 >   derivative of the sum function with respect to the summation bounds is
 >   wrong. I have to remember the reasons for the design, but the current
 >   formula encoded in dvdsum is the following:
 > 
 >     D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db
 > 
 >   for any derivation D. In the case of indefinite summation, a is an
 >   arbitrary constant, so that formula becomes
 > 
 >     D(sum(f(i),i=..n) = sum((Df)(i),i=..n) + f(n) Dn
 > 
 >   which is encoded in dvsum.  Both are clearly wrong when the bounds are not
 >   constant, I do not have the correct derivative at hand when the sum is not
 >   expressible in closed form as a function of the bounds.  If there is
 >   agreement to return an unevaluated derivative when the bounds are not
 >   constants w.r.t. D, I can probably patch dvdsum and dvsum to do this.

I'm certain that this is the best thing to do. If you could provide a patch,
that would be great!

Some more issues:

- is there any (written) documentation on the design of the EXPR domain
  (including FS, ES, COMBFS, FS2 ...) ?

- I have a problem with sum: once sum is turned into an operator (for example
  via summation or idsum), it stays such an operator. It would be great if sum
  could be re-evaluated. In fact, I believe that sum$FS2 should be called
  automatically in certain circumstances. However, I do not yet have a clear
  picture how this should be done. (Also considering the fact that there should
  be more summation algorithms in the near future. Maybe the RISC people will
  help, I don't know...)

- is the Algebra library from Aldor Open Source? Where could I get it? Looking
  at the Basic Categories in its documentation it seems that there is quite a
  bit of overlap with the corresponding Axiom Domains. It would be nice if we
  could make the two things converge *somehow*. (It seems to me that the Aldor
  stuff is more up to date, but I don't know.)

Thanks again for joining,

\start
Date: Fri, 18 Jun 2004 10:41:23 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom on sparc solaris

Camm,

I don't have access to a solaris machine.
Please send me the Makefile.solaris that gets created.

\start
Date: Fri, 18 Jun 2004 13:35:30 +0200
From: Manuel Bronstein
To: Martin Rubey
Subject: Re: Patches 

Hello,

Sorry to pitch in late on this, I only received part of the thread and
had to reconstruct it and look at the original bug reports.

- new()$Symbol is working properly in the NAG version, so 9298 is
  probably a lisp problem.

- The line
      -- cannot use new()$Symbol because of possible re-instantiation
      gendiff := "%%0"::SY
  in fspace.spad  is due to a problem with the axiom runtime: when a
  domain falls out of the runtime cache, it gets created again next time
  a function from that domain is called. This means that the top-level code
  of the domain is re-executed, and the globals are re-assigned.
  The existing objects from that domain in your session remain unchanged.
  This would cause the value of the gendiff symbol to change at random times,
  while previous values of gendiff would be stored in live objects, and that
  causes havoc.
  If the runtime could guarantee that top-level code is called only once,
  then, I would have used new()$Symbol. But this re-instantiation problem
  forces hardwiring a specific symbol, I used %%O hoping that it would not
  conflict with user variables.

- The definite summation operator %defsum takes 5 arguments as follows:
    f  - the expression being summed, depends on a dummy summation variable
    v  - the dummy summation variable
    k  - the symbol to use for the summation variable when displaying
    a  - the lower bound
    b  - the upper bound
  For differentiation, it is viewed as a function of the 3 arguments f,a,b
  and the chain rule is used, although my interpretation of the partial
  derivative of the sum function with respect to the summation bounds is
  wrong. I have to remember the reasons for the design, but the current
  formula encoded in dvdsum is the following:

    D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db

  for any derivation D. In the case of indefinite summation, a is an
  arbitrary constant, so that formula becomes

    D(sum(f(i),i=..n) = sum((Df)(i),i=..n) + f(n) Dn

  which is encoded in dvsum.
  Both are clearly wrong when the bounds are not constant, I do not have
  the correct derivative at hand when the sum is not expressible in closed
  form as a function of the bounds.
  If there is agreement to return an unevaluated derivative when the bounds
  are not constants w.r.t. D, I can probably patch dvdsum and dvsum to do this.

\start
Date: Fri, 18 Jun 2004 17:47:06 +0000
From: Martin Rubey
To: list
Subject: Re: EXPR POLY INT

William Sit writes:
 > Hi Martin:
 > 
 > Your explanation on EXPR POLY INT is perfect.

thanks!
 
 > > (1) provide a possibility to get the "variable free" domain of a domain, i.e.,
 > > 
 > > POLY INT, UP(x,POLY INT) both should yield INT
 > 
 > Two comments: 
 > 
 > (1) Actually, there is a more general request for ages: that is, each
 > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This
 > would have to be built like OutputForm form the bottom up because of nesting.
 > Lots of editing and a total rebuilt. Currently, when writing a constructor,
 > there is no way one can "descend" inside its parameters other than finding their
 > categorical property or attributes.

Hm, I don't quite understand why this would be more general? What I think what
is needed is a function that takes a domain as argument and has a domain as
value, which is related to the first domain in the sense that the resulting
domain is no longer RetractableTo Symbol.

 > (2) Note UP(x, POLY INT) is valid (in the interpreter) but not
 > POLY UP(x, INT) probably for the same reason as EXPR POLY INT. Now this should
 > be!
 > 
 >   )clear all
 >   a:POLY INT :=x
 >   b:UP('x,INT):='x
 >   differentiate(b,x)
 >   differentiate(b,a)
 >   b/a

Uh, ugly. An excellent example though!

 > > (2) make the coercion to EXPR smarter and swallow all variables...
 > > 
 > > I'm very unsure wether we should prefer (1) or (2), mainly because I still
 > > don't understand the philosophy behind EXPR. 
 > 
 > Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may be an
 > easier target to "fix".

Yes. In fact, there is another possibility to consider. In (2) I suggested that
all the variables in EXPR POLY INT should belong to EXPR. In fact, this was an
accident. What I meant to say is

 (3) make the coercion to EXPR smarter and let its argument domain swallow as
     many variables as possible.

I think that this would be more sound. However, my feeling is that (1) is the
best way.

 > > Very briefly: I think we could
 > > characterize EXPR R by saying that it is the space of functions whose variables
 > > are allowed to take values in R or EXPR R. However, this is not quite complete:
 > > In which domain are the numbers appearing in the expression?
 > > 
 > > For example
 > > 
 > > (7) -> 2.0*x^2*log(2*x)
 > > 
 > >              2
 > >    (7)  2.0 x log(2.0 x)
 > >                                                        Type: Expression Float
 > > 
 > > which is good, I believe. (Note that the square stayed square, not power 2.0)
 > 
 > But notice that the 2 in 2*x has to be coerced to Float even though Float has
 > RetractableTo INT.

Hm? The above was an (unfortunately trivial) example to show that not all
numbers in EXPR FLOAT are FLOAT, or, more generally, not all coefficients in
EXPR R are from R. In fact, it seems as though exactly the powers are
not. More precisely, they cannot be:

(6) -> x^2.1

         2 10+-+
   (6)  x   \|x
                                                       Type: Expression Float
The following I'd consider as a bug:

(10) -> (x^%pi)::EXPR FLOAT

          3 6701487259+-+948881364
   (10)  x           \|x
                                                       Type: Expression Float

 > > Are there domains with OrderedSet and IntegralDomain which are not
 > > RetractableTo Integer?

 > An integral domain of characteristic zero is always retractable to integer. On
 > the other hand, one of characteristic non-zero will contain a prime field which
 > is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
 > RetractableTo(%), not RetractableTo Integer).

Yes, but could you give an example? This would be great!

\start
Date: Fri, 18 Jun 2004 17:51:58 +0000
From: Martin Rubey
To: list
Subject: Re: EXPR POLY INT

 Martin Rubey wrote:
 >  > > (1) provide a possibility to get the "variable free" domain of a domain, i.e.,
 >  > >
 >  > > POLY INT, UP(x,POLY INT) both should yield INT
 >  >
 >  > Two comments:
 >  >
 >  > (1) Actually, there is a more general request for ages: that is, each
 >  > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This
 >  > would have to be built like OutputForm form the bottom up because of nesting.
 >  > Lots of editing and a total rebuilt. Currently, when writing a constructor,
 >  > there is no way one can "descend" inside its parameters other than finding their
 >  > categorical property or attributes.
 > 
 > Hm, I don't quite understand why this would be more general? What I think what
 > is needed is a function that takes a domain as argument and has a domain as
 > value, which is related to the first domain in the sense that the resulting
 > domain is no longer RetractableTo Symbol.
 
 I disagree on this approach. First, mathematically, one can take a polynomial
 extension of any integral domain (and then its quotient ring) and the "new"
 variables should not be mixed up with elements of the integral domain. Second,
 not only will your approach require a mechanism to obtain the parameters of ANY
 constructor, but it will require further need to be able to RECONSTRUCT one.
 What would be your resulting domain for
 EXPR AN? (AN is AlgebraicNumber, which is the algebraic closure of the field of
 rational numbers. However, AN has EXPR INT as Rep which is NOT visible. At this
 time, I am not able to get an example like the one on POLY--UP interaction,
 because I do not follow the setup for AN (among lots of other things). So may be
 there is no such bad interaction (afterall, AN mathematically are just numbers!) 
 
 In any case, deciding the "field/domain of constants" in an Axiom domain
 requires more than just examining the towers. This is a difficult problem in
 differential Galois theory (for Picard Vessiot extensions): when does an
 extension contain no new constants? An example is the (differential field) F =
 Q(sin^2(x), sin(x)cos(x)), where Q is the field of rational numbers, x is
 transcendental and differentiation is D= d/dx. F can be constructed as a
 quadratic extension Q(y,z) of Q(y) where y is a transcendental and z^2 = y(1-y),
 Dy = 2z. In this construction, y would be retractable to a symbol and z may be a
 kernel. It takes some work to decide whether there are new constants other than
 those in Q (whether there are or aren't is not releveant to this discussion).
 Now think about EXPR F. How would you "simplify" this to using a general
 algorithm?
 
 >  > > (2) make the coercion to EXPR smarter and swallow all variables...
 >  > >
 >  > > I'm very unsure wether we should prefer (1) or (2), mainly because I still
 >  > > don't understand the philosophy behind EXPR.
 >  >
 >  > Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may be an
 >  > easier target to "fix".
 > 
 > Yes. In fact, there is another possibility to consider. In (2) I suggested that
 > all the variables in EXPR POLY INT should belong to EXPR. In fact, this was an
 > accident. What I meant to say is
 > 
 >  (3) make the coercion to EXPR smarter and let its argument domain swallow as
 >      many variables as possible.
 > 
 > I think that this would be more sound. However, my feeling is that (1) is the
 > best way.
 
 See above comment on (1). (3) will not work with EXPR POLY interaction because
 both wants to include ALL of SYMBOL, but may work with EXPR DMP (but not DMP
 EXPR). (3) may be difficult for EXPR F (F as above). I still think separating
 the name spaces (like any good old compilers -- think C++) is a reasonable
 approach. So each constructor gets its own name space by using a prefix.
 (Mathematica does this via what it calls "Context"). Coercion may be done by
 switching prefix in addition to any data conversion (Rep conversion). However,
 there are probably many many implications for this line of thinking and I know
 very little about compilers. I wonder how Aldor handles this type of issues.
 
 > 
 >  > > Very briefly: I think we could
 >  > > characterize EXPR R by saying that it is the space of functions whose variables
 >  > > are allowed to take values in R or EXPR R. However, this is not quite complete:
 >  > > In which domain are the numbers appearing in the expression?
 >  > >
 >  > > For example
 >  > >
 >  > > (7) -> 2.0*x^2*log(2*x)
 >  > >
 >  > >              2
 >  > >    (7)  2.0 x log(2.0 x)
 >  > >                                                        Type: Expression Float
 >  > >
 >  > > which is good, I believe. (Note that the square stayed square, not power 2.0)
 >  >
 >  > But notice that the 2 in 2*x has to be coerced to Float even though Float has
 >  > RetractableTo INT.
 > 
 > Hm? The above was an (unfortunately trivial) example to show that not all
 > numbers in EXPR FLOAT are FLOAT, or, more generally, not all coefficients in
 > EXPR R are from R. In fact, it seems as though exactly the powers are
 > not. 
 
 Exponents are not coefficients and technically belongs to a different domain
 from the coefficient domain in Axiom. Check the parameters for
 PolynomialCategory. So sure, not all "numbers" in EXPR FLOAT are FLOAT: the
 exponents aren't.
 
 >More precisely, they cannot be:
 > 
 > (6) -> x^2.1
 > 
 >          2 10+-+
 >    (6)  x   \|x
 >                                                        Type: Expression Float
 > The following I'd consider as a bug:
 > 
 > (10) -> (x^%pi)::EXPR FLOAT
 > 
 >           3 6701487259+-+948881364
 >    (10)  x           \|x
 >                                                        Type: Expression Float
 
 I don't know what you mean by a bug here. I assume the answer is correct, but
 there should be parenthesis that may make the display better. Axiom converts any
 decimal number with fixed precision into a rational number and allows these as
 exponents.
 
 >  > > Are there domains with OrderedSet and IntegralDomain which are not
 >  > > RetractableTo Integer?
 > 
 >  > An integral domain of characteristic zero is always retractable to integer. On
 >  > the other hand, one of characteristic non-zero will contain a prime field which
 >  > is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
 >  > RetractableTo(%), not RetractableTo Integer).
 > 
 > Yes, but could you give an example? This would be great!
 > 
 > Martin
 
 I thought my answer above meant there can be no such examples. Every domain in
 Axiom belonging to OrderedSet and IntegralDomain will belong to RetractableTo
 Integer.

\start
Date: Fri, 18 Jun 2004 12:11:54 -0400
From: William Sit
To: Manuel Bronstein
Subject: Re: Patches
Cc: Martin Rubey

Hi Manuel:

Thanks for pitching in. Martin and I have been making guessing games on your
Axiom code. Your input will definitely help in making necessary patches.

The Thread Patches has branched out into:
EXPR POLY INT
Bugs in combfunc.spad and partial patch

> - The definite summation operator %defsum takes 5 arguments as follows:
>     f  - the expression being summed, depends on a dummy summation variable
>     v  - the dummy summation variable
>     k  - the symbol to use for the summation variable when displaying
>     a  - the lower bound
>     b  - the upper bound
>   For differentiation, it is viewed as a function of the 3 arguments f,a,b
>   and the chain rule is used, although my interpretation of the partial
>   derivative of the sum function with respect to the summation bounds is
>   wrong. I have to remember the reasons for the design, but the current
>   formula encoded in dvdsum is the following:
> 
>     D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db

The Axiom version has:

      D(sum(f(i),i=a..b)) = sum((Df)(i),i=a..b) - f(a) Da + f(b) Db

>   for any derivation D. In the case of indefinite summation, a is an
>   arbitrary constant, so that formula becomes
> 
>     D(sum(f(i),i=..n) = sum((Df)(i),i=..n) + f(n) Dn
> 
>   which is encoded in dvsum.
>   Both are clearly wrong when the bounds are not constant, 

I still do not know under what conditions dvdsum applies (correctly). Do you
mean that it applies only when Da = - and Db = 0? In that case, why bother with
those terms? The formula (with the minus sign on f(a)Da) looks very much like
Leibniz' rule for differentiating under an integral sign, but I was not able to
find any such reference or formula.

>   I do not have
>   the correct derivative at hand when the sum is not expressible in closed
>   form as a function of the bounds.

Is there such a formula?

>   If there is agreement to return an unevaluated derivative when the bounds
>   are not constants w.r.t. D, I can probably patch dvdsum and dvsum to do this.

Well, I think there are cases when the bounds are not constant wrt D, but the
summation can be done in closed form (such as sums of powers). Those cases
should return an evaluated (hopefully correct) answer. But when a closed form is
not available (to the current version of Axiom), the original input should be
returned. Mathematica uses many special functions to replace summations and
perform differentiation afterwards. Axiom is not set up to do any such things
yet, I believe. I tried, but just like Martin had, and found it impossible to
"hold" the differentiation operator without getting into an infinite loop.
(Holding the summation is ok). It seems this cannot be done in combfunc.spad
alone.

Many thanks for your inputs.

\start
Date: Fri, 18 Jun 2004 18:26:53 +0000
From: Martin Rubey
To: list
Subject: Re: [Axiom-math] [Fwd: Re: EXPR POLY INT]

William Sit writes:
 > Martin Rubey wrote:
 > >  > > (1) provide a possibility to get the "variable free" domain of a
 > >  > >     domain, i.e.,
 > >  > >
 > >  > > POLY INT, UP(x,POLY INT) both should yield INT
 > 
 > I disagree on this approach. First, mathematically, one can take a
 > polynomial extension of any integral domain (and then its quotient ring) and
 > the "new" variables should not be mixed up with elements of the integral
 > domain. Second, not only will your approach require a mechanism to obtain
 > the parameters of ANY constructor, but it will require further need to be
 > able to RECONSTRUCT one.  What would be your resulting domain for EXPR AN?
 > (AN is AlgebraicNumber, which is the algebraic closure of the field of
 > rational numbers. However, AN has EXPR INT as Rep which is NOT visible. At
 > this time, I am not able to get an example like the one on POLY--UP
 > interaction, because I do not follow the setup for AN (among lots of other
 > things). So may be there is no such bad interaction (afterall, AN
 > mathematically are just numbers!)

 > In any case, deciding the "field/domain of constants" in an Axiom domain
 > requires more than just examining the towers. This is a difficult problem in
 > differential Galois theory (for Picard Vessiot extensions): when does an
 > extension contain no new constants? An example is the (differential field) F
 > = Q(sin^2(x), sin(x)cos(x)), where Q is the field of rational numbers, x is
 > transcendental and differentiation is D= d/dx. F can be constructed as a
 > quadratic extension Q(y,z) of Q(y) where y is a transcendental and z^2 =
 > y(1-y), Dy = 2z. In this construction, y would be retractable to a symbol
 > and z may be a kernel. It takes some work to decide whether there are new
 > constants other than those in Q (whether there are or aren't is not
 > releveant to this discussion).  Now think about EXPR F. How would you
 > "simplify" this to using a general algorithm?

Hm. I see, I was thinking too "applied". My problem was the following: I have
some field domain F, and I want to build an expression over it (basically
containing sums and products). However axiom won't let me do this -- even if
the field has OrderedSet. So I thought, well, get a domain R such that EXPR R
contains F.

But I suppose that you're right...

 > >  > > (2) make the coercion to EXPR smarter and swallow all variables...
 > >  > >
 > >  > > I'm very unsure wether we should prefer (1) or (2), mainly because I
 > >  > > still don't understand the philosophy behind EXPR.
 > >  >
 > >  > Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may
 > >  > be an easier target to "fix".
 > > 
 > > Yes. In fact, there is another possibility to consider. In (2) I suggested
 > > that all the variables in EXPR POLY INT should belong to EXPR. In fact,
 > > this was an accident. What I meant to say is
 > > 
 > >  (3) make the coercion to EXPR smarter and let its argument domain swallow
 > >  as many variables as possible.
 > > 
 > > I think that this would be more sound. However, my feeling is that (1) is
 > > the best way.
 > 
 > See above comment on (1). (3) will not work with EXPR POLY interaction
 > because both wants to include ALL of SYMBOL, but may work with EXPR DMP (but
 > not DMP EXPR). (3) may be difficult for EXPR F (F as above). I still think
 > separating the name spaces (like any good old compilers -- think C++) is a
 > reasonable approach. So each constructor gets its own name space by using a
 > prefix.  (Mathematica does this via what it calls "Context"). Coercion may
 > be done by switching prefix in addition to any data conversion (Rep
 > conversion). However, there are probably many many implications for this
 > line of thinking and I know very little about compilers. I wonder how Aldor
 > handles this type of issues.

In fact, it seems as though there were seperate namespaces at the moment, only
the user cannot distinguish them. In this sense, maybe were heading towards a
patch of output...


-------------------------------------------------------------------------------
 > >  > > Very briefly: I think we could characterize EXPR R by saying that it
 > >  > > is the space of functions whose variables are allowed to take values
 > >  > > in R or EXPR R. However, this is not quite complete: In which domain
 > >  > > are the numbers appearing in the expression?
 > >  > >
 > >  > > For example
 > >  > >
 > >  > > (7) -> 2.0*x^2*log(2*x)
 > >  > >
 > >  > >              2
 > >  > >    (7)  2.0 x log(2.0 x)
 > >  > >                                                 Type: Expression Float
 > >  > >
 > >  > > which is good, I believe. (Note that the square stayed square, not
 > >  > > power 2.0)
 > >  >
 > >  > But notice that the 2 in 2*x has to be coerced to Float even though
 > >  > Float has RetractableTo INT.
 > > 
 > > Hm? The above was an (unfortunately trivial) example to show that not all
 > > numbers in EXPR FLOAT are FLOAT, or, more generally, not all coefficients
 > > in EXPR R are from R. In fact, it seems as though exactly the powers are
 > > not.
 > 
 > Exponents are not coefficients and technically belongs to a different domain
 > from the coefficient domain in Axiom. Check the parameters for
 > PolynomialCategory. So sure, not all "numbers" in EXPR FLOAT are FLOAT: the
 > exponents aren't.

Thanks for the pointer. In fact, this is good news for me. Maybe it does make
sense to think about an alternative to EXPR after all.

 > > The following I'd consider as a bug:
 > > 
 > > (10) -> (x^%pi)::EXPR FLOAT
 > > 
 > >           3 6701487259+-+948881364
 > >    (10)  x           \|x
 > >                                                        Type: Expression Float
 > 
 > I don't know what you mean by a bug here. I assume the answer is correct, but
 > there should be parenthesis that may make the display better. Axiom converts any
 > decimal number with fixed precision into a rational number and allows these as
 > exponents.

Sorry, my fault.
 > 
 > >  > > Are there domains with OrderedSet and IntegralDomain which are not
 > >  > > RetractableTo Integer?
 > > 
 > >  > An integral domain of characteristic zero is always retractable to integer. On
 > >  > the other hand, one of characteristic non-zero will contain a prime field which
 > >  > is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
 > >  > RetractableTo(%), not RetractableTo Integer).
 > > 
 > > Yes, but could you give an example? This would be great!
 > > 
 > > Martin
 > 
 > I thought my answer above meant there can be no such examples. Every domain in
 > Axiom belonging to OrderedSet and IntegralDomain will belong to RetractableTo
 > Integer.

Again: stupid me. Sorry. On the other hand: in combfunc.spad we have


CombinatorialFunction(R, F): Exports == Implementation where
  R: Join(OrderedSet, IntegralDomain)
  F: FunctionSpace R

...

  Z   ==> Integer

and quite a bit of code for R which is not RetractableTo Z, for example:

    number?(x:F):Boolean ==
      if R has RetractableTo(Z) then
        ground?(x) or
         ((retractIfCan(x)@Union(Fraction(Z),"failed")) case Fraction(Z))
      else
        ground?(x)

(also, more importantly: iidsum, iidprod, ...)

so it seems that Bronstein thought already about allowing R's which do not have
OrderedSet...

Well, for the moment I'm happy. (Although the header of my package looks a bit
crowded)

\start
Date: Fri, 18 Jun 2004 18:37:01 +0200
From: Manuel Bronstein
To: William Sit
Subject: Re: Patches 
Cc: Martin Rubey, Manuel Bronstein

> >   wrong. I have to remember the reasons for the design, but the current
> >   formula encoded in dvdsum is the following:
> > 
> >     D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db
> 
> The Axiom version has:
> 
>       D(sum(f(i),i=a..b)) = sum((Df)(i),i=a..b) - f(a) Da + f(b) Db

You're right, my typo.

> I still do not know under what conditions dvdsum applies (correctly). Do you
> mean that it applies only when Da = - and Db = 0?

I hope not only those cases, but at least those (where it is trivial).
There must have been some examples with Da or Db nonzero and where that
formula worked.

> should return an evaluated (hopefully correct) answer.
> But when a closed form is
> not available (to the current version of Axiom), the original input should be
> returned. Mathematica uses many special functions to replace summations and
> perform differentiation afterwards. Axiom is not set up to do any such things
> yet, I believe. I tried, but just like Martin had, and found it impossible to
> "hold" the differentiation operator without getting into an infinite loop.
> (Holding the summation is ok). It seems this cannot be done in combfunc.spad
> alone.

I'll give it a try, but not before ISSAC.

\start
Date: Fri, 18 Jun 2004 13:20:22 -0400
From: William Sit
To: Manuel Bronstein
Subject: Re: Patches
Cc: Martin Rubey

Manuel Bronstein wrote:
 
> > I still do not know under what conditions dvdsum applies (correctly). Do you
> > mean that it applies only when Da = 0 [corrected typo] and Db = 0?
> 
> I hope not only those cases, but at least those (where it is trivial).
> There must have been some examples with Da or Db nonzero and where that
> formula worked.

Yes there may be, but all the examples I tried, it seems either the summation is
done first or the answer is wrong.

> I'll give it a try, but not before ISSAC.

Thanks. Take your time.

\start
Date: Fri, 18 Jun 2004 16:14:17 +0200
From: Gregory Vanuxem
To: Axiom Developer <list>
Subject: Complex exponentiation and 0

Hi,

In complex(Float) and Complex(SingleFloat), we have to change the
exponentiation so that
	complex(0,0)^complex(0,0.0)
or
	complex(0,0)^complex(2,2.0)
doesn't use log.

if (real(x) = 0 and imag(x) = 0)
	if (real(power)=0 and  imag(power)=0)
		complex(1.0,0.0)
 	else
		complex(0.0,0.0)
else
	...


\start
Date: Fri, 18 Jun 2004 14:50:02 -0400
From: William Sit
To: Martin Rubey
Subject: re: [Axiom-math] [Fwd: Re: EXPR POLY INT]

Martin Rubey wrote:

> In fact, it seems as though there were seperate namespaces at the moment, only
> the user cannot distinguish them. In this sense, maybe were heading towards a
> patch of output...

As pointed out in previous discussions, the first thing is to fix it so EXPR R
is allowed for any R having OrderedSet and IntegralDomain. Second, users should
not use the same symbol for variables that may occur in R for variables in EXPR.
And third, modify new()$Symbol to generate not just %A, but %A.tag where tag is
the name of the constructor that makes the call. This is a longer term project,
since new()$Symbol has to figure out the calling domain. An alternative to this
is to patch constructors that calls new()$Symbol to do what Manuel did in
fspace.spad, that is, manually use %A.tag instead of %A returned from SYMBOL.
This bottom-up approach may be the easier route.

Your remark is not quite correct. Try this example again:

  )clear all
  a:=POLY INT:=x
  b:=UP('x,INT):='x
  b/a

    1
    - x   (type: UP(x,FRAC POLY INT))
    x

  a/b

    1     (type: FRAC POLY INT)

So the interpreter does some coercion and mixes the two x. Note in UP('x, INT),
x is only for output. 

  variables b

    ["?"]

Incidentally, previously, differentiate(b,x) gives 1, but now somehow the
interpreter cannot find the map, and differentiate(b) gives 1.


 > > Are there domains with OrderedSet and IntegralDomain which are not
 > > RetractableTo Integer?

 > An integral domain of characteristic zero is always retractable to integer.
On
 > the other hand, one of characteristic non-zero will contain a prime field
which
 > is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
 > RetractableTo(%), not RetractableTo Integer).

>  > I thought my answer above meant there can be no such examples. Every domain in
>  > Axiom belonging to OrderedSet and IntegralDomain will belong to RetractableTo
>  > Integer.
> 
> On the other hand: in combfunc.spad we have ... 
> quite a bit of code for R which is not RetractableTo Z, for example:
> 
>     number?(x:F):Boolean ==
>       if R has RetractableTo(Z) then
>         ground?(x) or
>          ((retractIfCan(x)@Union(Fraction(Z),"failed")) case Fraction(Z))
>       else
>         ground?(x)
> 
> (also, more importantly: iidsum, iidprod, ...)
> 
> so it seems that Bronstein thought already about allowing R's which do not have
> OrderedSet...

I think I should have said "Every domain in Axiom belonging to OrderedSet and
IntegralDomain SHOULD belong to RetractableTo Integer."  Since properties are
only declarative, there is no logical (automatic) derivation. So a domain that
declared it has OrderedSet and IntegralDomain may not have declared itself to
have RetractableTo Integer. Manuel was careful (and indeed forced to by the
strict type system) to use the "if R has RetractableTo(Z)" clause. But note that
Axiom does not check the mathematical validity of any declaration like these. 

Perhaps in Ring or Rng (catdef.spad), one should patch this:

  If R has CharacteristicZero then RetractableTo Integer.

(R does not have to be an integral domain, for example, R = Z[x]/(x^2).)

\start
Date: Sat, 19 Jun 2004 09:48:57 -0400
From: Tim Daly
To: William Sit, Martin Rubey, Manuel Bronstein
Subject: re: [Axiom-math] [Fwd: Re: EXPR POLY INT]

Bill, Martin, Manuel,

Could one/both/all of you summarize this discussion in some way?  I'd
like to apply the suggested code fragments/fixes to Axiom but I'm
somewhat confused.

Martin sent me some code. I integrated the first piece but you've
asked me to wait until you added test cases. Then you sent me
additional code. What are your expectations of my actions?

Bill has suggested possible fixes and further improvements but Manuel
has suggested different fixes.

I've been reading the thread in order to glean the required changes to
Axiom but I've ended up confused as to what I'm expected to do. I'm
quite pleased with the suggestions but lost in the expectations.

Please try to summarize this so I don't lose the changes.

\start
Date: Sat, 19 Jun 2004 11:23:09 -0400
From: Tim Daly
To: Jelena i Zoran
Subject: Re: [Axiom-mail] Compiling Axiom

>>>I compiled axiom at work using Red Hat Fedora Core 2 without any problems.
>>>Axiom does not run when I type "axiom". It returns "Could not find a 
>>>free pty" instead.
>>>      
>>>
>>I have experienced this same problem a few days ago while installing
>>Axiom on a fresh Mandrake 10 system. I am not very familiar with the
>>Mandrake or Redhat distros, but I know they have been fairly similar
>>in the past. Perhaps this fix will work for you. You probably have
>>restrictive permissions for the pty devices under /dev/pty. Try giving
>>yourself read/write access (the error is coming from clef, the Axiom
>>rewrite of GNU Readline, which explains why you do not see the same
>>problem when executing AXIOMsys).

> Steve's suggestion did not work for me. If /dev/pty refers to pty
> directory inside dev directory, then I do not have that directory on
> my Fedora Core 2 installation.  However there a lot of devices that
> start with pty in /dev directory and changing permission of those made
> no difference for me.  What works for me is exporting
> AXIOM=/usr/local/axiom/mnt/linux in .bash_profile file and then
> including alias axiom='AXIOMsys' in .bashrc file. I guess, this is a
> standard technique and it works for a nonprogrammer like me.

AXIOMsys is the name of the actual executable image.
axiom is shell script that starts processes.
At the moment there is only one process, called clef, that we wrote
years ago. It acts like the GNU readline. AXIOMsys will work fine
without clef. Since I run axiom inside of emacs I don't need clef
but others find it useful.

It would be interesting to know some more details about your system.
That way I might be able to reproduce the problem. If I can't reproduce
it I can't fix it. 

\start
Date: Sat, 19 Jun 2004 11:45:14 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom Book

CY,

> Just had a couple curosity questions for you concerning the Axiom
> book/manual.  
> 
> a)  I was wondering if there is some way for the book to take advantage
> of thinks like hyperlinking when producing a pdf?  I am able to use
> LaTeX + pdflatex to do this in the Maxima book but the Axiom book build
> seems to be integrated with the overall system build, so I'm not quite
> sure how to customize it.

Hyperlinks would be fine. I believe ADVI also supports hyperlinks.
The book.pamphlet file needs very little from the system in order
to build. This was part of the plan as you should be able to use
the book without having the system around. So it should be possible
to add 
\usepackage{hyper}
(or whatever hyperlinking package you have) and add hyperlinks.
If they were done in a way that didn't break the display of the
book under such tools as xdvi then I'd be happy to include any
hyperlinks you develop. Send me the changes and I'll try to 
incorporate them.

I'm a little concerned about pdf files, mostly because I haven't had
much luck getting the book properly formatted. My pdfs are fuzzy and
lack graphics.  Perhaps you will have more luck. I tend to stop at the
.dvi file.

David Mentre has done a pdf version.

I still have to return to working on the book as the graphics are
missing, the chapters need changes, and the appendix is broken. Just
this week, while working on the second book, I figured out how to use
pstricks, which was suggested to me much earlier but I haven't gotten
to it until now.

> 
> b)  Is there any progress on plans to have someone like O'Reilly to
> publish a hard copy of the book?  Online pdfs are good for a quick
> check of something, but I know I for one would shell out a few $$ (once
> I get some anyway) to have a bound paper copy.  Did anybody ever
> contact Oreilly to see if they might be interested?

The book already exists in a much better version. 

Jenks, Richard D., Sutor Robert S. 
Axiom -- The Scientific Computation System
ISBN 0-387-97855-0
ISBN 3-540-97855-0

Search for it on amazon, using the keywords "Axiom Jenks".
It is about 1/2 price on the used list. And, no, I don't 
get royalties :-)

I'd love for O'Reilly or Baen or Dover to publish it but that's
yet another hill to climb. I've tried to publish two textbooks
before and it's a lot more effort than it would seem. There is
no such thing as a simple job.

However, anyone on the list is free and welcome to try to publish
it. The book text is covered by the modified BSD license that NAG
used to release the sources. The additional words I've written are
also under the same license. So anyone with a touch of ambition is
free to take it, put their name on the cover, and publish it. I'd
even be willing to help but I can't take the lead in the effort.
I've got way too many things that are "top of stack" right now.

\start
Date: Sat, 19 Jun 2004 09:51:27 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Axiom Book

--- Tim Daly wrote:

> The book.pamphlet file needs very little from the system in order
> to build. This was part of the plan as you should be able to use
> the book without having the system around. 

It might be useful from a user standpoint to have a "make book" option
where they can just type that in the top level directory and have the
build logic for the book kick in.  A minor point but it does make
things a little more user friendly. 

I hate to ask this because I'm quite sure it's a stupid question, but
how does the book.pamphlet file differ from regular latex?  If I were
organizing it my instinct would be to break it down into individual
latex files for each chapter, to make things more managable, but I'm
assuming there's a reason for everything being in one file due to the
pamphlet superstructure.

> If they were done in a way that didn't break the display of the
> book under such tools as xdvi then I'd be happy to include any
> hyperlinks you develop. Send me the changes and I'll try to 
> incorporate them.

There are ways, at least in regular latex, to conditionalize things
like  \usepackage statements.  If that can function in the pamphlet
environment than unless a pdf is being created latex won't even mess
with the other stuff.  I'll see if I can take a stab at it.

> I'm a little concerned about pdf files, mostly because I haven't had
> much luck getting the book properly formatted. My pdfs are fuzzy and
> lack graphics.  Perhaps you will have more luck. I tend to stop at
> the ..dvi file.

Fuzzy?  Do you mean poor fonts?  As far as graphics go...  there are
some things that can be done, but for the maxima book we have two
copies of all graphics - ps and png I believe are the formats we use. 
(Which reminds me - I need to check if a pdf graphic option would be
better.)  Did you want to have only one version of a graphic that is
handled at runtime?

> David Mentre has done a pdf version.

Oh, he might have done most of this already then :-).  Archive time.

> I still have to return to working on the book as the graphics are
> missing, the chapters need changes, and the appendix is broken. 

Ah yes, graphics.  That reminds me - what are Axiom's eventual plans
for graph output?  Does Axiom have its own internal code, or will it
need to use something like gnuplot?  I think this was discussed a long
time back on the list but I was curious if any decisions have been
reached.

> Just
> this week, while working on the second book, I figured out how to use
> pstricks, which was suggested to me much earlier but I haven't gotten
> to it until now.

Second book?  There's another one?  (/me turns green with envy.)

> I'd love for O'Reilly or Baen or Dover to publish it but that's
> yet another hill to climb. I've tried to publish two textbooks
> before and it's a lot more effort than it would seem. There is
> no such thing as a simple job.

A textbook is a little different though, isn't it?  The Axiom book has
the potential to sell to anyone wanting to use it for research or
teaching (or some crazy hobbiest ;-)  but a textbook goes nowhere
unless people actually use it for a course.  Where there are a lot of
books for most courses (lower level ones anyway) there aren't very many
competitors in the Axiom documentation department.  Not that that
necessarily means the total sales would be greater, of course, but
perhaps reason to hope.
 
> However, anyone on the list is free and welcome to try to publish
> it. The book text is covered by the modified BSD license that NAG
> used to release the sources. The additional words I've written are
> also under the same license. So anyone with a touch of ambition is
> free to take it, put their name on the cover, and publish it. I'd
> even be willing to help but I can't take the lead in the effort.
> I've got way too many things that are "top of stack" right now.

Know what that's like.  Probably the time to look into that sort of
thing will be more when Axiom is reaching a "polished, 1.0" status
where we can package it and market it to non-developers.  The curse of
books/releases is they take on a life of their own - people get used to
that particular release and are disinclined to change.  Of course, this
is less of a problem when the updates don't cost $300+ :-).

If such an event does come to pass, and does make some money, is there
some mechanism where the publisher/person(s) who made it happen could
funnel some part of the profits back to the Axiom development effort? 
If open Axiom ever does somehow produce funding or revenue, I don't
think anyone would doubt that a lot of it should be sent Tim Daly's
way.

\start
Date: Sat, 19 Jun 2004 19:02:33 +0200
From: David Mentre
To: Tim Daly
Subject: re: Axiom Book

Hello,

Tim Daly writes:

>> a)  I was wondering if there is some way for the book to take advantage
>> of thinks like hyperlinking when producing a pdf?  I am able to use
>> LaTeX + pdflatex to do this in the Maxima book but the Axiom book build
>> seems to be integrated with the overall system build, so I'm not quite
>> sure how to customize it.

Look in axiom sources : src/doc/book.pamphlet is the latex source of the
book. It can be compiled with latex ou pdflatex without any issues
(except graphics for pdflatex).

> \usepackage{hyper}
> (or whatever hyperlinking package you have) and add hyperlinks.

The correct command is:
\usepackage{hyperref}

> If they were done in a way that didn't break the display of the
> book under such tools as xdvi then I'd be happy to include any
> hyperlinks you develop. Send me the changes and I'll try to 
> incorporate them.
>
> I'm a little concerned about pdf files, mostly because I haven't had
> much luck getting the book properly formatted. My pdfs are fuzzy and
> lack graphics.  Perhaps you will have more luck. I tend to stop at the
> .dvi file.

Because you haven't used pdflatex command. ;)

> David Mentre has done a pdf version.

Unfortunatly without graphics. I just ran pdflatex on the book.pamphlet
file. 

\start
Date: Sat, 19 Jun 2004 19:27:07 +0200
From: David Mentre
To: Cliff Yapp
Subject: re: Axiom Book

Hello,

Cliff Yapp writes:

> I hate to ask this because I'm quite sure it's a stupid question, but
> how does the book.pamphlet file differ from regular latex?

In no way for book.pamphlet.

>  If I were organizing it my instinct would be to break it down into
> individual latex files for each chapter, to make things more
> managable, but I'm assuming there's a reason for everything being in
> one file due to the pamphlet superstructure.

As far as I recall, noweb (for noweb -> latex conversion) can only
manage one file at a time. It does not handle tex input files.

> There are ways, at least in regular latex, to conditionalize things
> like  \usepackage statements.  If that can function in the pamphlet
> environment than unless a pdf is being created latex won't even mess
> with the other stuff.  I'll see if I can take a stab at it.

I think the most important point regarding the book is to have the
graphics incorporated correctly in the pdf version.

> Fuzzy?  Do you mean poor fonts?  As far as graphics go...  there are
> some things that can be done, but for the maxima book we have two
> copies of all graphics - ps and png I believe are the formats we use. 
> (Which reminds me - I need to check if a pdf graphic option would be
> better.)  Did you want to have only one version of a graphic that is
> handled at runtime?

Right now, the graphics are in eps format (but with no bounding boxes in
some cases. It blocks me to convert the graphics to pdf. However I'm for
from a postscript specialist). From an engineering point of view, the
best solution would be to have the reference graphic in one format that
can be translated in needed formats by the Makefile.

>> David Mentre has done a pdf version.
>
> Oh, he might have done most of this already then :-).  Archive time.

:) Just pdflatex.

> Ah yes, graphics.  That reminds me - what are Axiom's eventual plans
> for graph output?  Does Axiom have its own internal code, or will it
> need to use something like gnuplot?

If I remember correctly, Tim is resurrecting Axiom's original graphics
code. 

> Probably the time to look into that sort of thing will be more when
> Axiom is reaching a "polished, 1.0" status where we can package it and
> market it to non-developers.

Regarding the 1.0 status, the lacking points are:

 1. Axiom book in PDF with graphics; 

    [done for pdf. Nobody is working on the graphics]

 2. Define if the current found bugs are release critical or not. If
    yes, fix them. If not, document them (and reduce the priority in the
    1-3 range);

    [nobody is working on the bugs, except martin and william]

 3. Have a wroking graphics module.

    [I think tim is working on this]


\start
Date: Sat, 19 Jun 2004 19:30:37 +0200
From: David Mentre
To: Martin Rubey
Subject: New bugs you found

Hello Martin,

I've just discovered that I was removed from the email announcements of
new bugs. That's why there was no feedback on your bug reports.

\start
Date: Sat, 19 Jun 2004 18:13:28 +0200 (CEST)
From: Bertfried Fauser
To: David Mentre
Subject: re: Axiom Book

Hi,

	it is fairly easy to create a pdf file having graphics in it _and_
using reasonable pdf fonts. A colleague of mine used a makefile to produce
his PhD thesis, I had sent a copy to Tim. The main point is to go as
follows:

1) use ordinary latex
2a) use dvips to produce ordinary ps-files (including graphics)
2b) use dvips with differnt options to produce a ps-file prepared to be
    translated into pdf (including graphics)
3) use ps2pdf (and some other goodies if wanted) to produce a pdf (having
   tubnails etc)

Note that pdflatex has problems with certain latex styles, eg pstricks.
There are pstricks somethings for pdflatex, but then you have two latex
files, one for producing dvi and one for directly producing pdf via
pdflatex.

------------------------------------------------------
An example which I use for a local project looks like:
------------------------------------------------------

# name of main tex file
MAINTEXFILE = Bbook
# possibly path to latex
LATEX = latex

all: dvi pspdf

world: dvi pdf ps

clean:
	rm -f ${MAINTEXFILE}.dvi ${MAINTEXFILE}.ps ${MAINTEXFILE}.pdf ${MAINTEXFILE}.aux \
		${MAINTEXFILE}.log ${MAINTEXFILE}.lof ${MAINTEXFILE}.toc ${MAINTEXFILE}.tpm\
		${MAINTEXFILE}.bbl ${MAINTEXFILE}.blg ${MAINTEXFILE}.ind ${MAINTEXFILE}.idx\
		${MAINTEXFILE}.ilg ${MAINTEXFILE}.out ${MAKEFILE}.bak *.log BF_book_2004.pdf

dvi: ${MAINTEXFILE}.dvi

pdf: ${MAINTEXFILE}-fromps.pdf

pspdf: ${MAINTEXFILE}-fromps.pdf

ps: ${MAINTEXFILE}.ps

${MAINTEXFILE}.dvi: ${MAINTEXFILE}.tex ${MAINTEXFILE}.bbl ${MAINTEXFILE}.ind
	${LATEX} ${MAINTEXFILE}.tex
	${LATEX} ${MAINTEXFILE}.tex

${MAINTEXFILE}.bbl: sql.bib
	${LATEX} ${MAINTEXFILE}.tex
	bibtex ${MAINTEXFILE}

${MAINTEXFILE}.ind: ${MAINTEXFILE}.idx
	${LATEX} ${MAINTEXFILE}.tex
	makeindex ${MAINTEXFILE}

# 	see especially the options to dvips & ps2pdf
${MAINTEXFILE}-fromps.pdf: ${MAINTEXFILE}.dvi
	dvips -Ppdf -G0 ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
	ps2pdf -sPAPERSIZE=a4 -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 \
		-dSubsetFonts=true -dEmbedAllFonts=true ${MAINTEXFILE}.ps \
		 ${MAINTEXFILE}.pdf
#	new dvips and ps2pdf version (ghostscript 3.??) produces
#	thumbnails automatically
#	thumbpdf --modes=dvips ${MAINTEXFILE}.pdf
	${LATEX} ${MAINTEXFILE}.tex
	dvips -Ppdf -G0 ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
#	timestamp (program not on my solaris box, havn't tested)
#	pdftime ${MAINTEXFILE}.ps
	ps2pdf -sPAPERSIZE=a4 -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 \
		-dSubsetFonts=true -dEmbedAllFonts=true ${MAINTEXFILE}.ps \
		 ${MAINTEXFILE}.pdf
#	'publish' the pdf file
	mv ${MAINTEXFILE}.pdf BF_book_2004.pdf
	rm ${MAINTEXFILE}.ps
	dvips ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps

${MAINTEXFILE}.ps: ${MAINTEXFILE}.dvi
	dvips ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps

\start
Date: Sat, 19 Jun 2004 14:36:37 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom Book

> It might be useful from a user standpoint to have a "make book" option
> where they can just type that in the top level directory and have the
> build logic for the book kick in.  A minor point but it does make
> things a little more user friendly. 

This I can do.

> I hate to ask this because I'm quite sure it's a stupid question, but
> how does the book.pamphlet file differ from regular latex?  If I were
> organizing it my instinct would be to break it down into individual
> latex files for each chapter, to make things more managable, but I'm
> assuming there's a reason for everything being in one file due to the
> pamphlet superstructure.

It was previously in dozens of files. I could break it up but why?
The individual chapters would still need the tex superstructure.
I could use David's booklet program (my original thought and still
a long term plan) but that would require noweb.

> There are ways, at least in regular latex, to conditionalize things
> like  \usepackage statements.  If that can function in the pamphlet
> environment than unless a pdf is being created latex won't even mess
> with the other stuff.  I'll see if I can take a stab at it.

Ok. Let me know what you come up with.

> Fuzzy?  Do you mean poor fonts?  As far as graphics go...  there are
> some things that can be done, but for the maxima book we have two
> copies of all graphics - ps and png I believe are the formats we use. 
> (Which reminds me - I need to check if a pdf graphic option would be
> better.)  Did you want to have only one version of a graphic that is
> handled at runtime?

The graphics files are .ps format since the Axiom graphics program can
output them directly. If we mod the graphics program to output other
formats then that might be of interest but not currently.

> Oh, he might have done most of this already then :-).  Archive time.

The pdf version of the book is available from David's site.
I don't have the URL handy but it's in the archives.
Or send him a note. He's very helpful.

> Ah yes, graphics.  That reminds me - what are Axiom's eventual plans
> for graph output?  Does Axiom have its own internal code, or will it
> need to use something like gnuplot?  I think this was discussed a long
> time back on the list but I was curious if any decisions have been
> reached.

The graphics code compiles now and I'm working on viewAlone which is a
program to test the graphics in stand-alone mode. Once that works I need
to get viewman running and then the socket connection running. The 
graphics code talks to axiom thru sockets. (It all takes time, massive
amounts of time, unfortunately).

> Second book?  There's another one?  (/me turns green with envy.)

Yes, there is another one in the pipe. The initial motivation comes
from Littlewood's book "The skeleton key of mathematics". I'm buried
in the writing at the moment. The first draft will be posted in a
while and I'll let the list know so they can critique/modify/add to it.
This one is harder because I'm trying to attack the math following
Axiom's categorical structure and there is an astonishing amount I
don't know about either math or Axiom's categorical structure. All
of which will be evident when the book emerges and the real experts
weigh in. :-)

> A textbook is a little different though, isn't it?  The Axiom book has
> the potential to sell to anyone wanting to use it for research or
> teaching (or some crazy hobbiest ;-)  but a textbook goes nowhere
> unless people actually use it for a course.  Where there are a lot of
> books for most courses (lower level ones anyway) there aren't very many
> competitors in the Axiom documentation department.  Not that that
> necessarily means the total sales would be greater, of course, but
> perhaps reason to hope.

I wrote 120 pages of one textbook and 90 pages of another. (Figure that
each page is 500 words and takes about 1 day to write (remember that 
you occasionally have to delete stuff)). I had contract negotiations
with two different publishers and even had an editor assigned to my
effort. Textbooks that sell more than 3000 copies are considered a
best seller. It rarely happens so I'm told.

> Know what that's like.  Probably the time to look into that sort of
> thing will be more when Axiom is reaching a "polished, 1.0" status
> where we can package it and market it to non-developers.  The curse of
> books/releases is they take on a life of their own - people get used to
> that particular release and are disinclined to change.  Of course, this
> is less of a problem when the updates don't cost $300+ :-).
> 
> If such an event does come to pass, and does make some money, is there
> some mechanism where the publisher/person(s) who made it happen could
> funnel some part of the profits back to the Axiom development effort? 
> If open Axiom ever does somehow produce funding or revenue, I don't
> think anyone would doubt that a lot of it should be sent Tim Daly's
> way.

There isn't a whole lot of money to be made. By the time the publisher,
the bookstore, the girlfriend, etc take their cut you'd be happy to buy
coffee. But you'd have a book with your name on the cover and that's
worth something.

\start
Date: Sat, 19 Jun 2004 17:18:21 -0700 (PDT)
From: Cliff Yapp
To: David Mentre
Subject: re: Axiom Book

--- David Mentre wrote:
> As far as I recall, noweb (for noweb -> latex conversion) can only
> manage one file at a time. It does not handle tex input files.

OK.  Not critical.
 
> I think the most important point regarding the book is to have the
> graphics incorporated correctly in the pdf version.

I have looked at this.  I think what will have to be done is update the
commands which are loading the graphics files to use includegraphics
instead of the current oddness.  For example:

\begin{figure}[htbp]
\begin{picture}(324,168)%(-54,0)
\special{psfile=ps/h-matsource.ps}
\end{picture}
\caption{Source code for {\tt Matrix}.}
\end{figure}

This special command doesn't seem to be well suited to pdf and ps joint
usage. If I strip the special stuff out, I can include some of the
graphics. Hyperref works fine, and produces a hyperlinked pdf.  The
Bibliography upsets it for some reason - I think we need to modernize
something there - but other than that I get chapter organization and
everything.  I had to remove the setcounter{chapter} entries, however,
to get reasonable behavior in that department. 

I have uploaded a hacked up version of book.pamphlet and the pdf
created here:

http://garnetlisp.sf.net/axiom/book.pamphlet
http://garnetlisp.sf.net/axiom/book.pdf

> Right now, the graphics are in eps format (but with no bounding 
> boxes in some cases. It blocks me to convert the graphics to pdf.
> However I'm for from a postscript specialist). From an engineering
> point of view, the best solution would be to have the reference 
> graphic in one format that can be translated in needed formats by 
> the Makefile.

In order to generate reasonable pdfs from the old ps images (the
bounding box problem) I used eps2eps to clean up the images, and then
epstopdf to make pdf images.  There were several images where eps2eps
failed with a ghostscript error - those might have to be remade since
if eps2eps fails it's usually difficult to do anything reasonable with
them, in my experience.  Perhaps these are also the ones commented out?

If a couple script files are written to automate the conversions, it
shouldn't be hard to reference the eps files for everything, given no
ghostscript errors.
 
> Regarding the 1.0 status, the lacking points are:
> 
>  1. Axiom book in PDF with graphics; 
> 
>     [done for pdf. Nobody is working on the graphics]

If we can use straight includegraphics that will solve 90% of the
graphics problems.  Conversion should be doable except for the ones
throwing postscript errors, which will have to be redone.
 
>  2. Define if the current found bugs are release critical or not. If
>     yes, fix them. If not, document them (and reduce the priority in
>     the 1-3 range);

Is the lack of a replacement for the NAG numerical libraries a release
stopper?  (I seem to remember some mention of the GNU scientific
libraries being possible replacements, but I don't know much more about
it.)

\start
Date: Sat, 19 Jun 2004 22:22:12 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom Book

Actually the booklet program can join multiple pamphlet files. 
It allows you to make chunks with a protocol and a URI:
<<pamphlet://foo/bar/baz.pamphlet>>

I didn't use it because I wanted the book to be pure latex, at least
until I was ready to do further integration work into the system
which won't be for a while yet.

> I have looked at this.  I think what will have to be done is update the
> commands which are loading the graphics files to use includegraphics
> instead of the current oddness.  For example:
> 
> \begin{figure}[htbp]
> \begin{picture}(324,168)%(-54,0)
> \special{psfile=ps/h-matsource.ps}
> \end{picture}
> \caption{Source code for {\tt Matrix}.}
> \end{figure}

The "current wierdness", as you say, is my attempt at graphics in latex
which I've never tried before. The key annoyance is that I've been
unable to get two images on the same page. 

> This special command doesn't seem to be well suited to pdf and ps joint
> usage. If I strip the special stuff out, I can include some of the
> graphics. Hyperref works fine, and produces a hyperlinked pdf.  The
> Bibliography upsets it for some reason - I think we need to modernize
> something there - but other than that I get chapter organization and
> everything.  I had to remove the setcounter{chapter} entries, however,
> to get reasonable behavior in that department. 

I'll look at what you did and try to copy it. 
 
> I have uploaded a hacked up version of book.pamphlet and the pdf
> created here:
> 
> http://garnetlisp.sf.net/axiom/book.pamphlet
> http://garnetlisp.sf.net/axiom/book.pdf

I've downloaded both. The pdf looks good and the graphics are
embedded properly. If I can fully understand what you (and BF and
David) have been trying to tell me about pdfs I might start 
autogenerating them in the doc directory.
> 
> > Right now, the graphics are in eps format (but with no bounding 
> > boxes in some cases. It blocks me to convert the graphics to pdf.
> > However I'm for from a postscript specialist). From an engineering
> > point of view, the best solution would be to have the reference 
> > graphic in one format that can be translated in needed formats by 
> > the Makefile.
> 
> In order to generate reasonable pdfs from the old ps images (the
> bounding box problem) I used eps2eps to clean up the images, and then
> epstopdf to make pdf images.  There were several images where eps2eps
> failed with a ghostscript error - those might have to be remade since
> if eps2eps fails it's usually difficult to do anything reasonable with
> them, in my experience.  Perhaps these are also the ones commented out?

I ran into the bounding box problem also. I did add bounding boxes to
most of the images I used but it was tedious.

> If a couple script files are written to automate the conversions, it
> shouldn't be hard to reference the eps files for everything, given no
> ghostscript errors.
>  
> > Regarding the 1.0 status, the lacking points are:
> > 
> >  1. Axiom book in PDF with graphics; 
> > 
> >     [done for pdf. Nobody is working on the graphics]
> 
> If we can use straight includegraphics that will solve 90% of the
> graphics problems.  Conversion should be doable except for the ones
> throwing postscript errors, which will have to be redone.

I'll have a look at where I was on the graphics chapter and see if
your technique will break the logjam holding things up.
 
> >  2. Define if the current found bugs are release critical or not. If
> >     yes, fix them. If not, document them (and reduce the priority in
> >     the 1-3 range);
> 
> Is the lack of a replacement for the NAG numerical libraries a release
> stopper?  (I seem to remember some mention of the GNU scientific
> libraries being possible replacements, but I don't know much more about
> it.)

I've also been working on this. I have imported the BLAS routines, 
converted them to pamphlet files, automated the build, and am now
looking at the machinery necessary to add them to the GCL lisp image
automatically. This is the first of multiple layers of numeric code
but the first layer is always the hardest because I have to break
new ground (at least for me).

\start
Date: Sat, 19 Jun 2004 22:25:49 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom Book

CY,

What was the problem with the bibligraphy?

\start
Date: Sat, 19 Jun 2004 20:24:44 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Axiom Book

--- Tim Daly wrote:
> Actually the booklet program can join multiple pamphlet files. 
> It allows you to make chunks with a protocol and a URI:
> <<pamphlet://foo/bar/baz.pamphlet>>
> 
> I didn't use it because I wanted the book to be pure latex, at least
> until I was ready to do further integration work into the system
> which won't be for a while yet.

It's not really needed.  I think the reason I organized maximabook that
way was because there was a question of whether some parts should be
part of another book, and with discrete pieces and a control file all
someone had to do was tweak the control file and they could get a book
with just the parts they wanted in it. 

> The "current wierdness", as you say, is my attempt at graphics in
> latex which I've never tried before. The key annoyance is that 
> I've been unable to get two images on the same page. 

Opps :-).  Sorry - it was just that I was unfamiliar with that style of
figure insertion. I thought someone had tweaked it for publishing
purposes or some such :-).

There is an includegraphics flag to force an image to be in a certain
place relative to some text, IIRC.  If you need that I can try and dig
it up.

> I'll look at what you did and try to copy it. 

Well, most of what I did was basically hack and slash.  You might want
to check if that file works with the ps files - in theory it should,
but I didn't put it through the full run.
  
> I've downloaded both. The pdf looks good and the graphics are
> embedded properly. If I can fully understand what you (and BF and
> David) have been trying to tell me about pdfs I might start 
> autogenerating them in the doc directory.

It shouldn't be too hard, given the presence of gs on the system
building it.  I don't know what to do about the ones that give errors
though.
 
> I ran into the bounding box problem also. I did add bounding boxes to
> most of the images I used but it was tedious.

They might prove better than the autoconverted ones though.

\start
Date: Sun, 20 Jun 2004 11:52:34 +0200
From: David Mentre
To: Cliff Yapp
Subject: Re: Axiom Book

Cliff Yapp writes:

> I have uploaded a hacked up version of book.pamphlet and the pdf
> created here:
>
> http://garnetlisp.sf.net/axiom/book.pamphlet
> http://garnetlisp.sf.net/axiom/book.pdf

Very nice work. I haven't read the whole book but the few pages I've
looked at are very nice. And the first page is rendererd well this time!
:) 

Looking at table of content, I find numbering starting at 0 strange (for
a book ;). Tim, is it you who have introduced following latex code?

  \pseudoChapter{Introduction to Axiom}

If it's you, what is the rationale? I suppose you did not want to
disturb original book chapter numbering? Should we use a different
numbering style (roman?) or a different typesetting? (ok, I admit, it is
a rather minor point)



Regarding book content, I would propose to add:

 - a (sub)section on TeXmacs (in section 1.1) (starting an Axiom session
   in TeXmacs, pitfalls that users have encountered regarding multi-line
   input);

 - a section on electronic contacts (web sites, mailing-list, wikis,
   community, etc.);

 - an appendix on Axiom compilation (at least pointers on the source
   code part to look at in order to compile Axiom).

What do you think of it? I volunteer to write the first draft of them.

\start
Date: Sun, 20 Jun 2004 13:16:22 +0200
From: David Mentre
To: list
Subject: Todo list for 1.0 stable release

Hello,

I propose to maintain a list of things to do towards our stable 1.0
release. Let me know what do you think of it.

I would personally consider that the biding to numerical libraries is
not release critical.

http://www.linux-france.org/~dmentre/axiom/release-1.0/todo-list-for-1.0.html


To do list for free Axiom "1.0" stable release

1 Release critical items

Those items should be fixed for the next stable release.

   1.

      Axiom Book in PDF format. Proofreading of the book

      [CY, david, tim are working on it]
   2.

      Resurrection of graphics package

      [tim]
   3.

      Resurrection of biding to numerical libraries

      [tim]
   4.

      Fix all release critical bugs (Severity 5 and above). Reduce Severity if not release critical.

      http://savannah.nongnu.org/bugs/?group=axiom

      [martin, william]
   5.

      Document non release critical bugs (errata list with workarounds)

      [?]
   6.

      Find a release number

      [tim]

2 Non release critical items

Those points do not prevent a stable release, but it would be a bonus to have them.

   1.

      Incorporate Martin Rubey "guessing formula for sequence" algebra code

      [tim]


\start
Date: Sun, 20 Jun 2004 13:19:57 +0200
From: David Mentre
To: Gregory Vanuxem
Subject: Re: Complex exponentiation and 0

Grgory,

Vanuxem Grgory Gregory Vanuxem writes:

> In complex(Float) and Complex(SingleFloat), we have to change the
> exponentiation so that
> 	complex(0,0)^complex(0,0.0)
> or
> 	complex(0,0)^complex(2,2.0)
> doesn't use log.
>
> if (real(x) = 0 and imag(x) = 0)
> 	if (real(power)=0 and  imag(power)=0)
> 		complex(1.0,0.0)
>  	else
> 		complex(0.0,0.0)
> else
> 	...

Is your bug report related to:
  [bugs #9313] 0^0 handled inconsistently
  http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9313

According to Martin comment, 0^0 is not mathematically defined.

\start
Date: Sun, 20 Jun 2004 09:45:25 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Axiom Book

> Looking at table of content, I find numbering starting at 0 strange (for
> a book ;). Tim, is it you who have introduced following latex code?
> 
>   \pseudoChapter{Introduction to Axiom}
>
> If it's you, what is the rationale? I suppose you did not want to
> disturb original book chapter numbering? Should we use a different
> numbering style (roman?) or a different typesetting? (ok, I admit, it is
> a rather minor point)
> 

There is a way to restart page numbering in TeX but I forget what the
magic code is. The \pseudoChapter tags are in the original. I didn't
add them. I did manipulate them to try to keep the original chapter
order but that's no longer important.

> 
> 
> Regarding book content, I would propose to add:
> 
>  - a (sub)section on TeXmacs (in section 1.1) (starting an Axiom session
>    in TeXmacs, pitfalls that users have encountered regarding multi-line
>    input);
> 
>  - a section on electronic contacts (web sites, mailing-list, wikis,
>    community, etc.);
> 
>  - an appendix on Axiom compilation (at least pointers on the source
>    code part to look at in order to compile Axiom).
> 
> What do you think of it? I volunteer to write the first draft of them.

I'd be happy to see additional work done on the book. 

\start
Date: Sun, 20 Jun 2004 15:25:11 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Axiom Book

Hi Tim,

Tim Daly writes:

> There is a way to restart page numbering in TeX but I forget what the
> magic code is.

\pagenumbering{/style/} with /style/ in {roman, Roman, arabic, alph,
Alph}. 

I'm not sure however resetting the page number is a good idea. I
personally hate books with several pages having the same page number. 

> The \pseudoChapter tags are in the original. I didn't
> add them. I did manipulate them to try to keep the original chapter
> order but that's no longer important.

Ok. I would then advise to replace:

\pseudoChapter{Introduction to Axiom}

By:
\chapter{Introduction to Axiom}


As well as:
\pseudoChapter{A Technical Introduction}

by:
\chapter{A Technical Introduction}

\start
Date: Sun, 20 Jun 2004 14:11:49 +0200 (CEST)
From: Bertfried Fauser
To: David Mentre
Subject: Re: Axiom Book

On Sun, 20 Jun 2004, David Mentre wrote:

> \pagenumbering{/style/} with /style/ in {roman, Roman, arabic, alph,
> Alph}.

This does change the _style_ of the page numbering. If you change the
style you might want to start again by 1 with the new style, so
additionally one needs to reset the counter

\setcounter{page}{1}
	% might be zero, depending if the increment is done
	% before the use or afterwards, cannot rememner

hence you can number preface as

\setcounter{page}{1}
\pagenumbering{Roman}
 ... text...

with pagenumber like I,II,III,IV,V, ...XXI, ... (roman would result in
i,ii,iii,iv,...)

then do

\setcounter{page}{1}
\pagenumbering{arabic}

and the result is 1,2,3, as expected

by teh way, chapter can be renumbered the same way, hence on can start
with chapter 0 by setting

\setcounter{chapter}{0}

the style of a counter can be changed directly by redefining the
"\the<countername>" command.

GRAPHICS:


\usepackage{graphics} %\graphicspath{{pics/}} % sets a searchpath for graphics

includes a graphic, size can be defined and teh picture will be scaled to
this size, so more than one picture (without bonding box may be) can be
placed on one page

\parbox{0.5\textwidth}{%
\hfil
\includegraphics[height=3.5cm]{foo.eps}
\hfil}

\start
Date: Sun, 20 Jun 2004 06:56:54 -0700 (PDT)
From: Cliff Yapp
To: David Mentre
Subject: Re: Axiom Book

--- David Mentre wrote:
> Cliff Yapp writes:
> 
> > I have uploaded a hacked up version of book.pamphlet and the pdf
> > created here:
> >
> > http://garnetlisp.sf.net/axiom/book.pamphlet
> > http://garnetlisp.sf.net/axiom/book.pdf
> 
> Very nice work. I haven't read the whole book but the few pages I've
> looked at are very nice. And the first page is rendererd well this
> time!
> :) 

Thanks :-).

> Looking at table of content, I find numbering starting at 0 strange
> (for a book ;). Tim, is it you who have introduced following latex
> code?
> 
>   \pseudoChapter{Introduction to Axiom}
> 
> If it's you, what is the rationale? I suppose you did not want to
> disturb original book chapter numbering? Should we use a different
> numbering style (roman?) or a different typesetting? (ok, I admit, it
> is a rather minor point)

Roman for the intro would be cool :-).  Unfortunately I have no idea
how to do that.

> Regarding book content, I would propose to add:
> 
>  - a (sub)section on TeXmacs (in section 1.1) (starting an Axiom
>    session in TeXmacs, pitfalls that users have encountered 
>    regarding multi-line input);

I would say that is good, but before commiting the pitfalls to paper
perhaps the thing to do is see if they can be corrected :-).

>  - a section on electronic contacts (web sites, mailing-list, wikis,
>    community, etc.);

Good - as an appendix probably?

>  - an appendix on Axiom compilation (at least pointers on the source
>    code part to look at in order to compile Axiom).

Not a bad idea - best thing to do is organize it by operating system. 
I suspect the eventual Windows build docs will look rather different
from the Linux ones.

> What do you think of it? I volunteer to write the first draft of
> them.

I'd say go for it, but we'll see what Tim says :-).

\start
Date: Sun, 20 Jun 2004 17:10:58 +0200
From: David Mentre
To: Cliff Yapp
Subject: Re: Axiom Book

--=-=-
Cliff Yapp writes:

> Roman for the intro would be cool :-).  Unfortunately I have no idea
> how to do that.

\pagenumbering{roman} % see also Bertfried joint comments

>> Regarding book content, I would propose to add:
>> 
>>  - a (sub)section on TeXmacs (in section 1.1) (starting an Axiom
>>    session in TeXmacs, pitfalls that users have encountered 
>>    regarding multi-line input);
>
> I would say that is good, but before commiting the pitfalls to paper
> perhaps the thing to do is see if they can be corrected :-).

Wrong english. It is not really a pitfall but a feature, I think
multi-line input follows TeXmacs habit.

>>  - a section on electronic contacts (web sites, mailing-list, wikis,
>>    community, etc.);
>
> Good - as an appendix probably?

I have included it as a plain chapter. I personally would like to insist
on the free software and community driven aspects of free Axiom.

>>  - an appendix on Axiom compilation (at least pointers on the source
>>    code part to look at in order to compile Axiom).
>
> Not a bad idea - best thing to do is organize it by operating system. 
> I suspect the eventual Windows build docs will look rather different
> from the Linux ones.

Right now, a small entry for Linux/Unix systems. I'll let other write
the Windows part. :) 

>> What do you think of it? I volunteer to write the first draft of
>> them.
>
> I'd say go for it, but we'll see what Tim says :-).

So here it is. Feel free to fix/update/comment.


--=-=-=

--- /home/david/pub/axiom-libre/GOLD/axiom/src/doc/book.pamphlet	2004-04-02 05:36:06.000000000 +0200
+++ book.pamphlet	2004-06-20 17:01:32.000000000 +0200
@@ -1,6 +1,7 @@
 \documentclass{book}
 %\usepackage{axiom}
 \usepackage{graphicx}
+\usepackage{url}
 % struggle with latex figure-floating behavior
 \renewcommand\floatpagefraction{.9}
 \renewcommand\topfraction{.9}
@@ -3526,6 +3527,7 @@
    2
    4
    6
+
 \end{verbatim}
 \returnType{Type: Void}
 
@@ -3583,6 +3585,7 @@
    [2,7]
    [3,6]
    [4,5]
+
 \end{verbatim}
 \returnType{Type: Void}
 
@@ -3601,6 +3604,68 @@
 General-Distributed-Mul-ti-var-iate-Poly-nomial
 }
 
+\chapter{Axiom and its electronic community}
+
+Axiom is now an OpenSource/Free Software project. It means that you are
+able to inspect its internal working, change it and make available the
+changes to the world.
+
+It also means that Axiom is now maintained and supported by a group of
+volunteers that can be joined through electronic means. It also means
+that you can join this group, at any time, for any purpose.
+
+\section{Web sites}
+
+The official Axiom web site is at:
+\url{http://www.nongnu.org/axiom/} 
+You'll find there latest Axiom news,
+information, tutorials and other pointers.
+
+The official Axiom development web site is at:\\
+\url{http://savannah.nongnu.org/projects/axiom/} 
+This web site is used
+by the Axiom developers to maintain and enhance Axiom, with usual
+development tools (CVS, mailing lists, bug tracking system, etc.). If
+you want to join the group of developer, it is recommended (but not
+mandatory) to open a Savannah account and the join the \texttt{axiom}
+project. 
+
+If you find a bug in Axiom, you are encouraged to fill a bug report on
+the Axiom bug reporting system at:\\
+\url{http://savannah.nongnu.org/bugs/?func=additem&group=axiom}\\
+Alternatively, you can send your bug report at
+\url{list}. 
+
+An experimental community driven collaborative web site, a.k.a. Wiki, as
+been setup at: \\
+\url{http://page.axiom-developer.org/zope/wiki/AxiomWiki} You are free
+to participate and enhance this web site. 
+
+\section{Mailing lists}
+
+Several mailing lists have been set up to obtain help or participate in
+Axiom development:
+
+\begin{description}
+\item [axiom-mail] For general discussion on Axiom. If you need help;
+
+\item [axiom-math] For general discussion on the mathematical aspects of
+  Axiom: math theory, philosophy and type system;
+  
+\item [axiom-developer] For discussion on the development of Axiom. If
+  you want to follow or participate in the improvement and extension of
+  Axiom;
+
+\item [axiom-legal] For discussion of all the legal aspects surrounding
+  Axiom. In case you have doubt how to reuse some of its component and
+  all other issues related to licensing.
+\end{description}
+
+All those mailing lists can be joined and their archives consulted on
+the Savannah web site at page:
+\url{http://savannah.nongnu.org/mail/?group=axiom}
+
+
 \chapter{An Overview of Axiom}
 \label{ugIntro}
 
@@ -3707,6 +3772,21 @@
 a name appears and it is not what you want, press {\bf Tab} again to
 see another name.
 
+\subsection{TeXmacs}
+
+If you are using Axiom under the X Window System, you can also interact
+with Axiom under the TeXmacs scientific editor (starting from version
+1.0.3). The main advantage of using TeXmacs is that you obtain a nice
+typesetting of Axiom output. Moreover you can copy/paste the output of
+an Axiom session into your article. TeXmacs web site is at:
+\url{http://texmacs.org/} 
+
+To start a new Axiom session, choose menu item
+Text$\rightarrow$Session$\rightarrow$Axiom.  You
+can then use Axiom as usual. One noticeable difference regards
+multi-line input, where one uses {\bf Shift}+{\bf Enter} to enter
+following line instead of ``\texttt{\_}''+{\bf Enter} for plain Axiom.
+
 You are ready to begin your journey into the world of Axiom.
 
 \section{Typographic Conventions}
@@ -59950,7 +60030,7 @@
 compilers.
 
 
-\setcounter{chapter}{0} % Appendix A
+\appendix
 
 \newcommand{\lanb}{{\tt [}}
 \newcommand{\ranb}{{\tt ]}}
@@ -62194,7 +62274,7 @@
 These commands return the state of the interactive
 environment to that immediately after step {\tt n}.
 If {\tt n} is a positive number, then {\tt n} refers to step nummber
-{\tt n}. If {\tt n} is a negative number, it refers to the \tt n-th
+{\tt n}. If {\tt n} is a negative number, it refers to the {\tt n-th}
 previous command (that is, undoes the effects of the last $-n$
 commands).
 
@@ -62328,8 +62408,6 @@
 {\tt )set} \index{ugSysCmdset}, and
 {\tt )show} \index{ugSysCmdshow}.
 
-\setcounter{chapter}{1} % Appendix B
-
 %\twocolumn[%
 \chapter{Categories}
 \label{ugAppCategories}
@@ -62355,7 +62433,7 @@
 $\hbox{{\rm op}}_{j}$ & is an operation exported by the category.
 \end{tabular}
 
-\appendix{Categories}
+%\appendix{Categories}
 %tpdclip2
 
 % ----------------------------------------------------------------------
@@ -62799,8 +62877,6 @@
 
 
 
-\setcounter{chapter}{2} % Appendix C
-
 %\twocolumn[%
 
 \chapter{Domains}
@@ -62827,7 +62903,7 @@
 $\hbox{{\rm op}}_{j}$ & is an operation exported by the domain.
 \end{tabular}
 
-\appendix{Domains}
+%\appendix{Domains}
 
 % ----------------------------------------------------------------------
 %\begin{constructorListing}
@@ -64043,8 +64119,6 @@
 
 
 
-\setcounter{chapter}{3} % Appendix D
-
 %\twocolumn[%
 \chapter{Packages}
 \label{ugAppPackages}
@@ -64070,7 +64144,7 @@
 $\hbox{{\rm op}}_{j}$ & is an operation exported by the package.
 \end{tabular}
 
-\appendix{Packages}
+%\appendix{Packages}
 
 % ----------------------------------------------------------------------
 %\begin{constructorListing}
@@ -64831,8 +64905,6 @@
 % ----------------------------------------------------------------------
 
 
-\setcounter{chapter}{4} % Appendix E
-%
 {
 %\twocolumn[%
 \chapter{Operations}
@@ -64847,7 +64919,7 @@
 
 \vskip \baselineskip
 %]
-\appendix{Operations}
+%\appendix{Operations}
 \def\alt#1#2{{$\lbrace$#1$\mid$#2$\rbrace$}}
 \def\altx#1#2#3{{$\lbrace$#1$\mid$#2$\mid$#3$\rbrace$}}
 \def\opt#1{{$\,\lbrack$#1$\rbrack$}}
@@ -64920,8 +64992,6 @@
 }\onecolumn
 
 
-\setcounter{chapter}{5} % Appendix F
-
 \chapter{Programs for AXIOM Images}
 \label{ugAppGraphics}
 
@@ -65665,12 +65735,53 @@
 
 {
 
-\setcounter{chapter}{6} % Appendix G
+
+\chapter{Compiling Axiom from sources}
+
+You can yourself compile Axiom from its source code. Here is a short
+note on to do it. We give the command for a Unix environment, with a
+korn shell compatible shell. For further details, look at the
+\texttt{README} file in Axiom sources or ask on the
+\url{list} mailing list. 
+
+\begin{description}
+
+\item [Getting the source]\ \\
+\begin{verbatim}
+$ export CVS_RSH="ssh"
+$ cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/axiom co axiom
+\end{verbatim}
+You then should have an \texttt{axiom/} directory with axiom source
+code.
+
+\item [Compiling the sources] Enter at a shell prompt:
+\begin{verbatim}
+$ cd axiom
+$ ./configure
+$ export AXIOM=`pwd`/mnt/linux
+$ make
+\end{verbatim}
+When the make completes you'll have an executable called
+\texttt{\$AXIOM/bin/axiom}. The compilation time is fairly long, it takes
+more than two hours on an Pentium 4 at 2 Ghz.
+
+\item [Installing Axiom]\ \\
+\begin{verbatim}
+$ make install
+\end{verbatim}
+This will put Axiom into \texttt{/usr/local/axiom}
+and the axiom command in \texttt{/usr/local/bin/axiom}.
+
+You can change these defaults to anything using:
+\begin{verbatim}
+make INSTALL=/home/me/myaxiom COMMAND=/home/me/bin/myaxiom install
+\end{verbatim}
+
+\end{description}
+
 \chapter{Glossary}
 \label{ugGlossary}
 
-\appendix{Glossary}
-
 \sloppy
 
 \ourGloss{\glossarySyntaxTerm{!}}{%
@@ -67589,7 +67700,6 @@
 
 \vfill
 \eject
-\setcounter{chapter}{7} % Appendix H
 \chapter{License}
 %\appendix{License}
 \begin{verbatim}


\start
Date: Sun, 20 Jun 2004 14:02:03 -0400
From: Bill Page
To: David Mentre
Subject: RE: Complex exponentiation and 0

On Sunday, June 20, 2004 7:20 AM David Mentre wrote:
> ... 
> Is your bug report related to:
>   [bugs #9313] 0^0 handled inconsistently
>   http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9313
> 
> According to Martin comment, 0^0 is not mathematically defined.
> 

Surely the definitions 0^0 = 1 and 0.0^0 = 1.0 are consistent (law
of exponents), no? That Axiom treats 0^(0.0) as undefined also seems
consistent to me since a floating point 0 is not identical to the
integer 0. But there is a problem with the error message
"protected-symbol-warn called with (NIL)".

\start
Date: Mon, 21 Jun 2004 12:19:45 +0000
From: Martin Rubey
To: list
Subject: RE: Complex exponentiation and 0

This should have gone to axiom-devel also...

Martin Rubey writes:
 > Bill Page writes:
 >  > On Sunday, June 20, 2004 7:20 AM David Mentre wrote:
 >  > > ... 
 >  > > Is your bug report related to:
 >  > >   [bugs #9313] 0^0 handled inconsistently
 >  > >   http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9313
 >  > > 
 >  > > According to Martin comment, 0^0 is not mathematically defined.
 >  > > 
 >  >
 > 
 > The problem is that the function f(x,y) = x^y is not continuous at x=y=0: 
 > 
 > (1) -> limit(x^y,y=0)
 > 
 >    (1)  1
 >                         Type: Union(OrderedCompletion Expression Integer,...)
 > (2) -> limit(x^y,x=0)
 > 
 >    (2)  "failed"
 > 
 > (which is correct, note that y might be less than (or equal to)
 > zero... Unfortunately, I see no way to tell axiom to assume y > 0 here. Such a
 > facility would be very nice.)
 > 
 > (3) -> limit(x^1,x=0)
 > 
 >    (3)  0
 > 
 > (very nice:)
 > 
 > (4) -> limit(x^(-1),x=0)
 > 
 >    (4)  [leftHandLimit= - infinity,rightHandLimit= + infinity]
 > 
 > Type: Union(Record(leftHandLimit: Union(OrderedCompletion Fraction Polynomial
 > Integer,"failed"),rightHandLimit: Union(OrderedCompletion Fraction Polynomial
 > Integer,"failed")),...)
 > 
 > ------------------------------------------------------------------------------
 > 
 > I think it's dangerous to say that 0^0=1, although it's natural in many cases:
 > 
 > http://db.uwaterloo.ca/~alopez-o/math-faq/mathtext/node14.html
 > 
 > In fact, I'm not sure what we would gain if axiom assumes 0^0=1 throughout. I
 > think, before we decide to adopt this strategy, we should have examples which
 > were otherwise cumbersome to deal with.
 > 
 > Maybe as a guide:
 > 
 > Mathematica 5.0 for Linux
 > Copyright 1988-2003 Wolfram Research, Inc.
 >  -- Motif graphics initialized -- 
 > 
 > In[1]:= 0^0
 > 
 >                                         0
 > Power::indet: Indeterminate expression 0  encountered.
 > 
 > Out[1]= Indeterminate
 > 
 > In[2]:= Limit[x^y,y->0]
 > 
 > Out[2]= 1
 > 
 > It seems that MMA can't do the following either:
 > 
 > In[3]:= FullSimplify[Limit[x^y,x->0],y>0]
 > 
 >                y
 > Out[3]= Limit[x , x -> 0]
 > 
 > 
 > 
 >     |\^/|     Maple 8 (IBM INTEL LINUX)
 > ._|\|   |/|_. Copyright (c) 2002 by Waterloo Maple Inc.
 >  \  MAPLE  /  All rights reserved. Maple is a registered trademark of
 >  <____ ____>  Waterloo Maple Inc.
 >       |       Type ? for help.
 > 0^0;
 > > 0^0;
 >                                        1
 > 
 > limit(x^y,y=0);
 > > limit(x^y,y=0);
 >                                        1
 > 
 > limit(x^y,x=0);
 > > limit(x^y,x=0);
 >                                             y
 >                                     lim    x
 >                                    x -> 0
 > 
 > assume(y>0):limit(x^y,x=0);
 > > assume(y>0):limit(x^y,x=0);
 >                                        0
 > 
 > MuPad also says 0^0=1

\start
Date: Mon, 21 Jun 2004 12:22:45 +0000
From: Martin Rubey
To: list
Subject: Re: Complex exponentiation and 0

This should have gone to axiom-devel also...

Martin Rubey writes:
 > David Mentre writes:
 > 
 >  > Is your bug report related to:
 >  >   [bugs #9313] 0^0 handled inconsistently
 >  >   http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9313
 >  > 
 >  > According to Martin comment, 0^0 is not mathematically defined.
 > 
 > Yes, it is related in some sense: if we adopt 0^0=1, the above should be
 > fixed. Otherwise, it could be left alone, although the error message will not
 > be entirely clear for everybody:
 > 
 > (9) -> (0.0**complex(0,0))
 >  
 >    >> Error detected within library code:
 >    log 0 generated
 > 
 > protected-symbol-warn called with (NIL)
 > 
 > Addendum to my previous post: it seems that within axiom 0^0 was assumed to be
 > undefined originally:
 > 
 > card.spad:                error "0**0 not defined for cardinal numbers."
 > float.spad:         y = 0 => error "0**0 is undefined"
 > float.spad:         r = 0 => error "0**0 is undefined"
 > float.spad:         n = 0 => error "0**0 is undefined"
 > interval.spad:    zero?(v) => if zero?(u) then error "0**0 is undefined" else 1
 > pscat.spad:            zero? r => error "0**0 undefined"
 > sf.spad:         zero? r => error "0**0 is undefined"
 > [rubey@seam101 algebra]$ grep -i "0 \*\* 0" *
 > combfunc.spad:          zero? second l => error "0 ** 0"
 > gaussian.spad:               zero? x => error "0 ** 0 is undefined"
 > gaussian.spad:               zero? x => error "0 ** 0 is undefined"
 > laurent.spad:        zero? x => error "0 ** 0 is undefined"
 > laurent.spad:          zero? x => error "0 ** 0 is undefined"

\start
Date: Mon, 21 Jun 2004 13:15:33 +0000
From: Martin Rubey
To: Tim Daly
Subject: Re: EXPR POLY INT
Cc: Manuel Bronstein

root writes:
 > Bill, Martin, Manuel,
 > 
 > Could one/both/all of you summarize this discussion in some way?  I'd
 > like to apply the suggested code fragments/fixes to Axiom but I'm
 > somewhat confused.

I think the patches on the axiom patch-page

http://savannah.nongnu.org/patch/?group=axiom 

are generally accepted. I would not integrate code which has not made it to
this page yet.

It would be good to correct the code in dvdsum, but I don't really know how to
do this. I sent a *preliminary* patch right now... Manuel, could you have a
look at it?
http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=3148


A bigger issue is bug #9217 (re-evaluating the sum operator). I find this
rather important, however, I don't know how to fix it. For bug #9313 (0^0) we
need consensus first.

 > Martin sent me some code. I integrated the first piece but you've
 > asked me to wait until you added test cases. Then you sent me
 > additional code. What are your expectations of my actions?

I thought that I sent this code only to axiom-math. So my intention is that
this code should be puplicly available, but I would not put it into

src/algebra/

with the exception of the interpolation code maybe -- *but not yet* !  I'd
suggest that we have a seperate directory for contributed stuff. The maxima
developers thought quite some time about this, they ended up with a quite
detailed directory structure, goto

http://cvs.sourceforge.net/viewcvs.py/maxima/maxima/

and look at src and contrib to get an impression.

In any case, the code in my guessing package will be available at

http://www.mat.univie.ac.at/~slc/divers/software.html 

as soon as I have a definite name for it. (rate, guess, devine are taken, I'd
love to have a greek or latin version...)

 > Bill has suggested possible fixes and further improvements but Manuel
 > has suggested different fixes.
 > 
 > I've been reading the thread in order to glean the required changes to
 > Axiom but I've ended up confused as to what I'm expected to do. I'm
 > quite pleased with the suggestions but lost in the expectations.
 > 
 > Please try to summarize this so I don't lose the changes.
 > 
 > Tim

\start
Date: Mon, 21 Jun 2004 12:53:25 +0200 (CEST)
From: Bertfried Fauser
To: Martin Rubey
Subject: Re: Complex exponentiation and 0

On Mon, 21 Jun 2004, Martin Rubey wrote:

Hi,

from a math point of view, 0^0 is introduced to cope with patological
examples in the standard terminology (this allows to fomulate definitions
and theorems without saying if x>0 then ... else ....)

>From an algebraic point of view, I think its save to assume 0^0=1 in any
category which has _no_ (non-discrete) topological semantics. As eg. real
numbers come with a standard topology, 0^0 is not a uniquely definalble
object.

Hence as a guidline, every object with allows a "limit" (ie some norm
established) should _not_ assume that 0^0=1. I don't see problems for say
natural numbers.

\start
Date: 21 Jun 2004 13:11:33 -0400
From: Camm Maguire
To: Martin Rubey
Subject: Re: Patches
Cc: Manuel Bronstein

Greetings!

Martin Rubey writes:

> Dear Prof. Bronstein,
> 
> thanks a lot for your answer!
> 
> Manuel Bronstein writes:
>  > - new()$Symbol is working properly in the NAG version, so 9298 is
>  >   probably a lisp problem.
> 
> Good. I remember that somebody was building axiom on cmucl -- I think it was 
> Juergen Weiss. Could he try to reproduce bug #9298 on cmucl? Camm Muguire (GCL)
> already offered to track down the bug:
> 
> Camm Maguire wrote:
>  > 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.
> 
> However, I don't know how to "boil it down" :-(
> 

OK, I'm afraid I've lost the thread.  If you could please give me the
commands you are using in axiom, what the result is, and what you
think it should be, in of course as simple an example as you can, I'll
be happy to take a look.

Take care,

> Manuel Bronstein writes:
> 
>  > - The line
>  >       -- cannot use new()$Symbol because of possible re-instantiation
>  >       gendiff := "%%0"::SY
>  >   in fspace.spad is due to a problem with the axiom runtime: when a domain
>  >   falls out of the runtime cache, it gets created again next time a function
>  >   from that domain is called. This means that the top-level code of the
>  >   domain is re-executed, and the globals are re-assigned.  The existing
>  >   objects from that domain in your session remain unchanged.  This would
>  >   cause the value of the gendiff symbol to change at random times, while
>  >   previous values of gendiff would be stored in live objects, and that
>  >   causes havoc.  If the runtime could guarantee that top-level code is
>  >   called only once, then, I would have used new()$Symbol. But this
>  >   re-instantiation problem forces hardwiring a specific symbol, I used %%O
>  >   hoping that it would not conflict with user variables.
> 
> This goes to the docs. Thanks a lot!
> 
> 
>  > - The definite summation operator %defsum takes 5 arguments as follows:
>  >     f  - the expression being summed, depends on a dummy summation variable
>  >     v  - the dummy summation variable
>  >     k  - the symbol to use for the summation variable when displaying
>  >     a  - the lower bound
>  >     b  - the upper bound
> 
>  >   For differentiation, it is viewed as a function of the 3 arguments f,a,b
>  >   and the chain rule is used, although my interpretation of the partial
>  >   derivative of the sum function with respect to the summation bounds is
>  >   wrong. I have to remember the reasons for the design, but the current
>  >   formula encoded in dvdsum is the following:
>  > 
>  >     D(sum(f(i),i=1..b)) = sum((Df)(i),i=a..b) + f(a) Da + f(b) Db
>  > 
>  >   for any derivation D. In the case of indefinite summation, a is an
>  >   arbitrary constant, so that formula becomes
>  > 
>  >     D(sum(f(i),i=..n) = sum((Df)(i),i=..n) + f(n) Dn
>  > 
>  >   which is encoded in dvsum.  Both are clearly wrong when the bounds are not
>  >   constant, I do not have the correct derivative at hand when the sum is not
>  >   expressible in closed form as a function of the bounds.  If there is
>  >   agreement to return an unevaluated derivative when the bounds are not
>  >   constants w.r.t. D, I can probably patch dvdsum and dvsum to do this.
> 
> I'm certain that this is the best thing to do. If you could provide a patch,
> that would be great!
> 
> Some more issues:
> 
> - is there any (written) documentation on the design of the EXPR domain
>   (including FS, ES, COMBFS, FS2 ...) ?
> 
> - I have a problem with sum: once sum is turned into an operator (for example
>   via summation or idsum), it stays such an operator. It would be great if sum
>   could be re-evaluated. In fact, I believe that sum$FS2 should be called
>   automatically in certain circumstances. However, I do not yet have a clear
>   picture how this should be done. (Also considering the fact that there should
>   be more summation algorithms in the near future. Maybe the RISC people will
>   help, I don't know...)
> 
> - is the Algebra library from Aldor Open Source? Where could I get it? Looking
>   at the Basic Categories in its documentation it seems that there is quite a
>   bit of overlap with the corresponding Axiom Domains. It would be nice if we
>   could make the two things converge *somehow*. (It seems to me that the Aldor
>   stuff is more up to date, but I don't know.)
> 
> Thanks again for joining,

\start
Date: Mon, 21 Jun 2004 14:24:56 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Complex exponentiation and 0

On Monday, June 21, 2004 6:27 AM Martin Rubey
Martin Rubey wrote:
> > > 
> > > According to Martin comment, 0^0 is not mathematically defined.
> > > 
> >
> 
> The problem is that the function f(x,y) = x^y is not continuous
> at x=y=0

Yes, of course. But what does that have to do with the case where
y is an integer?

> ... 
> I think it's dangerous to say that 0^0=1, although it's natural
> in many cases:
> 
> http://db.uwaterloo.ca/~alopez-o/math-faq/mathtext/node14.html
>

It seems to me that Alex L=F3pez-Ortiz's arguments above are correct.
Therefore I do not understand why you say "it's dangerous".
 
> In fact, I'm not sure what we would gain if axiom assumes 
> 0^0=1 throughout.

I assume you mean when '0' denotes an integer?

> I think, before we decide to adopt this strategy, we should 
> have examples which were otherwise cumbersome to deal with.

See Alex L=F3pez-Ortiz's article that you reference above.

> 
> Maybe as a guide:
> 
> Mathematica 5.0 for Linux
> ...
>     |\^/|     Maple 8 (IBM INTEL LINUX)
> ...                                       0
> 
> MuPad also says 0^0=1
> ...

I my perhaps less than humble opinion: No!

I think Axiom should *not* use Mathematica, Maple, MuPad or
Maxima as a guide. Axiom should only appeal to the mathematics
involved. In one way or another all of M^4 (and others) make
compromises when it comes to fundamentals. I think Axiom was
built with greater respect for the underlying mathematics and
that is something that we must retain and nurture. It is the
main thing that distinguises Axiom from the others.

\start
Date: Mon, 21 Jun 2004 20:58:33 +0200
From: David Mentre
To: Bill Page
Subject: Re: Complex exponentiation and 0

Hello,

Bill Page writes:

> I my perhaps less than humble opinion: No!
>
> I think Axiom should *not* use Mathematica, Maple, MuPad or
> Maxima as a guide. Axiom should only appeal to the mathematics
> involved. In one way or another all of M^4 (and others) make
> compromises when it comes to fundamentals. I think Axiom was
> built with greater respect for the underlying mathematics and
> that is something that we must retain and nurture. It is the
> main thing that distinguises Axiom from the others.

I strongly support Bill on that point. We must only refer to
mathematical work.

\start
Date: Mon, 21 Jun 2004 15:25:56 -0400
From: William Sit
To: David Mentre
Subject: Re: Complex exponentiation and 0
Cc: Bill Page

David Mentre wrote:
> 
> Hello,
> 
> Bill Page writes:
> 
> > I my perhaps less than humble opinion: No!
> >
> > I think Axiom should *not* use Mathematica, Maple, MuPad or
> > Maxima as a guide. Axiom should only appeal to the mathematics
> > involved. In one way or another all of M^4 (and others) make
> > compromises when it comes to fundamentals. I think Axiom was
> > built with greater respect for the underlying mathematics and
> > that is something that we must retain and nurture. It is the
> > main thing that distinguises Axiom from the others.
> 
> I strongly support Bill on that point. We must only refer to
> mathematical work.

I also strongly support Bill Page's point.

Also, I think the discussion on 0^0 = 1 seems to have mixed the raising of 0 to
the 0-th power (which in my opinion should be 1 in ANY domain that the base 0
belongs where the domain has an exponentiation to the NNI 0, because this is
pure algebra: -- note I am not talking about FLOAT where one would use 0.0),
with the LIMITS of the function
x^y as x AND y approaches 0 in domains in which limits make sense. In the latter
case, the eventual limit (or whether it exists) depends on the topology, and
thus should be left to the mathematics of that domain. In those cases, we should
bear in mind that the domains in Axiom dealt with a finite (though variable)
precision, trying to approximate the abstract mathematical infinite precision
object where the limit may theoretically exist. But even in those domains,
limits are distinct processes from the evaluation of the exponential function on
CONSTANT inputs.

The algebraic convention 0^0=1 is assumed for taking products over an empty
list, just as the sum over an empty list is 0. This assumption or convention is
commonly (even universally?) accepted in mathematics.

\start
Date: Mon, 21 Jun 2004 16:01:02 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Complex exponentiation and 0

Martin Rubey wrote:
>  > (9) -> (0.0**complex(0,0))
>  >
>  >    >> Error detected within library code:
>  >    log 0 generated
>  >
>  > protected-symbol-warn called with (NIL)
>  >
>  > Addendum to my previous post: it seems that within axiom 0^0 was assumed to be
>  > undefined originally:
>  >
>  > card.spad:                error "0**0 not defined for cardinal numbers."
>  > float.spad:         y = 0 => error "0**0 is undefined"
>  > float.spad:         r = 0 => error "0**0 is undefined"
>  > float.spad:         n = 0 => error "0**0 is undefined"
>  > interval.spad:    zero?(v) => if zero?(u) then error "0**0 is undefined" else 1
>  > pscat.spad:            zero? r => error "0**0 undefined"
>  > sf.spad:         zero? r => error "0**0 is undefined"
>  > [rubey@seam101 algebra]$ grep -i "0 \*\* 0" *
>  > combfunc.spad:          zero? second l => error "0 ** 0"
>  > gaussian.spad:               zero? x => error "0 ** 0 is undefined"
>  > gaussian.spad:               zero? x => error "0 ** 0 is undefined"
>  > laurent.spad:        zero? x => error "0 ** 0 is undefined"
>  > laurent.spad:          zero? x => error "0 ** 0 is undefined"
>  >
>  > Martin

Except for card.spad, the other "undefined" messages seem to me justified
because of the way exponentiation is defined x^y = exp(y* log(x)), where exp is
the natural exponentiation function, say defined as the inverse of log, which is
defined as an integral from 1 to x of 1/t (dt).  Since the integral is defined
in terms of a limit (of Riemann sum), this falls under the domain specific
convention I discussed. One can evaluate the limit of x^x = exp(x * log(x)) as x
approaches 0 by evaluating first the limit of x*log(x) as x approaches 0 (which
is 0 by L'Hopital's rule) and then apply the continuity of exp, giving the value
1. However, the limit of y^x as x AND y independently approaching 0 (that is,
(x,y) approaching (0,0) on the plane) would depend on the path. For example, if
the path is along the x-axis, where y is held 0, then the limit will be
undefined because log(0) is not defined. If the path is along the y-axis, where
x is held 0, then since y^0 is 1 for any non-zero y, the limit is 1. Since ONE
of the limits does not exist, the entire 2D limit is not defined.
Since the interpretation of the notation 0^0 in these domains is not unique, it
is better to leave it undefined.

In the case of card.spad, the function x^y, where x and y are cardinal numbers
of sets X and Y respectively, x^y is the cardinal number of the set of all maps
from Y to X. 
For example, when x = 2, 2^y is the cardinality of the power set of Y. Now when
x = 0 and/or y = 0, one (or both) of X and Y is the empty set and since one
cannot define what a "map" is to or from an empty set, it may seem justified to
leave 0^y, x^0, and 0^0 undefined.

\start
Date: Mon, 21 Jun 2004 16:52:21 -0400
From: Bill Page
To: William Sit
Subject: RE: Complex exponentiation and 0

On Monday, June 21, 2004 4:01 PM William Sit
William Sit wrote:

> ...
> Martin Rubey wrote:
> >  > ...
> >  > card.spad: error "0**0 not defined for cardinal numbers."
> ... 
> In the case of card.spad, the function x^y, where x and y are 
> cardinal numbers of sets X and Y respectively, x^y is the
> cardinal number of the set of all maps from Y to X. For example,
> when x = 2, 2^y is the cardinality of the power set of Y. Now
> when x = 0 and/or y = 0, one (or both) of X and Y is the empty
> set and since one cannot define what a "map" is to or from an
> empty set, it may seem justified to leave 0^y, x^0, and 0^0
> undefined.
> 

I am inclined to reject this argument on the general grounds of
the current treatment of categories with initial objects.

In the category of cardinal numbers a "map" is a morphism and 0
is initial. I think card.spad should be understood as implementing
such a category, although strictly speaking of course Axiom does
not (yet?) fully conform to category theory in this respect.

\start
Date: Mon, 21 Jun 2004 17:11:57 -0400
From: Bill Page
To: list
Subject: RE: Complex exponentiation and 0

On Monday, June 21, 2004 4:52 PM I wrote:

> ...
> Martin Rubey wrote:
> >  > ...
> >  > card.spad: error "0**0 not defined for cardinal numbers."
> ... 
> In the category of cardinal numbers a "map" is a morphism and 0
> is initial. I think card.spad should be understood as implementing
> such a category, although strictly speaking of course Axiom does
> not (yet?) fully conform to category theory in this respect.

Here is a good reference:

http://planetmath.org/?op=getobj&from=objects&name=CardinalArithmetic

\start
Date: Mon, 21 Jun 2004 18:20:47 -0400
From: William Sit
To: Bill Page
Subject: Re: Complex exponentiation and 0

"Page, Bill" wrote:
> 
> On Monday, June 21, 2004 4:01 PM William Sit
> William Sit wrote:
> 
> > ...
> > Martin Rubey wrote:
> > >  > ...
> > >  > card.spad: error "0**0 not defined for cardinal numbers."
> > ...
> > In the case of card.spad, the function x^y, where x and y are
> > cardinal numbers of sets X and Y respectively, x^y is the
> > cardinal number of the set of all maps from Y to X. For example,
> > when x = 2, 2^y is the cardinality of the power set of Y. Now
> > when x = 0 and/or y = 0, one (or both) of X and Y is the empty
> > set and since one cannot define what a "map" is to or from an
> > empty set, it may seem justified to leave 0^y, x^0, and 0^0
> > undefined.
> >
> 
> I am inclined to reject this argument on the general grounds of
> the current treatment of categories with initial objects.
> 
> In the category of cardinal numbers a "map" is a morphism and 0
> is initial. I think card.spad should be understood as implementing
> such a category, although strictly speaking of course Axiom does
> not (yet?) fully conform to category theory in this respect.
> 
> Regards,
> Bill Page.

I agree, in other words, you would recommend that x^0 =1 (empty product,
including x = 0, and there is a unique morphism from 0 to any x) and 0^y = 0 for
any y \ne 0. But this is still just a convention which agrees with the general
algebra cases. Note I used "may seem justified", to give a plausible reason why
Axiom is using the "undefined" convention.

\start
Date: Mon, 21 Jun 2004 19:10:53 -0400
From: Tim Daly
To: list
Subject: cvs update

Several changes, the most significant of which are that algebra dvi docs
are automatically produced and

"make book"

will make a copy of the book without building the system.

\start
Date: Mon, 21 Jun 2004 19:11:26 -0400
From: Tim Daly
To: William Sit
Subject: Re: Complex exponentiation and 0
Cc: Bill Page

well, we could split the difference and define it to 1/2 :-)

\start
Date: Mon, 21 Jun 2004 18:38:53 -0400
From: William Sit
To: list
Subject: Re: Complex exponentiation and 0
Cc: Bill Page

Bill Page wrote:
>http://planetmath.org/?op=getobj&from=objects&name=CardinalArithmetic

Actually, if one accepts the convention that there is a morphism from 0 to y in
Cardinal numbers, then I don't see any reason not to accept the convention that
there is a morphism from y to 0 (as there would be one in the opposite category,
and therefore in the original category). This of course would create difficulty
because one wants 0^y to be 0 for y \ne 0, not 1.

So it's all a matter of convenience for the "laws" to hold "more generally".

\start
Date: Mon, 21 Jun 2004 18:51:43 -0400
From: Bill Page
To: William Sit
Subject: RE: Complex exponentiation and 0

On Monday, June 21, 2004 6:39 PM William Sit
William Sit wrote:

> 
> Bill Page wrote:
> >http://planetmath.org/?op=getobj&from=objects&name=CardinalArithmetic
> 
> Actually, if one accepts the convention that there is a 
> morphism from 0 to y in Cardinal numbers, then I don't see
> any reason not to accept the convention that there is a
> morphism from y to 0 (as there would be one in the opposite
> category, and therefore in the original category). This of
> course would create difficulty because one wants 0^y to
> be 0 for y \ne 0, not 1.
> 
> So it's all a matter of convenience for the "laws" to hold 
> "more generally".
>

No. The morphisms in the Cardinal numbers category are
functions. There is no function whose codomain is 0 unless
the domain is 0. See

  http://planetmath.org/encyclopedia/Function.html

There is exactly one function whose domain is 0 for each
codomain. So we do have x^0 = 1 and 0^y = 0 for y \ne 0.

\start
Date: Mon, 21 Jun 2004 19:03:27 -0400
From: William Sit
To: Bill Page
Subject: Re: Complex exponentiation and 0

"Page, Bill" wrote:
> 
> No. The morphisms in the Cardinal numbers category are
> functions. There is no function whose codomain is 0 unless
> the domain is 0. See
> 
>   http://planetmath.org/encyclopedia/Function.html
> 
> There is exactly one function whose domain is 0 for each
> codomain. So we do have x^0 = 1 and 0^y = 0 for y \ne 0.

You are right. I stand corrected. Thanks.

\start
Date: Tue, 22 Jun 2004 09:07:13 +0000
From: Martin Rubey
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Patches
Cc: Manuel Bronstein

Camm Maguire writes:
 > Greetings!
 > 
 > Martin Rubey writes:
 > 
 > > Dear Prof. Bronstein,
 > > 
 > > thanks a lot for your answer!
 > > 
 > > Manuel Bronstein writes:
 > >  > - new()$Symbol is working properly in the NAG version, so 9298 is
 > >  >   probably a lisp problem.
 > > 
 > > Good. I remember that somebody was building axiom on cmucl -- I think it was 
 > > Juergen Weiss. Could he try to reproduce bug #9298 on cmucl? Camm Muguire (GCL)
 > > already offered to track down the bug:
 > > 
 > > Camm Maguire wrote:
 > >  > 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.
 > > 
 > > However, I don't know how to "boil it down" :-(
 > > 
 > 
 > OK, I'm afraid I've lost the thread.  If you could please give me the
 > commands you are using in axiom, what the result is, and what you
 > think it should be, in of course as simple an example as you can, I'll
 > be happy to take a look.

Here you go:

                        AXIOM Computer Algebra System 
               Version of Wednesday June 9, 2004 at 15:38:25 
-----------------------------------------------------------------------------
   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) -> %A::Symbol

   (1)  %A
                                                                 Type: Symbol
(2) -> new()$Symbol

   (2)  %A
                                                                 Type: Symbol
(3) -> G1419::SYMBOL


   (3)  G1419
                                                                 Type: Symbol
(4) -> symbol(GENSYM()$Lisp)
   Loading /home/rubey/axiom/mnt/linux/algebra/SEX.o for domain 
      SExpression 
   Loading /home/rubey/axiom/mnt/linux/algebra/DFLOAT.o for domain 
      DoubleFloat 
   Loading /home/rubey/axiom/mnt/linux/algebra/SEXOF.o for domain 
      SExpressionOf 

   (4)  G1419
                                                                 Type: Symbol

(5) -> b:=%B

   (5)  %B
                                                            Type: Variable %B
(6) -> new()$Symbol

   (6)  %B

 
The problem seems to be, that somehow the lisp doesn't realize that the symbols
are already around.

Would be great...

\start
Date: Tue, 22 Jun 2004 10:11:08 +0000
From: Martin Rubey
To: Bertfried Fauser
Subject: Re: Complex exponentiation and 0

I think Bertfried convinced me. Somehow I did not realize that axiom has
different domains :-) However, I do not yet quite understand how to apply this
insight.

Bertfried Fauser writes:

 > From an algebraic point of view, I think its save to assume 0^0=1 in any
 > category which has =5Fno=5F (non-discrete) topological semantics. As eg. real
 > numbers come with a standard topology, 0^0 is not a uniquely definalble
 > object.

Shouldn't this mean that 0^0 is undefined in EXPR INT, for example: x^y =3F  Hmm,
I see: in x^y we do not have a problem since there is no zero...

 > Hence as a guidline, every object with allows a "limit" (ie some norm
 > established) should =5Fnot=5F assume that 0^0=1. I don't see problems for say
 > natural numbers.

So, in other words, there is no bug, except that in

Vanuxem Gr=E9gory writes:
> In complex(Float) and Complex(SingleFloat), we have to change the
> exponentiation so that
>         complex(0,0)^complex(0,0.0)
> or
>         complex(0,0)^complex(2,2.0)
> doesn't use log.

the *latter* really should give 0=3F

--------------------------------------------------------------------

Page, Bill writes:
 > > Maybe as a guide:
 > > 
 > > Mathematica 5.0 for Linux
 > > ...
 > >     |\^/|     Maple 8 (IBM INTEL LINUX)
 > > ...                                       0
 > > 
 > > MuPad also says 0^0=1
 > > ...
 > 
 > I my perhaps less than humble opinion: No!
 > 
 > I think Axiom should *not* use Mathematica, Maple, MuPad or Maxima as a
 > guide. Axiom should only appeal to the mathematics involved. In one way or
 > another all of M^4 (and others) make compromises when it comes to
 > fundamentals. I think Axiom was built with greater respect for the
 > underlying mathematics and that is something that we must retain and
 > nurture. It is the main thing that distinguises Axiom from the others.
 > 
 > Regards,
 > Bill Page.


You are right. However, I still think that we can learn things from M^*. So,
what I should have written is: look, M^* does this and that. Are there things
that are mathematically just and we should incorporate=3F

Still, I strongly agree with you that we should never be tempted to say: "well,
Mx does it this way, therefore we should do so too."

\start
Date: Tue, 22 Jun 2004 08:52:15 +0200 (CEST)
From: Bertfried Fauser
To: Bill Page
Subject: RE: Complex exponentiation and 0

On Mon, 21 Jun 2004, Page, Bill wrote:

> I am inclined to reject this argument on the general grounds of
> the current treatment of categories with initial objects.
>
> In the category of cardinal numbers a "map" is a morphism and 0
> is initial. I think card.spad should be understood as implementing
> such a category, although strictly speaking of course Axiom does
> not (yet?) fully conform to category theory in this respect.

I agree totally with this. However, there are categories which have more
subtle structure being able to cope with notions as smoothnes etc. Such
categories bahave different. It is usually easily possible to write down
"elements" (not belonging to the category but looking formally like them)
which behave different. Eg if x^y is smooth in x and y there is no
problem. I do however not know how AXIOM could learn to be fully
categorial in this sense.

\start
Date: Tue, 22 Jun 2004 05:30:17 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Complex exponentiation and 0

On Tuesday, June 22, 2004 6:11 AM Martin Rubey
Martin Rubey wrote:
> ...
> Shouldn't this mean that 0^0 is undefined in EXPR INT,
> for example: x^y ?  Hmm, I see: in x^y we do not have a
> problem since there is no zero...

I don't understand. 0::EXPR INT and 1::EXPR INT exist.

 (0::EXPR INT) ^ (0::EXPR INT) = (1::EXPR INT)

> ...
> So, in other words, there is no bug,

There is a bug.

  0::CARD ^ 0::CARD

should be 1::CARD

> except that in
> 
> Vanuxem Gr=E9gory writes:
> > In complex(Float) and Complex(SingleFloat), we have to change the
> > exponentiation so that
> >         complex(0,0)^complex(0,0.0)
> > or
> >         complex(0,0)^complex(2,2.0)
> > doesn't use log.
> 
> the *latter* really should give 0?
>

No. complex(0,0)^complex(0,0.0) is like 0^0.0 and should
return

  '0**complex(0,0.0)' is undefined

The message 'log 0 generated' is confusing but technically
correct.

\start
Date: Tue, 22 Jun 2004 11:40:48 +0000
From: Martin Rubey
To: Bill Page
Subject: RE: Complex exponentiation and 0

Page, Bill writes:
 > On Tuesday, June 22, 2004 6:11 AM Martin Rubey
 > Martin Rubey wrote:
 > 
 > There is a bug.
 > 
 >   0::CARD ^ 0::CARD
 > 
 > should be 1::CARD

ok.
  
 > > except that in
 > > 
 > > Vanuxem Gr=E9gory writes:
 > > > In complex(Float) and Complex(SingleFloat), we have to change the
 > > > exponentiation so that
 > > >         complex(0,0)^complex(0,0.0)
 > > > or
 > > >         complex(0,0)^complex(2,2.0)
 > > > doesn't use log.
 > > 
 > > the *latter* really should give 0=3F
 > >
 > 
 > No. complex(0,0)^complex(0,0.0) is like 0^0.0 and should
 > return
 > 
 >   '0**complex(0,0.0)' is undefined
 > 
 > The message 'log 0 generated' is confusing but technically
 > correct.

Yes, but complex(0,0)^complex(2,2.0) should be 0.0, shouldn't it=3F

\start
Date: Tue, 22 Jun 2004 09:58:42 -0400
From: Tim Daly
To: Richard Fateman
Subject: symbolic matrix multiply

Richard,

Your paper
http://www.cs.berkeley.edu/~fateman/papers/symmat2.pdf
is very interesting.

We've been looking at the issue in terms of indefinites.
In the current version of Axiom if you type:

  x+1

'x' is known to be a symbol
'1' is known to be an integer
there is no plus which takes +(symbol,integer)
so 'x' gets promoted to polynomial over integers
'1' gets promoted to polynomial over integers
'+(POLY(INT),POLY(INT)) exists
and the result is
  x + 1
         Type: Polynomial Integer

Now it is often convenient, and especially important for further
research work we want to do, to be able to specify that 'x' is
an "indefinite integer". Thus there can be a signature 
  +(Indefinite(Integer),Integer) -> Indefinite(Integer)
so that
  x + 1
         Type: Indefinite Integer

This is a slightly more primitive notion than matrices of 
indefinite size but the ideas are essentially the same.

Indeed, the idea of Indefinite(R) where R is a domain is
the generalization. Thus, for your example, in Axiom the 
appropriate type would be 
  Matrix(Indefinite(Integer),Indefinite(Integer))

We can clearly construct such types in Axiom. What the 
mathematically correct reasoning would be and what algorithms
apply is an interesting question that we need to explore.

The key issue is that symbolic computation systems do very
little "symbolic" computation (hasty generalization to make
the point). We'd like to be able to do computation "along
the theorem line" (that is, reasoning with known theorems)
rather than basic algebra.

\start
Date: Tue, 22 Jun 2004 16:33:46 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: symbolic matrix multiply

Tim,

James Davenport had a post-doc, Christele Faure, who did a lot of work
on what you are calling indefinite integers in Axiom about 10 years ago.
The only reference I have is:
  James H. Davenport and Christ`ele Faure.
  The "unknown" in computer algebra.
  Programmirovanie, 1(1), 1994.
I'm not sure what happened to the code - it was quite complicated if I
recall correctly.  Last I heard Christele was at INRIA in
Sophia-Antipolis working on automatic differentiation, James may have more
up-to-date information.

On Tue, Jun 22, 2004 at 09:58:42AM -0400, Tim Daly wrote:
> Richard,
> 
> Your paper
> http://www.cs.berkeley.edu/~fateman/papers/symmat2.pdf
> is very interesting.
> 
> We've been looking at the issue in terms of indefinites.
> In the current version of Axiom if you type:
> 
>   x+1
> 
> 'x' is known to be a symbol
> '1' is known to be an integer
> there is no plus which takes +(symbol,integer)
> so 'x' gets promoted to polynomial over integers
> '1' gets promoted to polynomial over integers
> '+(POLY(INT),POLY(INT)) exists
> and the result is
>   x + 1
>          Type: Polynomial Integer
> 
> Now it is often convenient, and especially important for further
> research work we want to do, to be able to specify that 'x' is
> an "indefinite integer". Thus there can be a signature 
>   +(Indefinite(Integer),Integer) -> Indefinite(Integer)
> so that
>   x + 1
>          Type: Indefinite Integer
> 
> This is a slightly more primitive notion than matrices of 
> indefinite size but the ideas are essentially the same.
> 
> Indeed, the idea of Indefinite(R) where R is a domain is
> the generalization. Thus, for your example, in Axiom the 
> appropriate type would be 
>   Matrix(Indefinite(Integer),Indefinite(Integer))
> 
> We can clearly construct such types in Axiom. What the 
> mathematically correct reasoning would be and what algorithms
> apply is an interesting question that we need to explore.
> 
> The key issue is that symbolic computation systems do very
> little "symbolic" computation (hasty generalization to make
> the point). We'd like to be able to do computation "along
> the theorem line" (that is, reasoning with known theorems)
> rather than basic algebra.

\start
Date: Tue, 22 Jun 2004 10:53:47 -0400
From: Tim Daly
To: James Davenport
Subject: paper request

James,

  James H. Davenport and Christ`ele Faure.
  The "unknown" in computer algebra.
  Programmirovanie, 1(1), 1994.

Do you have an electronic copy of this paper I can reach?
Do you have a contact address for Christ`ele Faure?

Tim

====================================================================

Tim,

James Davenport had a post-doc, Christele Faure, who did a lot of work
on what you are calling indefinite integers in Axiom about 10 years ago.
The only reference I have is:
  James H. Davenport and Christ`ele Faure.
  The "unknown" in computer algebra.
  Programmirovanie, 1(1), 1994.
I'm not sure what happened to the code - it was quite complicated if I
recall correctly.  Last I heard Christele was at INRIA in
Sophia-Antipolis working on automatic differentiation, James may have more
up-to-date information.

Cheers, Mike.

===================================================================

On Tue, Jun 22, 2004 at 09:58:42AM -0400, Tim Daly wrote:
> Richard,
> 
> Your paper
> http://www.cs.berkeley.edu/~fateman/papers/symmat2.pdf
> is very interesting.
> 
> We've been looking at the issue in terms of indefinites.
> In the current version of Axiom if you type:
> 
>   x+1
> 
> 'x' is known to be a symbol
> '1' is known to be an integer
> there is no plus which takes +(symbol,integer)
> so 'x' gets promoted to polynomial over integers
> '1' gets promoted to polynomial over integers
> '+(POLY(INT),POLY(INT)) exists
> and the result is
>   x + 1
>          Type: Polynomial Integer
> 
> Now it is often convenient, and especially important for further
> research work we want to do, to be able to specify that 'x' is
> an "indefinite integer". Thus there can be a signature 
>   +(Indefinite(Integer),Integer) -> Indefinite(Integer)
> so that
>   x + 1
>          Type: Indefinite Integer
> 
> This is a slightly more primitive notion than matrices of 
> indefinite size but the ideas are essentially the same.
> 
> Indeed, the idea of Indefinite(R) where R is a domain is
> the generalization. Thus, for your example, in Axiom the 
> appropriate type would be 
>   Matrix(Indefinite(Integer),Indefinite(Integer))
> 
> We can clearly construct such types in Axiom. What the 
> mathematically correct reasoning would be and what algorithms
> apply is an interesting question that we need to explore.
> 
> The key issue is that symbolic computation systems do very
> little "symbolic" computation (hasty generalization to make
> the point). We'd like to be able to do computation "along
> the theorem line" (that is, reasoning with known theorems)
> rather than basic algebra.

\start
Date: Tue, 22 Jun 2004 18:46:04 +0200
From: David Mentre
To: Mike Dewar
Subject: Re: symbolic matrix multiply

Hello,

Mike Dewar writes:

> Last I heard Christele was at INRIA in Sophia-Antipolis working on
> automatic differentiation

Apparently, she is not longer at INRIA:
http://www-sop.inria.fr/tropics/tropics/people.html

When at INRIA, she could be contacted at:

Dr. Christle Faure
INRIA Sophia Antipolis
2004, route des Lucioles B.P. 93
06902 Sophia Antipolis Cedex
FRANCE

Tel: +33 04.92.38.79.08
Sec: +33 04.92.38.78.24
Fax: +33 04.92.38.78.58

Christele.Faure@sophia.inria.fr

\start
Date: Tue, 22 Jun 2004 19:07:43 +0200
From: Daniel Duparc
To: David Mentre
Subject: Re: symbolic matrix multiply
Cc: Mike Dewar

On Tue, 22 Jun 2004 18:46:04 +0200
David Mentre wrote:

Mrs Faure seems to be involved in a new job:
http://www.telecom.gouv.fr/rntl/projet/Posters-PDF/RNTL-Poster-JavaVerifier.pdf
(google launched on "Michelle Faure").
Regards.

> Hello,
> 
> Mike Dewar writes:
> 
> > Last I heard Christele was at INRIA in Sophia-Antipolis working on
> > automatic differentiation
> 
> Apparently, she is not longer at INRIA:
> http://www-sop.inria.fr/tropics/tropics/people.html
> 
> When at INRIA, she could be contacted at:
> 
> Christele.Faure@sophia.inria.fr

-- 
Daniel Duparc
29 av. de la Commune de Paris
94400 Vitry sur Seine (France)

\start
Date: Tue, 22 Jun 2004 19:11:11 +0200
From: Daniel Duparc
To: David Mentre
Subject: Re: symbolic matrix multiply
Cc: Mike Dewar

On Tue, 22 Jun 2004 18:46:04 +0200
David Mentre wrote:

Sorry: of course please read "Google lauched on
'Christele Faure'"

> Hello,
> 
> Mike Dewar writes:
> 
> > Last I heard Christele was at INRIA in Sophia-Antipolis working on
> > automatic differentiation
> 
> Apparently, she is not longer at INRIA:
> http://www-sop.inria.fr/tropics/tropics/people.html

\start
Date: Wed, 23 Jun 2004 08:37:17 -0400
From: Tim Daly
To: dgrande@fastq.com
Subject: Re: [Axiom-mail] Compiling Axiom

David,

> I had a similar problem compiling Axiom on my system: Gentoo, 2.6.5 
> kernel, udev.  I figured it had to do with legacy pty support in the 2.6 
> kernels.  Anyway, I was able to get it to work by slightly editing 
> axiom/src/lib/openpty.c.pamphlet.  All I had to do was remove the 
> defined(LINUXplatform) from line 95, which also includes SUNplatform, 
> HP9platform, RTplatform, and AIX370platform, and add the same 
> defined(LINUXplatform) to line 138, which includes SUN4OSS5platform, 
> ALPHAplatform, and HP10platform.  After compiling and installing, the 
> axiom command worked fine.
> 
> David Grande

please send me a copy of your new pamphlet file.

\start
Date: Wed, 23 Jun 2004 16:00:12 +0000
From: Martin Rubey
To: list
Subject: any?, member?, ...

I noticed that these function evaluate the predicate for all elements of the
argument list, which I find rather strange. For example:

(2) -> any?(i+->(output(i);(i=1)::Boolean),[1,2,3])
   1
   2
   3

   (2)  true
                                                                Type: Boolean

Wouldn't it be sensible to define these functions so that they exit when the
result is determined, i.e., instead of

     any?(f, c)           == _or/[f x for x in parts c]
     every?(f, c)         == _and/[f x for x in parts c]

do

     any?(f, c) ==
       for x in parts c repeat
         if f x then return true
       false
       
     every?(f, c) ==
       for x in parts c repeat
         if not f x then return false
       true

It seems that for TREE, some shortcircuiting is done:

    any?(fn, t) ==  ---bug fixed
      t case empty => false
      fn value t or "or"/[any?(fn, c) for c in children t]
    every?(fn, t) == 
      t case empty => true
      fn value t and "and"/[every?(fn, c) for c in children t]

\start
Date: Wed, 23 Jun 2004 16:25:08 +0000
From: Martin Rubey
To: list
Subject: (no subject)

Does anybody know about the exact semantics of #1 in compiled code?

For example, the following does not work:

)abbrev package TEST Test
Test(F): Cat == Body where
    F: Field

    Cat == with
            tst: (F, List F, List F) -> Boolean

    Body == add
      tst (e, lst1, lst2) ==
        any?(e=elt(lst1, #1), lst2)

But I don't have a clue why...

\start
Date: Wed, 23 Jun 2004 15:45:25 +0100 (BST)
From: James Davenport
To: Tim Daly
Subject: Re: paper request
Cc: James Davenport

On Tue, 22 Jun 2004, Tim Daly wrote:
>   James H. Davenport and Christ`ele Faure.
>   The "unknown" in computer algebra.
>   Programmirovanie, 1(1), 1994.
> 
> Do you have an electronic copy of this paper I can reach?
The attached is the best I can find - I don't think it's the final text, 
but is close.
> Do you have a contact address for Christ`ele Faure?
No - last seen at INRIA.
Manuel Bronsten might know.
James

--279709440-297597986-1088001925=:25976

9wIBg5LAHDsAAAAAA+gbIFRlWCBvdXRwdXQgMjAwNC4wNi4yMzoxNTQziwAA
AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////oAJs
AACNoP27AACgAicAAI2g/fwAAI2SANchS/MedAyJOgAJAAAACQAAAAVjbWJ4
OclBYnN0cmFjdI6fFazSjZFl3/zzGm+0i8cACQAAAAkAAAAEY21yOcVDb21w
dXRlcpYD+CFhbGdlYnJhk3N5c3RlbXOTaGGVvjl2k2WWA/ghdG+TZGVhbJN3
aXRok3RoZZNjb25mdXNpb26TYpBBx2V0lb45d5NlZW6OpAsAAI2RWAACXHBy
b2dyYW1taW5nlgQIP3aR/3xyYXJpYWJsZXMik2FuZJNcbWF0aGVtYXRpY2Fs
k3N5bZC+OWKQQcdvbHMiLpEG9TFXkf86q2WTY2xhaW2TdGhhdI6hjZFYAAJ0
aGV5lgPf1XNob3VsZJNhbHNvk2RlYWyTd2l0aJNcdW5rbm+Vvjl3bnMiLJEE
EnVpLmUukQZ78mVsZW1lbpN0c5YD39V3aG9zZZN2kf98cmFsdWVzk2FyZY6h
jZFYAAJ1bmtub5q+OXduLJECv2xidXSWAqnxd2hvc2WTdJh5cJBBx2WTaXOT
a25vmHduLpED+KRGkf86q29yk2V4YW1wbGUskQK/bPMbNfmeIgAJAAAACQAA
AAVjbW1pOcZ4jZ/8LT3zEBDNvs4ABgAAAAYAAAAFY21taTa7cI6RBuyd8xyp
sZDKAAkAAAAJAAAABWNtc3k5xzbFPZECkcbGeJPFaWaTxniTxWlzk2GTc3lt
mGKQQcdvbCyOoY2RWAACYnV0lgMhlMZ4jZ/8LT27cI6RBwEIxT2bAqYxxniT
xWlmk8Z4mMcyjZjFR0aOkQ/x5ijGcMUpLpEEQTFXkf86q2WTc2hvmr45d5No
b5h3k3eYZZNoYZh2mGWTZXh0ZW5kZWSTQXhpb22TdG+TZGVhbI6hjZFYAAJ3
aXRolgMVVHRoaXOTY29uY2VwdC6Ojp8eAACNkgDpAADzB0vxYHkACgAAAAoA
AAAFY21yMTCyMY6OjIsAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAKqACbAAAjaD9uwAAoAInAACNoP4mAAKNkWYJl/M+RNPt
dAARR64AEUeuAAVjbXIxN+lUaGWWBTd0XFVua25vkIxxd24ik2luk0NvbXB1
dGVyk0FsZ2VicmGOnycAAo2NjY2NkXI1I/MwWKtRCwAMAAAADAAAAAVjbXIx
MttKYW1lc5ED6qhEYZWscnaTZW5wkFOOb3J0jY2f+6Uy8xe+S8gLAAgAAAAI
AAAABWNtc3k4wgOOjo6Onw4AAI2NkWdgv/M234a1VAAMAAAADAAAAAZjbXR0
MTLhamhkQG1hdGhiYXRoLmFjLnVrjo6Ojo2NjY2SAQqXtdtDaHJpc3SQrHIS
kfpzkmVsZZED6qhGkf8FVmF1cmWNjZ/7pTLCeY6Ojo6fDgAAjY2SAPQfPeFj
cmZAbWF0aHMuYmF0aC5hYy51a46Ojo6Ony+IjI2SAJfqLttTY5CscmhvkFOO
b2yWA+qob2aTTWF0aGVtYXRpY2Fsk1NjaWVuY2VzjqQOAACNkgC75llVbml2
laxyZXJzaXSTeZYD6qhvZpNCYXRojqGNkgDELctCYXRolgPqqEJBMpM3QZH/
BVZZjqQMAACNkgDWNFNFbmdsYW5kjp9B4JmNjZE/AADzPMLWTqAADmZmAAwA
AAAGY21ieDEy5zGOkVdMy0lukIzMdHJvkHMzZHVjdGlvbo6fH+ccjZE/AACy
Q29tcHV0ZXKWAluiQWxnZWJyYZNhbmSTTnVtZXJpY2Fsk0NvbXB1dGF0aW9u
k2FyZZN0lbjjd5NvlgJbom1lYW5zk29mk2NvbXB1dGF0aW9uYWyOoY2RPwAA
bWF0aGVtYXRpY3OWA1VVd2hpY5q442iTYXJlk2RpC2VyZW6YdJNpbpN0aGWT
d5hhmHmTdGhleZN1c2WTYW5kk3RyZWF0k3N5bZhikEcdb2xzLo6hjZE/AABJ
bpYEfdNumrjjdW1lcmljYWyTY29tcHV0YXRpb24skQTH8nN5bZhikEcdb2xz
k2FyZZNjb25zaWRlcmVkk2Fzk3Byb2dyYW1taW5nk3aR/3HHYXJpYWJsZXOO
oY2RPwAAYW5klgNVVWFyZZN1c2Vkk3Rvk3N0b3Jlk2lukLjjdGVybWVkaWF0
ZZNyZXN1bHRzLo6hjZE/AABDb21wdXRlcpYDNalhbGdlYnJhk3N5c3RlbXOT
dGFrmrjjZZNpbph0b5NhY2NvdW6YdJNpbpNwkEcdb2x5bm9taWFsc5NldGMu
kQRnOGGTc2Vjb25kk2NsYXNzjqGNkT8AAG9mmwNVVXN5bZW442KQRx1vbHM6
kQRxx3VuaW6TdGVycHJldGVkmHaR/3HHYXJpYWJsZXMujqGNkT8AAEJ1dJYD
4KNpbpNtYXRoZW1hdGljcyyRBAN3YZN0aGlyZJNjbGFzc5NvZpNzeW2auONi
kEcdb2xzk2lzk2Fsc2+TaW6YdphvbHaYZWSTaW6TY29tcHV0YXRpb24ujqGN
kT8AAE9uZZYCr+lvZnRlbpNikEcdZWdpbnOTbWF0aGVtYXRpY2Fsk3RleHRz
k3dpdGiTc2VumrjjdGVuY2Vzk2xpa5hlk1xsZXST8woLoGI+AAoAAAAKAAAA
BmNtbWkxMLVwk7JimkcdZZNhk3CYb2x5bm9taWFsIo6hjZE/AABvcpYCzD9c
bGV0k7Vuk7JikEcdZZNhbpNpbpq443RlZ2VyIo2TtTqWAaqoOpM6jpERQyWy
SW6TdGhvc2WTc2VumHRlbmNlcyyRAueqtW6TsmFuZJO1cJOyYXJlk25laXRo
ZXKTcHJvZ3JhbW1pbmeOoY2RPwAAdpv/ccdhcmlhYmxlcyyRA68ibm9ylgOd
LXVuaW6QuON0ZXJwcmV0ZWSTdphhcmlhYmxlcyyRA68iYnV0k2FyZZNuYW1l
c5NvZpNtYXRoZW1hdGljYWyTb2KRAI44amVjdHMsjqGNkT8AAHdpdGiWBBnx
dJq443lwkEcdZXOTYnV0k3dpdGhvdXSTa25vmHduk3aR/3HHYWx1ZXMskQRL
GGNhbGxlZJPzIxryIlYACgAAAAoAAAAGY21ieDEwznVua25vkK45d25zk7J8
k2luk2Z1dHVyZZN3mGWTd2lsbI6hjZE/AAByZWZlcpYDVVV0b5NzdWOauONo
k3N5bZhikEcdb2xzk2Fzk7Vuk7Jhc5POYmFzaWORA9VUdW5rbm+Qrjl3bnOy
Lo6hjZE/AABPbmWWAlrYYppHHWVnaW5zk2GTbWF0aGVtYXRpY2Fsk3RleHST
YpC443mTXGxldJO1cJOyYphlk2GTcJhvbHlub21pYWwik3Rvk21ha5q442WT
dGhlk2ZvbGxvmHdpbmeOoY2RPwAAdGV4dJYCj1dtb3Jlk3ByZWNpc2UukQQv
yEaR/yqqb3KTZXhhbXBsZSyRArbxdGhlk2V4cHJlc3Npb26TXLVulgCs6LIr
k7VtsiKWAo9XY2Fuk21lYW6TYZNsb3STb2aTdGhpbmdzOo6hjZE/AAB0aGWW
A6hVc3Vtk29mk3SVuON3k2+WA6hVbWF0cmljZXMskQO9FHRoZZNhcHBsaWNh
dGlvbpNvZpN0aGWTY29uY2F0ZW5hdGlvbpNvcJBHHWVyYXRvcpN0b5N0lbjj
d5NvjqGNkT8AAGxpc3RzlgOHJGV0Yy4skQOTmHdoZXJlYXOTdGhpc5NleHBy
ZXNzaW9uk2lzk2NsZWFyk2lmk29uZZNkZWNsYXJlc5N0aGF0k7Vuk7JhbmST
tW2TsmFyZZN0lbjjd5NvjqGNkT8AAFxpbpC443RlZ2VycyIujqGNkT8AAFN1
Y5W442ibBCjgc3ltk2KQRx1vbHOYbZN1c3SYYpVHHWWYdHJlYXRlZJhpbphj
b21wdXRlcphhbGdlYnJhmGlumGGYc3CTZWNpDGOYd5W442GTeZhikEcdZWNh
dXNljpE/AACfB5iviQAAZmYAif92nwlAAI2NjZEK94if/S068xFxoSULAAYA
AAAGAAAABWNtc3k2vAOOjpEPTNzzFXx7WQcACAAAAAgAAAAEY21yOMBUaGlz
lgL7F3Jlc2VhcmOQw45oLJsDBIZhbmSTdGhlk2FjY2Vzc5N0b5PzWd9DynMA
CAAAAAgAAAAFY210dDjrWUF4aW9tk8B1c2Vkk2luk3RoaXOTcHJvkHjkamVj
dCyYd5rDjmVyZZNzdXBwkDxyb3J0ZWSTYph5k3RoZZNVSydzjqQJgACNU2Np
ZW5jZZYC1VhhbmSTRW5naW5lZXJpbmeTUmVzZWFyY5rDjmiTQ291bmNpbJN1
bmRlcpNncmFumHSTR1IvSC8xMTU4Ny6OnwnXDI2NjZELWxef/S06vHmOjpEP
TNzAU3VwcJA8cm9ydGVklgQL2WKaw455k2Fuk0lOUklBkQQLiXNjmGhvbGFy
c2hpcJNhbmSTRUVDmwQLiVByb5B45GplY3STUE9TU0+YRXNwcml0k0Jhc2lj
k1Jlc2VhcmOQw45ojqGNQWN0aW9ukQLVWDY4NDYujo6fHgAAjZIA6QAAsjKO
joyLAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AzegAmwAAI2g/bsAAKACJwAAjaD9/AAAjZE/AACydGhleZYDcS5kb24ndJNo
YZW443aTZZYDcS52m/9xx2FsdWVzk2Fzk3Byb2dyYW1taW5nk3aYYXJpYWJs
ZXMskQN4JW5vcpNkb5N0aGV5k21lYW6TYZNwkEcdb3NpdGlvbo6kDAAAjZE/
AABsaWuVuONlmwOK/XVuaW6TdGVycHJldGVkmHaR/3HHYXJpYWJsZXMskQOY
Z2FuZJh0aGWYb25seZh0aGluZ5hrbm+Td26YYWKQRx1vdXSYdGhlbZhpc5hh
mHNvcnSYb2aOoY2RPwAAXHSVuON5cJBHHWUimwNVVWxpa5NlmFxpbpN0ZWdl
ciIsmFxwkEcdb2x5bm9taWFsIo2YtTqWAaqoOpM6jo6pFgABjZE/AACySXSW
A2UvaXOTcXVpdGWTZWFzeZN0b5Njb25mdXNlk3RoZZNjb25jZXB0k29mk3Vu
aW6QuON0ZXJwcmV0ZWSTb3KTZm9ybWFsk3aR/3HHYXJpYWJsZZN3aXRojqGN
kT8AAHRoZZYDpM5jb25jZXB0k29mkyyRA7isYnV0k3RoZZN0lbjjd5NvlgOk
zmFyZZNpbpNmYWN0k2RpC2VyZW6auON0k2NvbmNlcHRzLpEFYDJPdphlcpPO
Wo2fAX//8wkwZZdyAAcAAAAHAAAABWNtbWk3tHCOkQSfUrIskQO4rHRoZZNw
kEcdb2x5LY6hjZE/AABub21pYWxzlgL4dLV4k7JhbmSTtXiNn/xe/7RwjpEH
l8ayYXJlk2RpC2VyZW6auON0k2lmk7V4k7Jpc5Nhk2Zvcm1hbJN2kf9xx2Fy
aWFibGUskQMLCGJ1dJNpZpO1eJOyaXOTYW6TKHVua25vmHduKY6hjZE/AABl
bGVtZW6auON0lgNVVW9mk85ajZ8Bf/+0cI6RBJ9SsiyTdGhlbpO1eI2f/F7/
tHCOkQdmarI9kQLHGLV4k7JimHmTRpH/Kqplcm1hdCdzk0xpdHRsZZNUaGVv
cmVtLo6mjZE/AABUlv8qqnJhZGl0aW9uYWxseZMskQPvYWNvbXB1dGVylgPQ
kmFsZ2VicmGTc3lzdGVtc5NjYW5ub3STaGFuZGxlk3N1Y5q442iTc3ltmGKa
Rx1vbHOTcHJvcJhlcmx5jqGNkT8AAGKaRx1lY2F1c2WWBDjgdGhleZNoYZW4
43aTZZYEOOBub5NtZWOQuONoYW5pc22TZm9yk3RoZZN1c2Vyk3Rvk2Fzc2+Y
Y2lhdGWTc3VjmrjjaJNcdJh5cJBHHWVzIpN3aXRojqGNkT8AAHN5bZq442KQ
Rx1vbHMukQRrzENsYXNzaWNhbJYDQ2Rjb21wdXRlcpNhbGdlYnJhk3N5c3Rl
bXOTbZh1c3STYppHHWWTY29uc2lkZXJhYmx5k21vmGRpDGVkk3RvjqGNkT8A
AGKQRx1llgOC62FibGWTdG+TdHJlYXSTc3VjmrjjaJNzeW2YYpBHHW9scy6R
BPqJQW6TZXhhbXBsZZNvZpNhk3N5c3RlbZNhYmxlk3Rvk3Rha5hlk3RoZW2T
aW6YdG+OoY2RPwAAYWNjb3VumrjjdJYDukdpc5PzIf0AJzoACgAAAAoAAAAG
Y210aTEwzFVseXNzZZOyKFuNzj+OkQVuN7JdKSyRA9OEYZNzeXN0ZW2TYmFz
ZWSTb26TYW6TaW6YdGVycHJldGVyk2VucmljmGhlZJN3aXRok2GTdJh5cJBH
HWWOoY2RPwAAY5W442hlY5Nrk2VylgPvJihbjUaR/yqqYXU5Mo6RGkAFXSku
kQY/O0GRA+7/bm9uLWNsYXNzaWNhbJNzeXN0ZW2Tc3VjkLjjaJNhc5PzJN/q
PHgACgAAAAoAAAAGY210dDEwz0F4aW9tk7JpcyyWBBWacm91Z2hseZH/Kqos
k2GRA+8mbGlicmFyeY6hjZE/AABidWlsdJYDPWtmcm9tk2hpZ2gtbGV2mrjj
ZWyTbWF0aGVtYXRpY2Fsk2Rlc2NyaXB0aW9uc5NimHmTYZNjb21waWxlci6R
BGnOSW6YdHJvkEcdZHVjaW5nk3VuLY6hjZE/AABrbm+auON3bnOWA/VSaW6T
dGhpc5NraW5kk29mk3N5c3RlbZNpc5NxdWl0ZZNkaQtlcmVumHSTYppHHWVj
YXVzZZNvbmWTZG+YZXOTbm90k2hhlbjjdpNlkQP1UnRvjqGNkT8AAG1vkEcd
ZGlmeZYDwzd0aGWTY29tcHV0aW5nk3BhcnSTb2aTdGhlk3N5c3RlbZMoaW6Q
uON0ZXJwcmV0ZXIpk2Fzk2luk2NsYXNzaWNhbJNzeXN0ZW1zLo6hjZE/AABJ
bnN0ZWFkLJYDVVVvbmWTbmVlZJNvbmx5k2lukLjjdHJvkEcdZHVjZZNhk25l
d5NjbGFzc5NvZpNtYXRoZW1hdGljYWyTZXhwcmVzc2lvbnMujqaNkT8AAFeR
/yqqZZYECHF3aWxsk3VzZZPPQXhpb22TsnRvk2V4cGxhaW6TdGhlk2NvbmNl
cHRzk2RlDG5lZJNpbpN0aGlzk3BhcJBHHWVyLpEGixpUaGWTdXNlcpNpc46h
jZE/AABhYmxllgMtK3Rvk2RlDG5lk25ld5NtYXRoZW1hdGljYWyTb2KRAI44
amVjdHOTaW6Tz0F4aW9tsi6RBGRkV5H/Kqplk3dpbGyTZGVzY3JpYppHHWWT
dGhpc5Nhc3CYZWN0jqGNkT8AAG9mlgM2OXRoZZNzeXN0ZW2TaGVyZTqRBGI5
b3RoZXKTZGVzY3JpcHRpb25zk2NhbpNikEcdZZNmb3VuZJNpbpNbjc4/jpEF
bjeyXS6RBGdpQZEDNjJzZXSTb2aTb2KRAI44amVjdHOTYW5kjqGNkT8AAHRo
ZZYDs85vcJBHHWVyYXRvcnOTdXNlZJN0b5NtYW5pcHVsYXRlk3RoZW2TaXOT
Y2FsbGVkk2GTz2RvbWFpbpOyKHNlZZNbjUpTOTJhjpEZscxdKS6RBY0xRWFj
kLjjaI6hjZE/AADPZG9tYWlulgLUcLJjYW6TYpBHHWWTY29uc3RydWN0ZWST
dGhyb3VnaJNhbpNleGlzdGluZ5NmdW5jdG9yLJEC7jhvcpNhk25ld5NvbmWT
ZGUMbmVkk2KQuON5jqGNkT8AAHRoZZYC8zR1c2Vyk1uNRGGQuON2OTKOkRuj
k10ukQRREUGRAvMbbmV3k89kb21haW6Tsm2QuON1c3STDHJzdJNikEcdZZNk
ZQxuZWSTaW6TdGVybXOTb2aTbW9yZZNhYnN0cmFjdI6hjZE/AABjb25jZXB0
c5YDd3djYWxsZWSTz2NhdGVnb3JpZXOTsihzZWWTW41KUzkyYo6RGkAFXSmT
d2hpY5q442iTYpBHHWVsb25nk3Rvk2GTaGllcmFyY5hoaWNhbJNncmFwaI6h
jZE/AABiYXNlZJYDg81vbpNhbGdlYnJhaWOTcHJvcJBHHWVydGllc5Moc2Vl
k1uNzj+OkQVuN7JdKS6RBP0uT25lk2lzk29imrjjdmlvdXNseZNhbGxvmHeY
ZWSTdG+TZGUMbmWTbmV3jqGNkT8AAGNhdGVnb3JpZXOWBL5ZYW5kk2lumrjj
dHJvkEcdZHVjZZN0aGVtk2lumHRvk3RoZZNoaWVyYXJjmGiYeZH/KqoukQis
01RoaXOTbGVhZHOTdG+TYZN0mHeYby1sZXaYZWyOoY2RPwAAdJW443lwaW5n
mwNVVW1lY5NoYW5pc22YaW6YQXhpb206jqQTtgONjZIAqgAAT2KRAI44amVj
dI6SAMp///MNISIsmgAKAAAACgAAAAZjbXN5MTC4Mo2RAscYskRvbWFpbo6R
J9xvuDKNkQLHGLJDYXRlZ29yeY6RKocetTqOoY2RPwAAslSR/yqqb5YEkqJt
YWuQuONlk3RoZZNzcJpHHWVjaQxjYXRpb26Tb2aTdGhlk2RvbWFpbpNjb21w
bGV0ZSyRBOH1YWxsk3RoZZNvcJhlcmF0b3Jzk3NwmGVjaQxjjqQMAACNkT8A
AHRvlgRN53RoaXOTZG9tYWluk22auON1c3STYpBHHWWTZGVjbGFyZWQukQdb
flRoZW6Tb25lk2hhc5N0b5NpbXBsZW1lbph0k2l0LJEEjAxpLmUukQdbfmRl
DG5ljqGNkT8AAHRoZZYDS9ZyZXByZXNlbpq443RhdGlvbpNvZpN0aGWTb2KR
AI44amVjdJNpbpN0aGWTZG9tYWluk2FuZJNpbXBsZW1lbph0k2FsbJN0aGWT
ZnVuY3Rpb25zjqGNkT8AAGFsbG+VuON3k2VkmwRko2+TdpNlcph0aG9zZZhv
YpEAjjhqZWN0cy6RB5+xRpH/Kqpvcphtb3JlmGluZm9ybWF0aW9umGFikEcd
b3V0mHRoZZhjcmVhdGlvbphvZphuZXeOoY2RPwAAZG9tYWlucyyWA1VVdGhl
k3JlYWRlcpNjYW6TcmVmZXKTdG+TKFuNRGGQuON2OTKOkRujk10pLo6fKqza
jY2RPwAA5zKOkVdMy1Vua25vkIzMd25zOpEHMzJzcJBzM2VjaQxjYXRpb26O
nx/nHI2RPwAAsleR/yqqZZsDtLt3lbjjYW6TdJh0b5hpbpN0cm+QRx1kdWNl
mHVua25vk3duc5h0aHJvdWdomHRoZZhkZQxuaXRpb26Yb2aYYZhkb21haW6Y
aW6Yz0F4aW9tsi6OoY2RPwAARpH/KqpvcpYEQ5p0aGlzk3B1cnCQRx1vc2Us
kQR/K3eauONlk3dpbGyTZGUMbmWTYZNmdW5jdG9yk29mk2RvbWFpbnOTb2aT
dW5rbm+Yd25zLpEHPJdXkf8qqmWTDHJzdI6Onx4AAI2SAOkAADOOjoyLAAAA
BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADbigAmwA
AI2g/bsAAKACJwAAjaD9/AAAjZE/AACyaGGVuON2k2WWA1VVdG+TYW5zd5C4
42Vyk2GTZmV3k3F1ZXN0aW9uc5N0b5NzcJBHHWVjaWZ5k2l0k2NsZWFybHmR
/yqqLo6fIAABjY2NjZFLOOQxLo6OjpFYAAJXaGF0lgNVVWlzk2GTZG9tYWlu
k29mk3Vua25vkLjjd25zP46kDAAAjZFYAAJCYXNpY2FsbHmR/yqqLJECqcpp
dJYCfuZjb26auON0YWluc5NzeW2YYpBHHW9sc5N3aXRok3RoZWlyk1x0mHlw
kEcdZXMiLJECqcpjYWxsZWSTzmJhc2ljkQLevHVua25vkK45d25zsi6OoY2R
WAACQnV0lgMG829imrjjdmlvdXNseZNvbmWTd5hhbph0c5N0b5NidWlsdJNl
eHByZXNzaW9uc5N0aGF0k2Nvbph0YWluk3RoZW0skQMWoHRoZXJlZm9yZY6h
jZFYAAJ2kf9xx2FsaWSWA8Pdb3CaRx1lcmF0b3Jzk22QuON1c3STYphlk2Rl
DG5lZC6RBb1fVGhvc2WTZXhwcmVzc2lvbnOTYXJlk3B1cmVseZNzeW2QuONi
mG9saWMsjqGNkVgAAndoZW6WAuZab25lk2Fsc2+TbmVlZHOTdG+TdXNlk3Bh
cnRpYWxseZNldpH/ccdhbHVhdGVkk2V4cHJlc3Npb25zk3N1Y5C442iTYXOT
XLVulgFa67IrkzIijqGNkVgAAndoZXJllgNIA7Vuk7Jpc5Nhk2Jhc2ljk3Vu
a25vmrjjd26TaW6YdGVnZXIukQRtVlRoZW6TYZNzZWNvbmSTY2xhc3OTb2aT
Y29uc3Rhbph0c5NhcmWOoY2RWAACbmVjZXNzYXJ5OpEEccd0aGV5lgNVVWFy
ZZN2kf9xx2FsdWVzk2KQRx1lbG9uZ2luZ5N0b5Nzb21lk3BhcnRpY3VsYXKT
c2V0cy6OoY2RWAACQW6WBNv1ZXhwcmVzc2lvbpNpc5Nhk3aR/3HHYWxpZJN1
bmtub5q443duk2lmLJEFPZx3aGVuZXaYZXKTZWFjmGiTYmFzaWOTdW5rbm+Y
d26TaXOOoY2RWAACcmVwbGFjZWSWAxJtYpC443mTYZN2kf9xx2FsdWWTZnJv
bZN0aGWTYXBwcm9wcmlhdGWTc2V0LJEDH890aGWTd2hvbGWTZXhwcmVzc2lv
bpNjYW6TYpBHHWWOoY2RWAACZXaR/3HHYWx1YXRlZJYDVVV0b5Nhk3eQuONl
bGwtZGUMbmVkk29ikQCOOGplY3QujqGNkVgAAlRoZZYC3pBwYXJhbWV0ZXJz
k25lY2Vzc2FyeZN0b5NkZQxuZZNhk2NvbnN0cnVjdG9yk29mk2RvbWFpbnOT
b2aTdW5rbm+QuON3bnOOoY2RWAACYXJllgMrp2GTbGlzdJNvZpN0mrjjeXCQ
Rx1lZJNzeW2YYpBHHW9sc5MoY2FsbGVkk2Jhc2ljk3Vua25vmHducykskQMz
/WFuZJNhk2xpc3STb2aTZG9tYWluc46hjZFYAAJmb3KWA1VVdGhlk3ab/3HH
YWx1ZXOTKGNhbGxlZJN2mGFsdWWTZG9tYWlucykujqkUAACNjY2NkUs45DIu
jo6OkVgAAlSauON5cJBHHWWWA1VVb2aTYmFzaWOTdW5rbm+Yd25zk2FuZJN2
kf9xx2FsdWWTZG9tYWlucz+OoY2RWAACVJH/KqpvlgOP9GKQRx1lk2FibGWT
dG+TY5W442hlY5NrlgOP9HRoZZN2kf9xx2FsaWRpdJq443mTb2aTdW5rbm+Y
d26TZXhwcmVzc2lvbnMskQOem3eYZZNoYZh2mGWTY5hob3Nlbo6hjZFYAAJ0
b5YDd111c2WTZG9tYWluc5Nhc5N0mrjjeXCQRx1lc5Nmb3KTYmFzaWOTdW5r
bm+Yd25zLpEE195UaGF0k21lYW5zk3RoYXQskQN/32lmk2GTYmFzaWOOoY2R
WAACdW5rbm+auON3bpYDtthpc5NyZXBsYWNlZJNimHmTYW6TZWxlbWVumHST
b2aTaXRzk3SYeXCQRx1lk2RvbWFpbiyRA885dGhlk2V4cHJlc3Npb26TaXOO
oY2RWAACc3RpbGyWA0dudpv/ccdhbGlkLpEEbSVXkf8qqmWTY2Fuk29ubHmT
dGFsa5NvZpNhk2RvbWFpbpNpZpNhbGyTb3CQRx1lcmF0b3Jzk2FyZZN2mGFs
aWSTb5W443aTZXKRA0duYWxsjqGNkVgAAmVsZW1lbpq443RzlgJf/G9mk3Ro
ZZNjb3JyZXNwkEcdb25kaW5nk3NldJNhbmSTcGFydGljdWxhcmx5k2+Ydphl
cpNhbGyTYmFzaWOTdW5rbm+Yd25zLo6hjZFYAAJGkf8qqm9ylgQQVWV4YW1w
bGUsmwQ/FGlmk7Vuk7JhbmSTMpNhcmWTaW6TYZNkb21haW6Td2hpY5C442iT
aXOTYZNyaW5nLJh0aGVuk25vdJNvbmx5jqGNkVgAAm2QuON1c3SbAxVgMpYB
uPYrkzKYYpBHHWWYYWxsb5W443eTZWQskQMiK2J1dJhhbHNvmLVulgG49rIr
kzIskQMiK2FuZJhpbmRlZWSYtW6TsiuTtW6yLpEEXHVUaGlzmHeQuONvdWxk
mHNlZW2OoY2RWAACdW6VuON3k29ya5H/ccdhYmxllgNbI2lmk3RoZZN0mrjj
eXCQRx1lk2RvbWFpbnOTb2aTdGhvc2WTYmFzaWOTdW5rbm+Yd25zk2FyZZNh
bGyTZGkLZXJlbph0Lo6hjZFYAAJUaGVyZWZvcmWWAy6Id5q442WTZGVjaWRl
k3RoYXSTYmFzaWOTdW5rbm+Yd25zk2Fsd5hhmHlzk2KQRx1lbG9uZ5N0b5N0
aGWTc2FtZZN0mHlwkEcdZY6hjZFYAAJkb21haW4skQPJ8GFsbJYDsp52m/9x
x2FsdWVzk2KQRx1lbG9uZ5N0b5N0aGWTc2FtZZN2mGFsdWWTZG9tYWluLJED
yfBhbmSTdGhhdJN0aG9zZZN0lbjjd5NvjqGNkVgAAnSQuON5cJpHHWVzlgNH
/WFyZZN0aGWTc2FtZS6RBG1VVGhlc2WTcmVzdHJpY3Rpb25zk2FyZZNub3ST
YXOTc3Ryb25nk2Fzk2l0k3NlZW1zk3Rvk2KYZY6hjZFYAAJikEcdZWNhdXNl
lgOJkW9uZZNpc5NhYmxlk2luk0F4aW9tk3Rvk2NyZWF0ZZNzZXaauONlcmFs
k2RvbWFpbnOTb2aTdW5rbm+Yd24skQOWn2FuZI6hjZFYAAJ1c2WRA1VVz2Nv
ZXJjaW9uc7Iujp8QAACNkVgAAlRoZW6WAtVSdGhlk2NvbnN0cnVjdG9yk29m
k3N1Y5q442iTZG9tYWluc5NuZWVkc5N0mHeYb5Nhcmd1bWVumHRzOpEEMcVh
k2xpc3STb2aTc3ltLY6hjZFYAAJilUcdb2xzLJEDDC50aGWbAvnkdJC443lw
k2WYZG9tYWlumChzYW1lmGFzmHaR/3HHYWx1ZZhkb21haW4pLpEEU0xJZph3
lbjjZZhjYWxsmHRoZZh0k3lwkEcdZZhkb21haW6OoY2RWAACYW5klgPb0HRo
ZZN2kf9xx2FsdWWTZG9tYWluk89EkQPbrbJhbmSTdGhlk2xpc3STb2aTYmFz
aWOTdW5rbm+QuON3bnOTz0Jhc2ljVW5rbm93bnOyLI6hjZFYAAJ0aGWWA1VV
ZGVjbGFyYXRpb26Tb2aTdGhpc5Njb25zdHJ1Y3RvcpNpbpPPQXhpb22Tsmlz
Oo6hjZFYAALPVW5rbm93bpYFP/0oRCxCYXNpY1Vua25vd25zOkxpc3STU3lt
Ym9sKY6mjY2NjZFLOOSyMy6Ojo6RWAACT25llgSIvnF1ZXN0aW9uk3eauONl
k3Nob3VsZJNhc2uTb3Vyc2Vsdphlc5NpczqRBtiZc2hvdWxkk3RoZXJlk2KQ
Rx1lk29uZZNvcpNtb3JljqGNkVgAAmZ1bmN0b3JzlgLrUXRvk2NyZWF0ZZNz
dWOauONok2RvbWFpbnM/kQic4lRoZZNhbGdlYnJhaWOTdJh5cJBHHWWTb2aT
YZNkb21haW6TZGUMbmVkjqGNkVgAAmKQuON5mwSzBs9Vbmtub3dulgU//ShE
LEJhc2ljVW5rbm93bnM6TGlzdJNTeW1ib2wpmLJkZXCVRx1lbmRzmG9umHRo
ZZh0kLjjeXCTZZhvZo6hjZFYAALPRLIulgPGd0aR/yqqb3KTZXhhbXBsZSyR
A+K/dGhlk2RvbWFpbnOTb2aTaW6auON0ZWdlcpNvcpNwkEcdb2x5bm9taWFs
k3Vua25vmHduc5NtYZh5k2KQRx1ljqGNkVgAAnNwmkcdZWNpDGVklgOhaHRv
k2KYZZNyaW5nc5N3aGVyZWFzk3RoZZNtYXRyaWNpYWyTb3KTdpq442VjdG9y
aWFsk3Vua25vmHduc5NjYW5ub3SOoY2RWAACYppHHWWWBIgwc2+Tc3CYZWNp
DGVkLpEQFLBJZpPPWCeRBIfhsmlzk2GTd5C442Vha5Nmb3Jtk29mk3RoZZNj
YXRlZ29yeZPPWLIsk3RoYXSTaXOTb25seY6hjZFYAAJzdWl0YWJsZZYChINw
cm9wmkcdZXJ0aWVzk2FuZJNvcJhlcmF0b3Jzk2Zyb22Tz1iyLJN0aGWTZGUM
bml0aW9uk29mk3RoZZNtb3N0k2dlbmVyYWyOjp8eAACNkgDpAAA0jo6MiwAA
AAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwcoAJs
AACNoP27AACgAicAAI2g/fwAAI2RWAACsmNvbnN0cnVjdG9ylgNVVXNlZW1z
k3Rvk2hhlbjjdpNllgNVVWGTaGVhZJNsaWuQuONlOo6kDAAAjZFYAALPVW5r
bm93bpYFP/0oRDpYLEJhc2ljVW5rbm93bnM6TGlzdJNTeW1ib2wpOlgnjp8g
AAGNkT8AALJJbpYDYtlvcmRlcpN0b5NzaG+auON3k2hvmHeTc3VjmGiTYZNj
b25zdHJ1Y3RvcpNjYW6TYpBHHWWTZGUMbmVkLJEDZjp3mGWTd2lsbJN3mG9y
a5N3aXRok3RoZY6hjZE/AABleGFtcGxllgNVVW9mk3RoZZNpbpq443RlZ2Vy
cyyTd2hpbHN0k2uYZWVwaW5nk3RoZZNwbGFuk2Fzk2dlbmVyYWyTYXOTcJBH
HW9zc2libGUujp8rEcWNjZE/AADnM46RV0zLUHVyZZYFZmZVbmtub5qMzHdu
k0lumHRlZ2Vyc46fH+ccjZE/AACyRpH/Kqpyb22WA9v0dGhlk3NwkEcdZWNp
DGNhdGlvbnOTc3R1ZGllZJNpbpN0aGWTcHJldmlvdXOTc2VjdGlvbiyRA/2c
YZNkb21haW6Tb2aTdW5rbm+QuON3bo6hjZE/AABpbpq443RlZ2Vyc5YDulBp
c5Njb21wbGV0ZWx5k2RlDG5lZJNpZpNvbmWTZ2l2mGVzk3RoZZNiYXNpY5N1
bmtub5h3bnOTz0Jhc2ljVW5rbm93bnOOoY2RPwAAsmFuZJYDSmJ0aGWTZG9t
YWluk29mk2lumrjjdGVnZXKTdpH/ccdhbHVlc5PPRLIukQaUxEFtb25nc3ST
dGhlk2N1cnJlbph0k29wkEcdZXJhdGlvbnOTb5h2mGVyk2lumHRlLY6hjZE/
AABnZXJzlgMN3HRoZZNvcJpHHWVyYXRpb25zk2Zyb22Tz1JpbmeTsnNlZW2T
dG+TYphlk3RoZZNlc3NlbpC443RpYWyTb25lcy6RBFn0V5H/Kqplkwxyc3ST
ZGUMbmWTdGhljqGNkT8AAGZ1bmN0b3KWA1VVd2hpY5q442iTaW1wbGVtZW6Y
dHOTYWxsk3Rob3Nlk29wkEcdZXJhdGlvbnMujqkWAAGNkT8AAElulgNoyW9y
ZGVyk3Rvk2RlDG5lk3RoZZNmdW5jdG9yk29mk2RvbWFpbnOTb2aTdW5rbm+a
uON3bpNpbph0ZWdlcnMskQNtpXeYZZMMcnN0k2hhmHaYZZN0b46hjZE/AABz
cJBHHWVjaWZ5lgNVVXRob3Nlk2RvbWFpbnMujqGNkT8AAFRoZZYC85JjYXRl
Z29yeZPPSW50ZWdlck51bWJlclN5c3RlbZOyY2+VuON2k2Vyc5YC85JhbGyT
dGhlk2ltcGxlbWVumrjjdGF0aW9uc5NvZpNpbph0ZWdlcnMsjqGNkT8AAHNv
lgNVVXRoZZN0mrjjeXCQRx1lk2RvbWFpbpPPRJOybZh1c3STYpBHHWVsb25n
k3Rvk3RoaXOTY2F0ZWdvcnmR/yqqLo6hjZE/AABXkf8qqmWbA+hJaGGVuON2
k2WYbm+Td5h0b5hkZQxuZZh0aGWYY2F0ZWdvcnmYb2aYdGhlmGRvbWFpbnOY
dGiTdXOYY29uc3RydWN0ZWQukQYqo0lumHRoaXOOoY2RPwAAc2VjdGlvbiyR
BRftd5W442WbBL3PdGFrk2WYdGhlmHCQRx1vaW6TdJhvZph2aWV3mHRoYXSY
dGhlmG1vc3SYaW1wkEcdb3J0YW6TdJhvcJBHHWVyYXRpb25zmG+TdpNlco6h
jZE/AAB0aGWWA8OdaW6auON0ZWdlcnOTYXJlk3Rob3Nlk29mk2GTcmluZyyR
A98vdGhlcmVmb3Jlk3eYZZNkZWNsYXJlk3RoZZNjYXRlZ29yeZPPUmluZ5Oy
YXOTdGhljqGNkT8AAGNhdGVnb3J5lgNVVW9mk3RoZZNyZXN1bHRpbmeTZG9t
YWluLo6mjZE/AABXkf8qqmWWAjjjY5q442hvc2WTdG+TcmVwcmVzZW6YdJN0
aGWTZWxlbWVumHSTb2aTdGhpc5Nkb21haW6TYXOTz0xvY2FsQWxnZWJyYZEF
P/0oUG9seW5vbWlhbI6hjZE/AABELEQsRCmRA4BLsndoaWOauONolgOAVmlz
k2GTZG9tYWluk29mk2ZyYWN0aW9uc42NjZ/7ifeNkQUcn7RwjpEEs4mfAik7
iQAAZmUABPF+nwW/mI1ujo6OjpEOWJCyd2hlcmWTz3CTsmlzk2Fuk2VsZW1l
bph0k29mk89Qb2x5bm9taWFsjqGNkT8AAESRBVxssmFuZJYFXPLPbpOyaXOT
YW6TaW6auON0ZWdlcpNmcm9tk89Esi6TT25seZNhk2Zld5NmcmFjdGlvbnOT
YpBHHWVsb25naW5nk3Rvk3RoZZN0mHlwkEcdZY6hjZE/AADPTG9jYWxBbGdl
YnJhlgU//ShQb2x5bm9taWFsk0QsRCxEKZEDkqayYXJllgOStWFjdHVhbGx5
k3Vua25vmrjjd26TaW6YdGVnZXIukQUp6FRoZZNmdW5jLY6hjZE/AAB0aW9u
lgOLwc9gYC8nJ5OybZq443VzdJN0aGVuk2OYaGVjmGuTKHNlZZNbjc4/jpEF
bjeyXSmTdGhhdJN0aGWTZXhwcmVzc2lvbpN0aGF0k3RoZXmTYnVpbHSTcmVh
bGx5jqGNkT8AAGKQRx1lbG9uZ5YDVVV0b5N0aGlzk3N1YnNldC6OnxUAAY2R
PwAAVGhlbpYC/2V0aGWTZnVuY3RvcpNjcmVhdGluZ5Nkb21haW5zk29mk3Vu
a25vmrjjd26TaW6YdGVnZXKTKGFzk3JpbmdzKZNpc5NkZWNsYXJlZJNhczqO
nx0AAY2RPwAA8x/fpE4AAAkAAAAJAAAABWNtdHQ5ylB1cmVVbmtub3duSW50
ZWdlcpYEuZYoRCxCYXNpY1Vua25vd24pOlJpbmeTPT2TSW1wbGVtZW50YXRp
b26Td2hlcmWOpAsAAKGNkUO5lkQ6SW50ZWdlck51bWJlclN5c3RlbY6hjZFD
uZZCYXNpY1Vua25vd246TGlzdJEEuZZTeW1ib2yOoaGNkUO5lkltcGxlbWVu
dGF0aW9ulgS5lj09PpNMb2NhbEFsZ2VicmGTKFBvbHlub21pYWyTRCxELEQp
k3dpdGiOoY2RTSzCIi8ilgS5ljqTKCQsRCmTLT6TJI6hjZFNLMIrK5YEuZZh
L26TY29tcHV0ZXOTdGhlk2V4cHJlc3Npb26Td2hvc2WTdmFsdWWTaXOTYS9u
k2lmk2l0jqGNkU0swisrlgS5lmlzk2FjdHVhbGx5k2Fuk3Vua25vd26TaW50
ZWdlco6Onx4AAI2SAOkAALI1jo6MiwAAAAYAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACotoAJsAACNoP27AACgAicAAI2g/fwAAI2N
kT8AAOc0jpFXTMtDb25kaXRpb25hbJYFZmZVbmtub5qMzHduk0lumHRlZ2Vy
c46fH+ccjZE/AACySG+VuON3k2V2k2VyLJEC3kh3k2WWAsCEYWxzb5NuZWVk
k3Rvk3VzZZNvdGhlcpNvcJBHHWVyYXRvcnOTc3VjkLjjaJNhc5PPYWJzLJYF
P/09LJM8ky4uLpEEQCyyVGhlc2WRAsCEb3AtjqQMAACNkT8AAGVyYXRvcnOW
AzezY2Fubm90k2KaRx1lk2FkZGVkk3Rvk3RoZZNwcmV2aW91c5NmdW5jdG9y
k2KYZWNhdXNlk3aR/3HHYWx1ZXOTc3VjkLjjaJNhc5PPYWJzKG4pjqGNkT8A
ALJjYW5ub3SWBKqvYppHHWWTcmVwcmVzZW6QuON0ZWSTYXOTYZNwmG9seW5v
bWlhbJNvlbjjdpNlcpYEqq/PRJEEqleyd2hvc2WTdpH/ccdhcmlhYmxlc5Nh
cmWTYmFzaWOTdW4tjqGNkT8AAGtub5q443ducy6RCc0SSW6WBR5ub3JkZXKT
dG+TbW90aXaR/3HHYXRlk3RoaXOTZGlzY3Vzc2lvbiyRBZC0d5hlk2ZvkEcd
Y3Vzk29uk3RoZZNleGFtcGxlk29mjqGNkT8AAHRoZZYEcs5vcJpHHWVyYXRv
cpPPYWJzsi6RB8ozQZEEcoUMcnN0k3NvbHV0aW9uk3eQuONvdWxkk2KYZZN0
b5NjmrjjaGFuZ2WTdGhlk3JlcHJlc2VumHRhdGlvbpN0b46hjZE/AADPRXhw
cmVzc2lvbpEFP/1Esi6WBIVnQnV0k3RoaXOTc29sdXRpb26TZG+aRx1lc5Nu
b3STcJhlcm1pdJNhbpq443mTcmVhbJPMY5H/fSdvbXB1dGF0aW9ukQVJyrJv
mHaYZXKOoY2RPwAAdW5rbm+auON3bpYD2YtleHByZXNzaW9ucyyRA/qYYW5k
k3RoZZNoaWdoLWxldphlbJNjb21wdXRhdGlvbpN3mGWTd5hhbph0ZWSTdG+T
aW6YdHJvkEcdZHVjZY6hjZE/AAB0aHJvdWdolgNxOnVua25vmrjjd25zk3eY
b3VsZJNub3STYpBHHWWTYZh2kf9xx2FpbGFibGUukQTFdkaR/yqqb3KTZXhh
bXBsZSyRA3gzYW6TZXhwcmVzc2lvbpNzdWOYaJNhc46hjZE/AAAylgErHrgD
k7VhYnOyKLVusimTuACTtWFic7IoMpO4A5O1brIplgLOc2lzk29ubHmTMJNp
ZpN0aGWTY29tcHV0ZXKTYWxnZWJyYZNzeXN0ZW2Ta25vkLjjd3OTYWKQRx1v
dXSTz2Fic7IujqGNkT8AAEGRA7qNbW9yZZYDuqdjb21wbGV4k2V4YW1wbGWT
d5q44291bGSTYpBHHWWTtWFic7IotW6yKZYCfGy4AJO1brIskQPT+3doaWOY
aJYDuqdpc5N6ZXJvk2ZvcpNub24tbmVnYXRpdphljqGNkT8AALVusi6OqRYA
AY2RPwAAV5v/KqpllgPEDmOQuONob3Nlk2Fub3RoZXKTc29sdXRpb24ukQW9
81eYZZNpbpC443Ryb5BHHWR1Y2Vkk2GTbmV3k2tpbmSTb2aTb2KRAI44amVj
dHOTY2FsbGVkk85Db24tjqGNkT8AAGRpdGlvbmFskQVYOG9ikQCjjmplY3Rz
lgSlw7J0b5NlbmFibGWTbW9yZZNjb21wbGV0ZZNjb21wdXRhdGlvbi6RCGMQ
VGhvc2WTY29uZGl0aW9uYWyOoY2RPwAAb2KRAI44amVjdHOWBEqnYXJlk2V4
cHJlc3Npb26Td2l0aJNzZXaQuONlcmFsk3aR/3HHYWx1ZXOTZGVwmkcdZW5k
aW5nk29uk3NvbWWTYphvmG9sZWFuk2NvbmRpLY6hjZE/AAB0aW9ucy6Onx1D
jo2NjZE/AADORXhhbXBsZZED1VQxjo6ReTxezFRoZZYER5FleHBym/99J2Vz
c2lvbpPPYWJzKG4pk8xtYXmTYphlk3RymGFuc2xhdGWYZJN0b5N0aGlzk2OY
b25kaXRpb25hbJN1bi2OoY2RPwAAa25vd26RA5PnaW50ZZH/fSdnZXI6jp8R
cceNjZ/55mSNjY2SAL0MO2lmjo6NkgDNLlu1bpYCxxi4FZOyMI6NjZIA74RE
zHRoZW6Ojo2SAQwsDrVujo6hjY2NkgDvhETMZWxzZY6OjZIBDCwOuAC1bo6O
jo6fFc2CjZE/AADMYW5klgOT53RoZZNleHBym/99J2Vzc2lvbpPPbjxtk8xt
YXmTYphlk3RymGFuc2xhdGWYZJN0bzqOnxi1VI2Nn/nmZI2NjZIAtigTaWaO
jo2SAMZKM7VulgLHGDyTbY6NjZIA7GfSzHRoZW6Ojo2SAQkPnLV0cpBHHXVl
jo6hjY2NkgDsZ9LMZWxzZY6OjZIBCQ+ctWaRAROPYWyQMmBzZY6Ojo6fIrVV
jZE/AACyVGhllgOnbGtpbmSTb2aTY29uZGl0aW9uc5NuZWNlc3NhcnmTdG+T
ZXhwcmVzc5N0aGWTcHJldmlvdXOTZXhwcmVzc2lvbnOTYXJlk3F1aXRljqGN
kT8AAHNpbXBsZSyRBP5ZYnV0lgSpWG9uZZNjYW6Tc2Vlk3RoYXSTdGhpc5Np
c5Nub3STYWx3lbjjYZN5c5YEqVh0aGWTY2FzZS6RCG3RVGhlk3RyZWF0bWVu
kLjjdJNvZo6hjZE/AABjb25kaXRpb25zlgRr8ndpbGyTY2VydGFpbmx5k2KQ
Rx1lk3aauONlcnmTY29tcGxpY2F0ZWSTaWaTb25lk3eYYW6YdHOTdG+TdXNl
k2NvbmdydWVuY2WOoY2RPwAAcmVsYXRpb25zLo6mjZE/AABUaJq443VzlgNP
g2KQRx1lZm9yZZNkZQxuaW5nk3Vua25vmHduk2lumHRlZ2VycyyRA1Ctd5hl
k2hhmHaYZZN0b5NkZQxuZZNjb25kaXRpb25hbJNkb21haW5zOo6hjZE/AABp
LmUukQRxx3eVuONlmwNVVWhhk3aTZZh0b5hzcJBHHWVjaWZ5mHRoZZhmdW5j
dG9ymHRoYXSYYnVpbGRzmHRoZW0ujp8dQ46NjY2NkUs45DEujo6OkVgAAldo
YXSWA1VVaXOTYZNjb25kaXRpb25hbJNkb21haW4/jqGNkVgAAlRoZZYC79Nv
YpEAjjhqZWN0c5N0aGF0k2KQRx1lbG9uZ5N0b5N0aGlzk2RvbWFpbpNtYZq4
43mTaGGYdphlk2RpC2VyZW6YdJN2kf9xx2FsdWVzk2RlcJBHHWVuZC2OoY2R
WAACaW5nlgRCi29uk2NlcnRhaW6TYpVHHW+Tb2xlYW6WBEKLY29uZGl0aW9u
c5NzdWOQuONok2Fzk1xpZpO1Q42fAX//8wbZk6BSAAcAAAAHAAAABGNtcjex
MY6bBHxzsiyRBH3YaXSTaXOTtWV4cI2fAX//sTGOmLIskQR92Glmk7VDjZ8B
f/+xMo6YsiyRBH3YaXSTaXOOoY2RWAACtWV4cI2fAX//sTKOkQfRyLIuLi4i
jp8S59KNjY2NkUs45DIujo6OkVgAAldoYXSWA1VVYWKQRx1vdXSTY29uZGl0
aW9ucz+OoY2RWAACQWxslgO/DHRoZZNjb25kaXRpb25zk2Rlc2NyaWKQRx1l
k2GTdW5pcXVlk3NldCyRA9l6dGhleZNhcmWTYZNwYXJ0aXRpb26Tb2aTdGhp
c5NzZXQujo6fHgAAjZIA6QAANo6OjIsAAAAHAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAA0SqACbAAAjaD9uwAAoAInAACNoP38AACN
kVgAArJCdXSWApFIZWFjkLjjaJNzZXSTY2Fuk2KaRx1lk3NwbGl0k3dpdGiT
YZNsb3STb2aTcGFydGl0aW9uaW5nk29wmGVyYXRvcnMukQQwbkaR/yqqb3KT
ZXhhbXBsZSyOpAwAAI2RWAACtTw7lgGqqD47k7I9lgJ44W9yk2NvbmdydWVu
Y2WTcmVsYXRpb25zk3NwbGl0k3RoZZNzZXSTb2aTaW6QuON0ZWdlcnONk7U6
lgGqqDqTOo6REJxpsleR/yqqZZNkZWNpZGVkk3RoYXSOoY2RWAACYWxslgLD
inRoZZNjb25kaXRpb25zk29mk2GTY29uZGl0aW9uYWyTb2KRAI44amVjdJNt
kLjjdXN0k2KQRx1lbG9uZ5N0b5N0aGWTc2FtZZNkb21haW4sjqGNkVgAAmku
ZS6bBEZLdGhllgLS4nNldJNvZpNvcJBHHWVyYXRvcnOTaW6VuON2k29sdpNl
ZJYC0uJpc5NcaG9tb2dlbmVvdXMiLphTb5NpZpNvbmWTd5W442Fuk3RzlgLS
4nRvk3VzZY6hjZFYAAJzZXaauONlcmFslgOGbmtpbmRzk29mk2NvbmRpdGlv
bnOTb5h2mGVyk3RoZZNzYW1lk3NldJO1U5EAk42yLJEDkrRvbmWTaGFzk3Rv
k2RlDG5lk3NldphlcmFsjqGNkVgAAmRvbWFpbnOWA1VVb2aTY29uZGl0aW9u
c5NvlbjjdpNlcpEDVVW1U5EAk42yLo6pEuU6jY2NjZFLOOQzLo6OjpFYAAJX
aGF0lgNVVWFikEcdb3V0k3aR/3HHYWx1ZXM/jqGNkVgAAlaR/yqqYWx1ZXOW
A5xtb2KQuON2aW91c2x5k2KaRx1lbG9uZ5N0b5N0aGWTc2FtZZNkb21haW6T
YphlY2F1c2WTY29uZGl0aW9uYWyTb2KRAI44amVjdHOOoY2RWAACZGUMbmWW
BDpTZnVuY3Rpb25zk2Zyb22TYZNkb21haW6TtVORBM3gsnRvk2Fub3RoZXKT
ZG9tYWluk7VWkQI45LIskQRzk3RoZZNkb21haW6Tb2aOoY2RWAACdpH/ccdh
bHVlcy6Opo2NjY2RSzjkNC6Ojo6RWAACVGhlkQNVVWZ1bmN0b3I6jqGNkVgA
AkGRAo6eY29uZGl0aW9uYWyWAo7QZG9tYWluk2lzk2RlDG5lZJNmcm9tk2GT
ZG9tYWluk29mk2NvbmRpdGlvbnOTYW5kk2GTZG9tYWlujqGNkVgAAm9mlgMA
kHaR/3HHYWx1ZXMukQRVhVeR/yqqZZNob3CaRx1lk3RoYXSTdGhlk2NvbmRp
dGlvbmFsk2RvbWFpbpN3aWxsk2KYZZNhc5NwmG+VuON3k2VyZnVslgMAkGFz
k3RoZY6hjZFYAAJ2kf9xx2FsdWWWA+qnZG9tYWluLpEGMb1JbpNmYWN0k2Fs
bJN0aGWTZnVuY3Rpb25zk3doaWOauONok3N0aWxsk21lYW6Tc29tZXRoaW5n
k2+Ydphlco6hjZFYAAJjb25kaXRpb25hbJYDeAFvYpEAjjhqZWN0c5NtkLjj
dXN0k2KQRx1lk2V4dGVuZGVkLJEDgK1zb5N0aGWTY2F0ZWdvcnmTb2aTdGhl
k2NvbnN0cnVjdGVkjqGNkVgAAmRvbWFpbpYEr8TPWSeRBK9rsm2auON1c3ST
YpBHHWWTYZN3mGVha5Nmb3Jtk29mk3RoZZNjYXRlZ29yeZNvZpPPVmFsk7Jj
YWxsZWSTz1myLpNUaGWOoY2RWAACZGVjbGFyYXRpb26WA1VVb2aTdGhlk2Z1
bmN0b3KTY29uc3RydWN0aW5nk3N1Y5C442iTZG9tYWluc5NpczqOnxU9Eo2R
d3/wz0NvbmRpdGlvbmFskQU//ShDb25kOlgsVmFsOlkpOlknjp8dPRONkT8A
ALJBmrjjdJYDWFF0aGlzk3CQRx1vaW6YdCyRA1kQYZNxdWVzdGlvbpNtYZh5
k3N0cmlrmGWTdXM6kQR3vmFyZZNjb25kaXRpb25hbJNvYpEAjjhqZWN0c5Nw
YXJ0aWFsk29yk2NvbS2OoY2RPwAAcGxldGU/kQRDZ0luZGVlZCyRAuYHd5W4
42WbAso0d5NhbpN0mHRvmGtub5N3mGlmmHRoZZhsaXN0mG9mmGNvbmRpdGlv
bnOYKG+TdpNlcpi1U5EAk42yKZhvZphhmGNvbmRpdGlvbmFsjqGNkT8AAG9i
kQCOOGplY3SWAvfXYXBwbGllc5N0b5N0aGWTZnVsbJNzZXSTtVORAJONsi6R
BFKdRpH/KqpvcpNleGFtcGxlLJEDCop0aGWTZm9sbG+QuON3aW5nk2V4cHJl
c3Npb26TaXOTcGFydGlhbDqOqRiu2Y2Nn/nmZI2NkgCrJjS1ZpEBE4+yKLVu
simOjZIAyObSPY6NkgDekX+1bo6NjZIA9cr9smlmjo6NkgEOPMcwlgLHGLgU
k7Vujo6hjY2SANqt8LgAtW6OjY2SAPXK/bJpZo6OjZIBCPWptW6WAscYPJO4
ALIztTuOjo6Opo2RPwAAsndoZXJlYXOWA1VVdGhpc5NvbmWTaXOTY29tcGxl
dGU6jp8ertmNjZ/z5mSNjZIAnqY6tWaRAROPsii1brIpjo2SALxm2D2OjZIA
1spmtW6OjY2SAPK8xLJpZo6OjZIBEvWnMJYCxxi4FJO1bo6OoY2NkgDOLfZu
lgI44LIrkzOOjY2SAPK8xGlmjo6NkgEF53C4ALIzlgLHGLgUk7VukzyTsjCO
jqGNjZIA0ubXuAC1bo6NjZIA8rzEsmlmjo6NkgENrom1bpYCxxg8k7gAsjO1
Oo6Ojo6fKK7ajZE/AACyV5H/KqpllgJvCGOQuONob3Nlk3Rvk2NvbnNpZGVy
k2FsbJN0aGWTY29uZGl0aW9uYWyTb2KRAI44amVjdHOTYXOTY29tcGxldGWT
YW5kk2FsbJN0aGWTZnVuY3Rpb25zjqGNkT8AAGRlDG5lZJsDVVVvlbjjdpNl
cph0aGlzmGRvbWFpbphtk3VzdJhrk2VlcJh0aGlzmGNvbXBsZXRlbmVzcy6O
nxYAAY2RPwAASW6WBGCyb3JkZXKTdG+TZGUMbmWTdGhlk2RvbWFpbpNvZpN1
bmtub5q443duk2lumHRlZ2VycyyRBKOJdJh3mG+TY29uZGl0aW9uYWyTZG9t
YWluc46hjZE/AABtmrjjdXN0lgPtB2KQRx1lk2NyZWF0ZWQ6kQWhKnRoZZNj
b25kaXRpb25hbJN1bmtub5h3bpNpbph0ZWdlcpMoZm9yk3RoZZNvcJBHHWVy
YXRvcpPPYWJzsimTYW5kjqGNkT8AAHRoZZYCZodkb21haW6Tb2aTY29uZGl0
aW9uYWyTYpVHHW+Tb2xlYW6WAmaHKGZvcpPPaW5mPyxlcT+yKS6RBCIuRpH/
KqpvcpN0aGlzk3B1cnCQRx1vc2WTdJW443eTb5ECZodmdW5jdG9yc46hjZE/
AABoYZW443aTZZYCo/FikEcdZWVuk2RlDG5lZDqRBBkVdGhlkwxyc3STZm9y
k2NvbmRpdGlvbmFsk3JpbmdzkyhjYWxsZWSTz0NvbmRpdGlvbmFsUmluZ7Ip
LJECx2xhbmSOoY2RPwAAdGhllgSccXNlY29uZJNmb3KTY29uZGl0aW9uYWyT
ZG9tYWluc5NzaW1pbGFyk3Rvk2KVRx1vk29sZWFulgSccShjYWxsZWSTz0Nv
bmRpdGlvbmFsLY6hjZE/AABFeHRlbmRlZEJvb2xlYW6yKS6OnxUAAY2RPwAA
VGhllgNVVWZ1bmN0b3KTb2aTZG9tYWluc5NvZpNjb25kaXRpb25hbJN1bmtu
b5q443duc5Npc5NkZQxuZWSTYXOTZm9sbG+Yd3OTOo6Onx4AAI2SAOkAADeO
joyLAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
P4ugAmwAAI2g/bsAAKACJwAAjaD9/AAAjZE/AADKQ29uZGl0aW9uYWxVbmtu
b3duSW50ZWdlcpEEuZYoRCxCYXNpY1Vua25vd24pOkV4cG9ydHOOpAsAAI2R
TSzCPT2WBLmWSW1wbGVtZW50YXRpb26Td2hlcmWOoaGNkUO5lkSWBLmWOpNJ
bnRlZ2VyTnVtYmVyU3lzdGVtjqGNkUO5lkJhc2ljVW5rbm93bpYEuZY6k0xp
c3STU3ltYm9sjqGhjZFDuZZDlgS5lj09PpNFbGVtZW50YXJ5SW50ZWdlckNv
bmRpdGlvbnOTQmFzaWNVbmtub3dujqGNkUO5llYxlgS5lj09PpNQdXJlVW5r
bm93bkludGVnZXKTKEQsQmFzaWNVbmtub3duKY6hjZFDuZZWMpYEuZY9PT6T
Q29weUJvb2xlYW6OoY2RQ7mWQ1YylgS5lj09PpNDb25kaXRpb25hbEV4dGVu
ZGVkQm9vbGVhbpMoQyxWMimOoaGNkUO5lkV4cG9ydHOWBLmWPT0+k0pvaW4o
Q29uZGl0aW9uYWxDYXRlZ29yeZMoQyxWMSksUmluZymTd2l0aI6hjZFNLMJh
YnOWBLmWOpMkky0+kySOoY2RTSzCKyuWBLmWYWJzKGEpk2NvbXB1dGVzkzqT
aWaTYT4wk3RoZW6TYSyTaWaTYT0wk3RoZW6TMCyTZWxzZZMtYSyOoY2RTSzC
aW5mP5YEuZY6kygkLCQpky0+k0NWMo6hjZFNLMIrK5YEuZZpbmY/kyhhLGIp
k2NvbXB1dGVzkzqTaWaTYTxik3RoZW6TVHJ1ZZNlbHNlk0ZhbHNljqGNkU0s
wmVxP5YEuZY6kygkLCQpky0+k0NWMo6hjZFNLMIrK5YEuZZlcT+TKGEsYimT
Y29tcHV0ZXOTOpNpZpNhPWKTdGhlbpNUcnVlk2Vsc2WTRmFsc2WOoY2RTSzC
Ii8ilgS5ljqTKCQsRCmTLT6TJI6hjZFNLMIrK5YEuZZhL26TY29tcHV0ZXOT
dGhlk2NvbmRpdGlvbmFsk29iamVjdJN3aG9zZZN2YWx1ZY6hjZFNLMIrK5YE
uZZpc5NhL26TaWaTaXSTaXOTYW6TZWxlbWVudJNvZpNWMZNlbHNlk2Vycm9y
jp8cqIiNkT8AALJUaGWWA0sUaW1wbGVtZW6QuON0YXRpb26Tb2aTdGhpc5Nm
dW5jdG9yk2lzk89Db25kaXRpb25hbFJpbmeRBT/9KEMsVjEpk7J3aXRok3Ro
ZZNkZQwtjp8MAACNkT8AAG5pdGlvbnOWA1VVb2aTdGhlk2Z1bmN0aW9uc5Mo
bm90k2KQRx1lbG9uZ2luZ5N0b5PPUmluZ7Ipk89hYnMslgU//WluZj8sk2Vx
PyyTIi8ikQNVVbJhZGRlZC6OnyrH1I2NkT8AAOc1jpFXTMtDb25jbHVzaW9u
jp8e5xyNkT8AALJUaGWWBGwSZGUMbml0aW9uk29mk2NvbmRpdGlvbmFsk3B1
cmWTdW5rbm+auON3bpNpbph0ZWdlcnOTDHRzk3CQRx1lcmZlY3RseZN0aGWT
Zm9ybWFsjqGNkT8AAGRlDG5pdGlvbpYEqWNvZpN1bmtub5q443duk2lumHRl
Z2Vyc5NwcmV2aW91c2x5k2dpdphlbiyRBP5mc2+TdGhlk3SYd5hvk2Z1bmN0
b3Jzk2FyZZN0aGWOoY2RPwAAc2FtZS6RBhE6V2l0aJYD39F0aGlzk25ld5N0
mrjjeXCQRx1lLJEEAm9vbmWTY2Fuk2NvbXB1dGWTc29tZZNleHByZXNzaW9u
c5NpbpNhk3eYYZh5k3F1aXRljqGNkT8AAGRpC2VyZW6QuON0lgNVVWZyb22T
dGhlk3VzdWFsk29uZTqOnxuoiI2RPwAAyigxKZYEuZYtPpNjdZM6PZMobioo
bisxKS8yKTo6Q29uZGl0aW9uYWxVbmtub3duSW50ZWdlcihbbixtLHBdLElu
dGVnZXIpjqGhjZIAlAyMMo6hjZIAj1L2bpEJcywrkQS5lm6OoY2RTSzCKDEp
kQlzLChUcnVllgS5li0+ky0tLS0tLSmOoY2SAJ1/uDKOoY2RfGyeVHlwZTqR
BLmWQ29uZGl0aW9uYWxVbmtub3duSW50ZWdlcihbbixtLHBdLEludGVnZXIp
jqGNkT8AACgyKZYEuZYtPpNhYnOTY3WOoaGNkgDDTGgyjqGNkgC1H6YtlgS5
lm6RCXMsLZNujqGNkU0swigyKZEJcywoKG4obpYEuZYrkzEpPDApky0+ky0t
LS0tLS0tKY6Onx4AAI2SAOkAALI4jo6MiwAAAAkAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEs+oAJsAACNoP27AACgAicAAI2g/fwA
AI2SAMgF/soyjqQLAACNkWTMsCgobihulgS5liuTMSk9MCmTLT6TMCmOoY2S
ALnZPDKOoY2SALUfpm6RCXMsK5EEuZZujqGNkWTMsCgobihulgS5liuTMSk+
MCmTLT6TLS0tLS0tKY6hjZIAw0xoMo6hjZF8bJ5UeXBlOpEEuZZDb25kaXRp
b25hbFVua25vd25JbnRlZ2VyKFtuLG0scF0sSW50ZWdlcimOnx4AAY2RPwAA
slN1Y5W442ibA1LodGVjk2hub2xvZ3mYY2FumGKQRx1lmGFwcGxpZWSYdG+Y
b3RoZXKYcHJvYmxlbXMskQNTZWFzmGZhcphhc5hjb25kaXRpb25hbJhyZXN1
bHRzjqQMAACNkT8AAGFyZZYCWF5uZWVkZWQukQQddUaR/yqqb3KTZXhhbXBs
ZSyRAor2aXSTaXOTdXNlZnVsk2luk3NvbWWTY29tcHV0YXRpb25zk29mk2xp
bWl0c5MotWyQMmBpbY2fAX//tHjzDE8h4oUABwAAAAcAAAAFY21zeTe3ITGO
kRT6rrVhZY2f/F7/tHiOjqGNkT8AALJkZXCQRx1lbmRzlgNVVW9uk3RoZZNz
aWduk29mk7Vhsiksk2lukLjjdGVncmFsc42TtTqWAaqoOpM6jo6fKxHFjZE/
AADnUmVmZXJlbmNlc46fGecbjY2NkT8AALJbRGGQuON2OTJdjo6RZTHNSi5I
LpsDVVVEYZW443aTZW5wkEcdb3J0LphIb5N3mGRvkEcdZXOYb25lmHByb2dy
YW2YaW6YdGhlmGF4aW9tmHN5c3RlbS6YMTk5Mi6OqRQAAI2NjZE/AABbRpH/
KqphdTkyXY6OkWUxzUMulgMdekaR/yqqYXVyZS6TzFF1ZWxxdWVzmwNghGFz
cJb/fSdlk2N0c5hkZZhsYZhTaW1wbGkMY5NhdGlvbphlbphDYWxjdWyYRpH/
O7xvcm1lbLIukQMdelBoRI6hjZFlMc10aGVzaXMsmwNVVVVuaXaVuONlcnNp
dJMTkftHHGWYZGWYTmljZZhTb3BoaWEtQW6TdGlwkEcdb2xpcyyYMTk5Mi6O
po2NjZE/AABbSlM5MmFdjo6RZTHNUi5ELpYCrRVKZW5rc5NhbmSTUi5TLpNT
dXRvci6TzEF4aW9tlgL5HlRoZZNTY2llbnRpDGOTQ29tcHV0YXRpb26TU3lz
dGVtsiyOoY2RZTHNY5C442hhcHRlcpYDVVUxMyyTcGFnZXOTNTI3ezU0Ni6T
U3ByaW5nZXItVpH/KqplcmxhZyyTMTk5Mi6Opo2NjZE/AABbSlM5MmJdjo6R
ZTHNUi5ELpYCrRVKZW5rc5NhbmSTUi5TLpNTdXRvci6TzEF4aW9tlgL5HlRo
ZZNTY2llbnRpDGOTQ29tcHV0YXRpb26TU3lzdGVtsiyOoY2RZTHNY5C442hh
cHRlcpYDVVUxMiyTcGFnZXOTNTE1ezUyNi6TU3ByaW5nZXItVpH/Kqplcmxh
ZyyTMTk5Mi6OnysRxY2RPwAA51RoZZEFZmZBdXRob3Jzjp8f5xyNkT8AAM5Q
cm9mLpYDAulKYW1lc5NEYZWuOXaTZW5wkFHHb3J0lgKeXLJ0b5BHHW9rk2hp
c5NkZWdyZWVzk2F0k0NhbZq442JyaWRnZZNVbml2mGVyc2l0mHmTKEVuZ2xh
bmQpLo6hjZE/AABIZZYE9UFpc5Nub5q443eTYXSTQmF0aJNVbml2mGVyc2l0
mHmR/yqqLJEFXTx3aGVyZZNoZZNpc5NIZWJyb26TJpNNZWRsb5BHHWOYa5NQ
cm9mZXNzb3KTb2aOoY2RPwAASW5mb3JtYXRpb26bA1liVJb/KqplY5C442hu
b2xvZ3mTLJEDWmVhbmSYSGVhZJhvZph0aGWYU2OQuONob5BHHW9smG9mmE1h
dGhlbWF0aWNhbJhTY2llbmNlcy6RBH3tSGWOoY2RPwAAaGFzmwQd2neVuONv
cmuTZWSYZXh0ZW5zaXaTZWx5mG9umHRoZZhSZWR1Y2WYYW5kmEF4aW9tmGNv
bXB1dGVymGFsZ2VicmGYc3lzdGVtcyyOoY2RPwAAYW5klgLFNWhhc5N3cml0
dGVuk3RoZZNilUcdb5Nva3ObAsU1zE9ulgMPT3RoZZNJbnRllv99J2dyk2F0
aW9ulgMPT29mk0GQvpNsZ2VicpH/fSdhaWOTRpH/O7x1bmN0aW9uc5EDl1ay
YW5kmMxDYWxjdWyOoY2RPwAARpH/O7xvcm1lbJYDci2yKHdpdGiTWS6TU2ly
ZXSTYW5kk0Uuk1SR/yqqb3VybmllcikukQTIT0JvdGiTYpVHHW+Tb2tzmwNy
LWhhlbjjdpNlmGKQRx1lZW6YdHJhbnNsYXRlZJhpbpN0b46hjZE/AABSdXNz
aWFuLo6fFgABjZE/AADORHIulgK2K0NocmlzdJDCqxKR+n1XZWxlk0aR/wqr
YXVyZZYCW6CydG+aRx1va5NoZXKTZGVncmVlc5NhdJN0aGWTVW5pdpW442Vy
c2l0k3mWAlugb2aTTmljZXtTb3BoaWGTQW6QuON0aXCYby2OoY2RPwAAbGlz
lgNpjyhGkf8qqnJhbmNlKS6RBK52U2hlk3NwmkcdZW6QuON0kzE5OTJ7OTOT
YXOTYZNwmG9zdC1kb5hjdG9yYWyTcmVzZWFyY5q442hlcpNhdJN0aGWTVW5p
dphlcnNpdJh5jqGNkT8AAG9mlgNVVUJhdGgsk3eQuONvcmtpbmeTb26TdGhl
k3N1YpEAjjhqZWN0k29mk3RoaXOTcGFwkEcdZXKTYW5kk2l0c5NpbXBsaWNh
dGlvbnMujo6fHgAAjZIA6QAAOY6OjPgAAFIvAYOSwBw7AAAAAAPoAmwAAAGY
AAAACQAJ81nfQ8pzAAgAAAAIAAAABWNtdHQ48z5E0+10ABFHrgARR64ABWNt
cjE38zzC1k6gAA5mZgAMAAAABmNtYngxMvM234a1VAAMAAAADAAAAAZjbXR0
MTLzMFirUQsADAAAAAwAAAAFY21yMTLzJN/qPHgACgAAAAoAAAAGY210dDEw
8yMa8iJWAAoAAAAKAAAABmNtYngxMPMh/QAnOgAKAAAACgAAAAZjbXRpMTDz
H9+kTgAACQAAAAkAAAAFY210dDnzHnQMiToACQAAAAkAAAAFY21ieDnzHKmx
kMoACQAAAAkAAAAFY21zeTnzGzX5niIACQAAAAkAAAAFY21taTnzGm+0i8cA
CQAAAAkAAAAEY21yOfMXvkvICwAIAAAACAAAAAVjbXN5OPMVfHtZBwAIAAAA
CAAAAARjbXI48xFxoSULAAYAAAAGAAAABWNtc3k28xAQzb7OAAYAAAAGAAAA
BWNtbWk28w0hIiyaAAoAAAAKAAAABmNtc3kxMPMMTyHihQAHAAAABwAAAAVj
bXN5N/MKC6BiPgAKAAAACgAAAAZjbW1pMTDzCTBll3IABwAAAAcAAAAFY21t
aTfzB0vxYHkACgAAAAoAAAAFY21yMTDzBtmToFIABwAAAAcAAAAEY21yN/kA
AFrKAt/f398=
--279709440-297597986-1088001925=:25976--

\start
Date: Wed, 23 Jun 2004 16:54:52 +0000
From: Martin Rubey
To: list
Subject: Re: semantics of #1

Martin Rubey writes:
 > Does anybody know about the exact semantics of #1 in compiled code?
 > 
 > For example, the following does not work:
 > 
 > )abbrev package TEST Test
 > Test(F): Cat == Body where
 >     F: Field
 > 
 >     Cat == with
 >             tst: (F, List F, List F) -> Boolean
 > 
 >     Body == add
 >       tst (e, lst1, lst2) ==
 >         any?(e=elt(lst1, #1), lst2)
 
Sorry, this was nonsense: replacing the final List F by List Integer, the
example works. However, here is the real thing which I can't get to work:

)abbrev package RINTERPA RationalInterpolationAlgorithms
++ Description:
++ This package exports rational interpolation algorithms
RationalInterpolationAlgorithms(F, P): Cat == Body   where
    F: Field 
    P: UnivariatePolynomialCategory(F)
    Cat == with
        RationalInterpolation: (List F, List F, NonNegativeInteger, 
                                NonNegativeInteger) 
                               -> Union(Record(function: Fraction P,
                                               undefined: List Integer,
                                               unattainable: List Integer),
                                        "failed")

    Body == add
        RationalInterpolation(xlist, ylist, m, k) ==
            #xlist ^= #ylist =>
                error "Different number of points and values."
            #xlist ^= m+k+1 =>
                error "wrong number of points"
            tempvec: List F := [1 for i in 1..(m+k+1)]

            collist: List List F := cons(tempvec, 
                                         [(tempvec := [tempvec.i * xlist.i _
                                                       for i in 1..(m+k+1)]) _
                                          for j in 1..max(m, k)])

            collist := append([collist.j for j in 1..(m+1)], _
                              [[- collist.j.i * ylist.i for i in 1..(m+k+1)] _
                               for j in 1..(k+1)])
            resspace: List Vector F := nullSpace((transpose matrix collist) _
                                                 ::Matrix F)

            reslist: List List P := _
                      [[monomial((resspace.1).(i+1), i) for i in 0..m], _
                      [monomial((resspace.1).(i+m+2), i) for i in 0..k]]

            den := reduce((_+), reslist.2)
            zero?(den) => "failed"

            fun := reduce((_+), reslist.1)/den

            denres := denom(fun)

            una: List Integer := []
            und: List Integer := []
            for i in 1..#xlist repeat
              if zero?(elt(denres, xlist.i)) then 
                und := cons(i, und)
                una := cons(i, una)
              else if zero?(elt(den, xlist.i)) and 
                      elt(fun, xlist.i) ~= ylist.i then 
                     una := cons(i, una)

            [fun, una, und]

)abbrev package RINTERP RationalInterpolation
++ Description:
++ This package exports interpolation algorithms
RationalInterpolation(xx, F): Cat == Body   where
    xx: Symbol
    F:  Field
    UP  ==> UnivariatePolynomial
    SUP ==> SparseUnivariatePolynomial
 
    Cat == with
        interpolate: (Fraction UP(xx, F), List F, List F, _
                      NonNegativeInteger, NonNegativeInteger) _
                      -> Union(Record(function: Fraction UP(xx, F),
                                      undefined: List Integer,
                                      unattainable: List Integer),
                               "failed") 

    Body == add
        RIA ==> RationalInterpolationAlgorithms

        tst: (F, List F, List Integer) -> Boolean
        tst (e, lst1, lst2) ==
          any?(e=elt(lst1, #1), lst2)

        interpolate(qx, lx, ly, m, k) ==
            px := RationalInterpolation(lx, ly, m, k)$RIA(F, UP(xx, F))

            (px case "failed") => "failed"

            if ((qnum := retractIfCan(numer qx)@Union(F, "failed")) case F) and
               ((qden := retractIfCan(denom qx)@Union(F, "failed")) case F) then
              q := qnum/qden
--              if tst(q, lx, px.unattainable) then _
--                return "failed"
              if any?(q::F=elt(lx::List(F), #1), (px.unattainable)::List(Integer)) then 
                return "failed"                  

            [elt(px.function, qx), px.undefined, px.unattainable]

using tst, it works, using any?, it doesn't...

HELP!

\start
Date: Wed, 23 Jun 2004 11:03:43 -0400
From: William Sit
To: Martin Rubey
Subject: Re: any?, member?, ...

Martin Rubey wrote:
> 
> I noticed that these function evaluate the predicate for all elements of the
> argument list, which I find rather strange. For example:
> 
> (2) -> any?(i+->(output(i);(i=1)::Boolean),[1,2,3])
>    1
>    2
>    3
> 
>    (2)  true
>                                                                 Type: Boolean
> 
> Wouldn't it be sensible to define these functions so that they exit when the
> result is determined, i.e., instead of
> 
>      any?(f, c)           == _or/[f x for x in parts c]
>      every?(f, c)         == _and/[f x for x in parts c]
> 
> do
> 
>      any?(f, c) ==
>        for x in parts c repeat
>          if f x then return true
>        false
> 
>      every?(f, c) ==
>        for x in parts c repeat
>          if not f x then return false
>        true
> 
> It seems that for TREE, some shortcircuiting is done:
> 
>     any?(fn, t) ==  ---bug fixed
>       t case empty => false
>       fn value t or "or"/[any?(fn, c) for c in children t]
>     every?(fn, t) ==
>       t case empty => true
>       fn value t and "and"/[every?(fn, c) for c in children t]
> 

That was my thoughts when I read your preliminary patch 3148:

>      dvdsum(l, x) ==
>        x = retract(y := third l)@SE => 0
> -      k := retract(d := second l)@K
> -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
> -        - differentiate(g := third rest l, x) * eval(f, k, g)
> -             + opdsum [differentiate(f, x), d, y, g, h]
> +      if member?(x, variables(h := third rest rest l)) or 
> +         member?(x, variables(g := third rest l)) then
> +        dm := dummy
> +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
> +      else
> +        opdsum [differentiate(first l, x), second l, y, g, h]
>  

Note that g would not have been defined in some cases in the last line if the
operator OR does not evaluate all its clauses first. I was about to suggest that
you define h and g outside of the IF statement to make it more robust, but
decided it's ok. I was under the impression also that exactly how the logical
operators evaluate was compiler/optimisation dependent, but I wasn't sure.

In general, I would prefer not to use side-effects in programming in arguments
for logical operators.

\start
Date: Wed, 23 Jun 2004 17:13:36 +0000
From: Martin Rubey
To: William Sit
Subject: Re: any?, member?, ...

William Sit writes:
 > That was my thoughts when I read your preliminary patch 3148:
 > 
 > >      dvdsum(l, x) ==
 > >        x = retract(y := third l)@SE => 0
 > > -      k := retract(d := second l)@K
 > > -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
 > > -        - differentiate(g := third rest l, x) * eval(f, k, g)
 > > -             + opdsum [differentiate(f, x), d, y, g, h]
 > > +      if member?(x, variables(h := third rest rest l)) or 
 > > +         member?(x, variables(g := third rest l)) then
 > > +        dm := dummy
 > > +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
 > > +      else
 > > +        opdsum [differentiate(first l, x), second l, y, g, h]
 > >  
 > 
 > Note that g would not have been defined in some cases in the last line if
 > the operator OR does not evaluate all its clauses first. 

Hmm, if the first member? succeeds, g won't be defined but that's no problem,
because it won't be used. If the first member? fails, the second member? will
be evaluated and g will be defined. Only if both member? fail, the "else" part
of the if statement will be evaluated and only in this case g is needed.

\start
Date: Wed, 23 Jun 2004 17:29:11 +0000
From: Martin Rubey
To: list
Subject: Re: semantics of #1

It's worse, the following works:

        interpolate(qx, lx, ly, m, k) ==
            px := RationalInterpolation(lx, ly, m, k)$RIA(F, UP(xx, F))

            (px case "failed") => "failed"

            if ((qnum := retractIfCan(numer qx)@Union(F, "failed")) case F) and
               ((qden := retractIfCan(denom qx)@Union(F, "failed")) case F) then
              q := qnum/qden
              una := px.unattainable
              if any?(q::F=elt(lx, #1), una) then return "failed"
--              for i in px.unattainable repeat
--                if elt(lx, i)=q then return "failed"

            [elt(px.function, qx), px.undefined, px.unattainable]

but not if I inline "una". Still more interesting:

        interpolate(qx, lx, ly, m, k) ==
            px := RationalInterpolation(lx, ly, m, k)$RIA(F, UP(xx, F))

            (px case "failed") => "failed"

            if ((qnum := retractIfCan(numer qx)@Union(F, "failed")) case F) and
               ((qden := retractIfCan(denom qx)@Union(F, "failed")) case F) then
              q := qnum/qden
              una := px.unattainable
              if any?(q::F=elt(lx, #1), px.unattainable) then return "failed"
--              for i in px.unattainable repeat
--                if elt(lx, i)=q then return "failed"

            [elt(px.function, qx), px.undefined, px.unattainable]

works!

\start
Date: Wed, 23 Jun 2004 11:36:10 -0400
From: William Sit
To: Martin Rubey
Subject: Re: any?, member?, ...

Martin Rubey wrote:
> 
> William Sit writes:
>  > That was my thoughts when I read your preliminary patch 3148:
>  >
>  > >      dvdsum(l, x) ==
>  > >        x = retract(y := third l)@SE => 0
>  > > -      k := retract(d := second l)@K
>  > > -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
>  > > -        - differentiate(g := third rest l, x) * eval(f, k, g)
>  > > -             + opdsum [differentiate(f, x), d, y, g, h]
>  > > +      if member?(x, variables(h := third rest rest l)) or
>  > > +         member?(x, variables(g := third rest l)) then
>  > > +        dm := dummy
>  > > +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
>  > > +      else
>  > > +        opdsum [differentiate(first l, x), second l, y, g, h]
>  > >
>  >
>  > Note that g would not have been defined in some cases in the last line if
>  > the operator OR does not evaluate all its clauses first.
> 
> Hmm, if the first member? succeeds, g won't be defined but that's no problem,
> because it won't be used. If the first member? fails, the second member? will
> be evaluated and g will be defined. Only if both member? fail, the "else" part
> of the if statement will be evaluated and only in this case g is needed.

Ooops. You are correct.

But the point I was trying to make is that if side-effects in logical clauses
may be unevaluated, that would make assessing the correctness of the code more
difficult. (Your explanation above would have to be expanded if there were more
clauses).

BTW: should dm:=new()$SE be used instead?

\start
Date: Wed, 23 Jun 2004 17:38:21 +0000
From: Martin Rubey
To: William Sit
Subject: Re: Patch 3148, was: any?, member?, ...

William Sit writes:
 > Martin Rubey wrote:
 > > 
 > > William Sit writes:
 > >  > That was my thoughts when I read your preliminary patch 3148:
 > >  >
 > >  > >      dvdsum(l, x) ==
 > >  > >        x = retract(y := third l)@SE => 0
 > >  > > -      k := retract(d := second l)@K
 > >  > > -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
 > >  > > -        - differentiate(g := third rest l, x) * eval(f, k, g)
 > >  > > -             + opdsum [differentiate(f, x), d, y, g, h]
 > >  > > +      if member?(x, variables(h := third rest rest l)) or
 > >  > > +         member?(x, variables(g := third rest l)) then
 > >  > > +        dm := dummy
 > >  > > +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
 > >  > > +      else
 > >  > > +        opdsum [differentiate(first l, x), second l, y, g, h]
 > >  > >
 > >  >
 > >  > Note that g would not have been defined in some cases in the last line if
 > >  > the operator OR does not evaluate all its clauses first.
 > > 
 > > Hmm, if the first member? succeeds, g won't be defined but that's no problem,
 > > because it won't be used. If the first member? fails, the second member? will
 > > be evaluated and g will be defined. Only if both member? fail, the "else" part
 > > of the if statement will be evaluated and only in this case g is needed.
 > 
 > Ooops. You are correct.
 > 
 > But the point I was trying to make is that if side-effects in logical clauses
 > may be unevaluated, that would make assessing the correctness of the code more
 > difficult. (Your explanation above would have to be expanded if there were more
 > clauses).

You are correct, too...

 > BTW: should dm:=new()$SE be used instead?

well, I think yes, but only if we change all occurrences of dummy to
new()$SE. In the near future (release 1) there should be a pamphlet file that
incorporates all the patches and explains them, too.

\start
Date: Wed, 23 Jun 2004 12:08:40 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Patch 3148, was: any?, member?, ...

Martin Rubey wrote:
>      dvdsum(l, x) ==
>        x = retract(y := third l)@SE => 0
> -      k := retract(d := second l)@K
> -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
> -        - differentiate(g := third rest l, x) * eval(f, k, g)
> -             + opdsum [differentiate(f, x), d, y, g, h]
> +      if member?(x, variables(h := third rest rest l)) or
> +         member?(x, variables(g := third rest l)) then
> +        dm := dummy
> +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
> +      else
> +        opdsum [differentiate(first l, x), second l, y, g, h]

>  William Sit wrote:
>  > BTW: should dm:=new()$SE be used instead?
> 
> well, I think yes, but only if we change all occurrences of dummy to
> new()$SE. In the near future (release 1) there should be a pamphlet file that
> incorporates all the patches and explains them, too.

I thought all occurrences of dummy in combfunc.spad were replaced. Besides the
definition dummy=new()$Symbol, there were four occurrences in the functions
product and summation, all were replaced effectively with inline calls to
new()$Symbol assigned to a local variable. The dummy in the patch above is the
only one left. So, the patch is correct as it is because dummy is now used only
once in combfunc.spad. However, I think removing all references to dummy
(including its definition) and using a local version each time will avoid
possible future mistakes similar to the ones you are patching.

Regarding your suggestion to have a pamphlet file "that ... explains them", I
think perhaps the pamphlet file should add another tag like "history" that could
be extracted separately into a tex file documenting just the changes, but in
chronological order. It will make those times when one wants to just read the
final code easier, especially for files that needed many patches.

\start
Date: Wed, 23 Jun 2004 18:37:22 +0000
From: Martin Rubey
To: William Sit
Subject: Re: history, was: Patch 3148, was: any?, member?,...

William Sit writes:
 > I thought all occurrences of dummy in combfunc.spad were replaced. Besides the
 > definition dummy=new()$Symbol, there were four occurrences in the functions
 > product and summation, all were replaced effectively with inline calls to
 > new()$Symbol assigned to a local variable. The dummy in the patch above is the
 > only one left. So, the patch is correct as it is because dummy is now used only
 > once in combfunc.spad. However, I think removing all references to dummy
 > (including its definition) and using a local version each time will avoid
 > possible future mistakes similar to the ones you are patching.

I agree.

 > Regarding your suggestion to have a pamphlet file "that ... explains them", I
 > think perhaps the pamphlet file should add another tag like "history" that could
 > be extracted separately into a tex file documenting just the changes, but in
 > chronological order. It will make those times when one wants to just read the
 > final code easier, especially for files that needed many patches.


CVS does this automagically.

\start
Date: Wed, 23 Jun 2004 11:43:53 -0400
From: Tim Daly
To: William Sit, Martin Rubey
Subject: history

William,

When I put patches in any file the technique used is to clip out the
old code, replace it with a chunk name, and insert the new code from
the chunk. Thus,

IF THE CODE READ:

   first line of code
   buggy line of code
   third line of code

UPON RECEIVING A PATCH TO THE BUGGY LINE SUCH AS:
==========================================================
Tim,

   buggy line of code

should be replaced by

   fixed line of code
because the buggy line of code is bad. the reason is that
it will compute the wrong answer. For instance, given this
   axiom input example
we get this output
   axiom buggy output
but it should read
   axiom fixed output
and this change fixes it.

============================================================
THE NEW FILE WOULD READ:

\section{fixed line of code change}
The code used to read:
\begin{verbatim}
   buggy line of code
\end{verbatim}
because the buggy line of code is bad. the reason is that
it will compute the wrong answer. For instance, given this
   axiom input example
we get this output
   axiom buggy output
but it should read
   axiom fixed output
and this change fixes it.

<<fixedline>>=
   fixed line of code
@

........

   first line of code
<<fixedline>>   
   third line of code


=================================================================

so you can see that the chunking/latex technology allows me to
document what was changed and why it was changed. So far I haven't
really gotten direct patch requests for anything although there
has been much debate on the list. I'm following the debate but
unless somebody sends me an explicit patch no change takes place.
I could jump in and code a random patch in the middle of the 
discussion but there are many different opinions (witness the
0^0 debate) which I'm not qualified to judge. I'm hoping that
once the dust settles someone will code up an agreed-upon patch
and send it to me. 

\start
Date: Wed, 23 Jun 2004 11:54:48 -0400
From: Tim Daly
To: James Davenport
Subject: indefinites
Cc: Richard Fateman

James,

As usual, your paper anticipates our current research work. 
Your ideas are spot on although we have slightly different
implementation ideas.

Should you come across the algebra anywhere I'd be happy to 
stealfollow your lead on this. :-)

\start
Date: Wed, 23 Jun 2004 22:14:15 +0200
From: David Mentre
To: Martin Rubey
Subject: Re: semantics of #1

Stupid guess: have you always spaces or mixed spaces and tabs? Spad is
quite sensitive to (invisible) wrong indentation.

\start
Date: Wed, 23 Jun 2004 17:04:17 -0400
From: Tim Daly
To: David Mentre
Subject: Re: semantics of #1

eh? i never use tabs (except in makefiles). tabs are evil and should
be abolished from all possible fonts/alphabets/character sets. 

that said, Axiom is sensitive to indentation. I'm not really sure what
it does with tabs as I've never used one in Axiom.

\start
Date: Thu, 24 Jun 2004 09:33:27 +0000
From: Martin Rubey
To: David Mentre
Subject: Re: semantics of #1

David Mentre writes:
 > Stupid guess: have you always spaces or mixed spaces and tabs? Spad is
 > quite sensitive to (invisible) wrong indentation.

The guess is not so stupid, still its wrong -- unfortunately, I'm tempted to
say. It seems as though axiom is able to guess the correct type for
px.unattainable if the line 

            una := px.unattainable

is present, otherwise not. But this is only a guess. I tried, but I was unable
to declare #1 or px.unattainable to help axiom.


            if ((qnum := retractIfCan(numer qx)@Union(F, "failed")) case F) and
               ((qden := retractIfCan(denom qx)@Union(F, "failed")) case F) then
              q := qnum/qden
--              una := px.unattainable
              if any?(q::F=elt(lx, #1), px.unattainable) then return "failed"


\start
Date: Thu, 24 Jun 2004 12:10:47 -0400
From: Bill Page
To: Tim Daly
Subject: indefinites

On Tuesday, June 22, 2004 9:59 AM Tim Daly
wrote:

> ... 
> We've been looking at the issue in terms of indefinites.
> In the current version of Axiom if you type:
> 
>   x+1
> 
> 'x' is known to be a symbol
> '1' is known to be an integer
> there is no plus which takes +(symbol,integer)
> so 'x' gets promoted to polynomial over integers
> '1' gets promoted to polynomial over integers
> '+(POLY(INT),POLY(INT)) exists
> and the result is
>   x + 1
>          Type: Polynomial Integer
> 

When I started using Axiom I was very surprised by the
following:

(1) -> x

   (1)  x
                                           Type: Variable x
(2) -> x+1

   (2)  x + 1
                                           Type: Polynomial Integer
(3) -> x:Symbol
                                           Type: Void
(4) -> x

   (4)  x
                                           Type: Symbol
(5) -> x+1

   (5)  x + 1
                                           Type: Polynomial Integer
(6) -> x:Integer
                                           Type: Void
(7) -> x

   x is declared as being in Integer but has not been given a value.
(7) -> x+1

   x is declared as being in Integer but has not been given a value.

(7) -> x::Symbol

   x is declared as being in Integer but has not been given a value.

--------

First, the type of x if no domain has be declared is "Variable x"
not symbol. That seems very odd (even wrong?) In what sense is
"Variable x" a domain? This seems like unnecessary confusion at
a rather basic level. But whatever "Variable x" is, it can apparently
be coerced to "Symbol" as you said, and we can use it to construct
a Polynomial, an Expression or whatever.

But worse, actually declaring the type of a variable to be Integer
(or Float etc.) prevents this coercion to symbol and so this variable
can no longer be used to form a Polynomial.
  

> Now it is often convenient, and especially important for 
> further research work we want to do, to be able to specify 
> that 'x' is an "indefinite integer". Thus there can be a
> signature 
>   +(Indefinite(Integer),Integer) -> Indefinite(Integer)
> so that
>   x + 1
>          Type: Indefinite Integer
>

So I wouldn't mind so much if I got the following result above

(7) -> x

   (7)  x
                                           Type: Indefinite Integer

-------

In fact it would make good sense for things to default to
something like Variable Any rather than Variable x and then
we could use the type Variable Integer instead of Indefinite.
I think there are already too many names for the same thing
in Axiom.

Now the first thing I would want is to be able to coerce
Variable Integer to Symbol. The second thing (maybe more
difficult?) is to be able to interpret it as Integer, at
least in the special case

  x:=1

Or in general it might be better if the variable retained it's
assigned domain (e.g. Integer) but if it has not (yet) been
assigned a value then it could still be coerced to a Variable
of that same type (e.g. Variable Integer).

> ... 
> Indeed, the idea of Indefinite(R) where R is a domain is
> the generalization. Thus, for your example, in Axiom the 
> appropriate type would be 
>   Matrix(Indefinite(Integer),Indefinite(Integer))
> 
> We can clearly construct such types in Axiom. What the 
> mathematically correct reasoning would be and what algorithms 
> apply is an interesting question that we need to explore.
>

It seems to me that it should be quite simple to provide
symbolic overloading for almost all operations but do we
really want

  x+1

to be of type Indefinite Integer as you suggest above?
Axiom already has several possible types for this.
 
> The key issue is that symbolic computation systems do very 
> little "symbolic" computation (hasty generalization to make 
> the point). We'd like to be able to do computation "along the 
> theorem line" (that is, reasoning with known theorems) rather 
> than basic algebra.
> 
> Comments?

Tim, I agree with your point especially as it applies to Axiom.
Perhaps the strict typing makes such symbolic computation more
difficult. Other systems such as Maple and Mathematica seem
to have more abilities when it comes to this kind of computation.
I am also reminded of systems like Reduce in which symbolic
tensor algebra (ITENSOR?), in the sense you mean above and in
a manner similar to that described in Richard Fateman's paper that
you quoted.

\start
Date: Thu, 24 Jun 2004 20:02:02 +0200
From: Magnus Larsson
To: list
Subject: Axiom cvs 040624 build error

Hello axiom-developer,

FYI,
Axiom CVS (24-June-2004) does not build on my i686-pc-linux-gnu system.
CVS June-5-2004 was ok.
I am using gcc-3.3.1 and gcl GCL (GNU Common Lisp)  2.7.0 ANSI   May 30 2004.

Staring a build using:

export CVS_RSH="ssh"
cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/axiom co axiom
magnus@lfs:~/usr/source/axiom/cvs-040624/axiom> ./configure 
--prefix=/home/magnus/test/axiom-040624
export AXIOM=/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make

results in:

...
making /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp 
from /home/magnus/usr/source/axiom/cvs-040 
624/axiom/src/interp/apply.boot.pamphlet

>
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LET.
Broken at APPLY.  Type :H for Help.
BOOT>>10 
making /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o 
from /home/magnus/usr/source/axiom /cvs-040624/axiom/int/interp/apply.clisp

>
The source 
file /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is 
not found.
9 
making /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o 
from /home/magnus/usr/source/axiom/cvs- 040624/axiom/obj/linux/interp/apply.o
cp: cannot stat 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o': No 
such file or directory
make[3]: *** 
[/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o] 
Error 1
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom'
make: *** [all] Error 2

There are several "The source file .../int/interp/<filename> is not found" 
before the final error reference to "... int/interp/apply.clisp is not found" 
shown in the text above.

I have been using Axiom for a while. 
My latest successful build, the one that I am currently using, was CVS 
5-June-2004. 
cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/axiom co -D "040605" 
axiom.

I tried to rebuild after reading the CVS update message 
http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00179.html.

I this only temporary or has something fundamental changed when it comes to 
the build prerequisites?

\start
Date: Thu, 24 Jun 2004 14:49:06 -0400
From: Tim Daly
To: Bill Page
Subject: Re: indefinites

Bill,

The distinction between Integer and Indefinite Integer is quite subtle.
Normally we think of a number, like 1, as an integer. In fact, if you
just type 1, Axiom is further restricts the type to the subtype
PositiveInteger:

(1) -> 1
 
    (1) 1
                                           Type: PositiveInteger

> When I started using Axiom I was very surprised by the
> following:
> 
> (1) -> x
> 
>    (1)  x
>                                            Type: Variable x

Non-numeric tokens become things of type Variable, as above.

> (2) -> x+1
> 
>    (2)  x + 1
>                                            Type: Polynomial Integer

The interpreter must make sense of this list of tokens
and find a compatible set of types where there is a '+' operator
with a signature matching the types. The interpreter eventually
"lifts" both to Variable(x) and PositiveInteger to POLY(INT) and
finds the signature +(POLY(INT),POLY(INT)) -> POLY(INT)

> (3) -> x:Symbol
>                                            Type: Void

Here you've just asked the interpreter to remember that the
token 'x' is of type Symbol. Notice that you now have a thing
with a Type Symbol which has a default value of its token name.
You could have said:

         x:Symbol := 'y

and now the value of the symbol 'x' would by 'y'. 

> (4) -> x
> 
>    (4)  x
>                                            Type: Symbol

Since you didn't assign the Symbol a value it defaults to its own name.

> (5) -> x+1
> 
>    (5)  x + 1
>                                            Type: Polynomial Integer

Here you've used the Symbol 'x' and the PositiveInteger 1 with the
'+' function. This gets promoted by the interpreter as before to 
POLY(INT) to find the signature +(POLY(INT),POLY(INT)) -> POLY(INT)

> (6) -> x:Integer
>                                            Type: Void

Here you've told the interpreter that 'x' is of type Integer.
Unlike Symbol, the Integer has no default value. Since you didn't
assign 'x' a value it has a value whose type is Void.

> (7) -> x
> 
>    x is declared as being in Integer but has not been given a value.

Here you've tried to take the value of 'x', which is Void. The
interpreter complains. If you want the value of 'x' you must
assign it a value as in:

         x:Integer:=1


> (7) -> x+1
> 
>    x is declared as being in Integer but has not been given a value.

Here, again, (as in lisp) you've used a token of type Integer and
another token of type PositiveInteger. Axiom finds the signature
+(INTEGER,INTEGER) -> INTEGER. It promotes PositiveInteger to Integer
and calls '+'. The '+' function tries to take the value of its first
argument, 'x', and gets Void. It's like the lisp (+ x 1) where 'x'
has no value.


> 
> (7) -> x::Symbol
> 
>   x is declared as being in Integer but has not been given a value.

Here you've asked for the value of 'x' to be converted to Symbol.
If 'x' had the value 'y' then this would work. But you've already
told Axiom that 'x' is an Integer so no matter what value you assign
to 'x' you can't get a Symbol because there is no way to coerce an
integer to a Symbol.


--------

> First, the type of x if no domain has be declared is "Variable x"
> not symbol. That seems very odd (even wrong?) In what sense is
> "Variable x" a domain? This seems like unnecessary confusion at
> a rather basic level. But whatever "Variable x" is, it can apparently
> be coerced to "Symbol" as you said, and we can use it to construct
> a Polynomial, an Expression or whatever.

Variable is a perfectly valid domain. We can ask Variable what operations
it supports and we get:

(3) -> )show Variable
 Variable sym: Symbol  is a domain constructor
 Abbreviation for Variable is VARIABLE 
 This constructor is not exposed in this frame.
 Issue )edit /boot/axiom/mnt/linux/../../src/algebra/VARIABLE.spad to see algebra source code for VARIABLE 

------------------------------- Operations --------------------------------
 ?=? : (%,%) -> Boolean                coerce : % -> Symbol
 coerce : % -> OutputForm              hash : % -> SingleInteger
 latex : % -> String                   variable : () -> Symbol
 ?~=? : (%,%) -> Boolean              

As you can see the Variable domain supports an operation 'coerce' which
when given a thing of Type Variable will return a thing of Type Symbol.


> But worse, actually declaring the type of a variable to be Integer
> (or Float etc.) prevents this coercion to symbol and so this variable
> can no longer be used to form a Polynomial.

If you do a 
  )show Integer
(the output is too long to include here) you'll find that Integer
does not have a 'coerce' function from Integer to Symbol. You told
the interpreter that 'x' is an Integer and thus you told the 
interpreter that only functions supported by Integer apply. Since
there is no function that will coerce an Integer to a Symbol what
you want doesn't exist. The interpreter is just doing what you told
it to do.
   

> So I wouldn't mind so much if I got the following result above
> 
> (7) -> x
> 
>    (7)  x
>                                            Type: Indefinite Integer

Ummm, the issue is MUCH more subtle than it appears. Indefinite(Integer),
indeed, Indefinite anything is a whole new type tower with completely
different meanings for all of the operations. The issues are subtle
enough to be considered material for a PhD thesis (or two) so I can't
really explain them in detail as I'm still pondering the questions.


> In fact it would make good sense for things to default to
> something like Variable Any rather than Variable x and then
> we could use the type Variable Integer instead of Indefinite.
> I think there are already too many names for the same thing
> in Axiom.
> 
> Now the first thing I would want is to be able to coerce
> Variable Integer to Symbol. The second thing (maybe more
> difficult?) is to be able to interpret it as Integer, at
> least in the special case
> 
>   x:=1
> 
> Or in general it might be better if the variable retained it's
> assigned domain (e.g. Integer) but if it has not (yet) been
> assigned a value then it could still be coerced to a Variable
> of that same type (e.g. Variable Integer).


ummm, no. for a variety, (indeed whole fiber bundles) of reasons. 

> > ... 
> > Indeed, the idea of Indefinite(R) where R is a domain is
> > the generalization. Thus, for your example, in Axiom the 
> > appropriate type would be 
> >   Matrix(Indefinite(Integer),Indefinite(Integer))
> > 
> > We can clearly construct such types in Axiom. What the 
> > mathematically correct reasoning would be and what algorithms 
> > apply is an interesting question that we need to explore.
> >
> 
> It seems to me that it should be quite simple to provide
> symbolic overloading for almost all operations but do we
> really want
> 
>   x+1
> 
> to be of type Indefinite Integer as you suggest above?
> Axiom already has several possible types for this.

Axiom has the machinery to handle this but no types that handle it.
That's the point of the research questions raised by Davenport, 
Fateman, Sit, and myself (and probably others I've yet to discover).

> > The key issue is that symbolic computation systems do very 
> > little "symbolic" computation (hasty generalization to make 
> > the point). We'd like to be able to do computation "along the 
> > theorem line" (that is, reasoning with known theorems) rather 
> > than basic algebra.
> > 
> > Comments?
> 
> Tim, I agree with your point especially as it applies to Axiom.
> Perhaps the strict typing makes such symbolic computation more
> difficult. Other systems such as Maple and Mathematica seem
> to have more abilities when it comes to this kind of computation.
> I am also reminded of systems like Reduce in which symbolic
> tensor algebra (ITENSOR?), in the sense you mean above and in
> a manner similar to that described in Richard Fateman's paper that
> you quoted.

You can't even raise the question or construct a proper answer in a
system that does not do strict typing. The research question itself
is about strict typing so it makes no sense to talk about the M*
systems as they can't construct types (at least in the meaning of
the question).

Hope this doesn't add to the confusion too much.

\start
Date: Thu, 24 Jun 2004 15:16:13 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

Magnus,

It appears that the AXIOM variable is not set properly.
It should be set as follows:

If the top level Makefile lives in 

/foo/bar/baz

then you set the AXIOM variable to be:

/foo/bar/baz/mnt/linux
            ^^^^^^^^^^

I could not figure out from your message exactly where the
top level Makefile resides. Axiom uses the AXIOM variable for
two things. First it parses out where it is installed 
(/foo/bar/baz) and second, which kind of system to build ('linux').

I test every build before I check it in so, unless the checkin
failed it should build.

You've likely confused the Axiom build system. I'd recommend
destroying the directory and re-fetching the sources. 
Alternatively, you need to do the following steps

1) keep the AXIOM variable set to its current setting
2) make clean
  
  This will cleanup the broken directories and restore the 
  original systems. 

3) set the AXIOM variable to the new value above
4) make

  This will build the system with the correct paths.

Let me know if you succeed or fail.
If you run the build in an emacs shell buffer you can send me
the complete console output.

\start
Date: Thu, 24 Jun 2004 22:37:11 +0200
From: Magnus Larsson
To: Tim Daly
Subject: Re: Axiom cvs 040624 build error

Hello Tim Daly,

I am sorry about that. That was a typo.
I meant:
the Makefile resides in:
/home/magnus/usr/source/axiom/cvs-040624/axiom
echo $AXIOM gives
/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux

I got your other email as well. Thank you.

I did rebuild from scratch using cvs sources in /tmp/axiom
pwd => /tmp/axiom
ls  => CHANGELOG  CVS  Makefile  Makefile.linux  Makefile.pamphlet  README     
     configure  int  license  lsp  mnt  noweb  obj  src  zips
echo $AXIOM => /tmp/axiom/mnt/linux
make

same error
....
The source file /tmp/axiom/int/interp/apply.clisp is not found.
9 making /tmp/axiom/mnt/linux/autoload/apply.o 
from /tmp/axiom/obj/linux/interp/apply.o
cp: cannot stat `/tmp/axiom/obj/linux/interp/apply.o': No such file or 
directory
make[3]: *** [/tmp/axiom/mnt/linux/autoload/apply.o] Error 1
make[3]: Leaving directory `/tmp/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/tmp/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/tmp/axiom'

On Thursday 24 June 2004 22.49, root wrote:
> You wrote:
> > The Makefile resides in:
> > /usr/source/axiom/cvs-040624/axiom
> >
> > echo $AXIOM gives
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux
>
> these two don't match. try
>
> export AXIOM=/usr/source/axiom/cvs-040624/axiom

\start
Date: Thu, 24 Jun 2004 17:59:57 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

ok. i'll do a cvs download and try it. 
it's possible that something is broken.

\start
Date: Thu, 24 Jun 2004 19:07:06 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

It works for me. I downloaded it from the cvs.
Any other clues?

==============================================================


>10 making /tmp/test/axiom/obj/linux/interp/apply.o from /tmp/test/axiom/int/interp/apply.clisp

>
Compiling /tmp/test/axiom/int/interp/apply.clisp.
; (DEFUN |compApplication| ...) is being compiled.
;; The variable |$op| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |compApplyModemap| ...) is being compiled.
;; The variable |$bindings| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |compMapCondFun| ...) is being compiled.
;; Warning: The variable |op| is not used.
;; Warning: The variable |dc| is not used.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /tmp/test/axiom/obj/linux/interp/apply.o.
9 making /tmp/test/axiom/mnt/linux/autoload/apply.o from /tmp/test/axiom/obj/linux/interp/apply.o
219 making /tmp/test/axiom/int/interp/c-doc.clisp from /tmp/test/axiom/src/interp/c-doc.boot.pamphlet

\start
Date: Fri, 25 Jun 2004 14:59:05 +0200
From: Magnus Larsson
To: Tim Daly
Subject: Re: Axiom cvs 040624 build error

Hello Tim

GNU Binutils dependency? I am using a fairly recent GNU Binutils.

I tried another system:
This worked:
Axiom CVS 040625 did build on a i686-pc-linux-gnu, gcc-3.3.1, gcl-2.5.3, 
binutils-2.14, linuxthreads system, or so it seems anyway, since the build 
got past the previous problem spot. I terminated the build by command, 
though, before final completion.

This does not work:
I can still not build Axiom CVS 040624 on my original system using gcc-3.3.1, 
gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I might have trashed 
something on this system, but I am not aware of any seroius malconfiguration.
(CVS 5-june-2004 does build on this system)
The Binutils version is the only difference I can pinpoint right now.

best regards,

Magnus Larsson

On Friday 25 June 2004 01.07, root wrote:
> It works for me. I downloaded it from the cvs.
> Any other clues?
>
> ==============================================================
>
> >10 making /tmp/test/axiom/obj/linux/interp/apply.o from
> > /tmp/test/axiom/int/interp/apply.clisp
>
> Compiling /tmp/test/axiom/int/interp/apply.clisp.
> ; (DEFUN |compApplication| ...) is being compiled.
> ;; The variable |$op| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |compApplyModemap| ...) is being compiled.
> ;; The variable |$bindings| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |compMapCondFun| ...) is being compiled.
> ;; Warning: The variable |op| is not used.
> ;; Warning: The variable |dc| is not used.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /tmp/test/axiom/obj/linux/interp/apply.o.
> 9 making /tmp/test/axiom/mnt/linux/autoload/apply.o from
> /tmp/test/axiom/obj/linux/interp/apply.o 219 making
> /tmp/test/axiom/int/interp/c-doc.clisp from
> /tmp/test/axiom/src/interp/c-doc.boot.pamphlet

\start
Date: Sat, 26 Jun 2004 13:40:05 +0200
From: David Mentre
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

Magnus Larsson writes:

> This does not work:
> I can still not build Axiom CVS 040624 on my original system using gcc-3.3.1, 
> gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I might have trashed 
> something on this system, but I am not aware of any seroius malconfiguration.
> (CVS 5-june-2004 does build on this system)
> The Binutils version is the only difference I can pinpoint right now.

This might pinpoint an issue with GCL. Axiom is using its own version of
GCL (2.6.2-something) but there might be an issue with this release of
GCL and the releases of binutils and other utilities on your system.

\start
Date: 26 Jun 2004 09:22:59 -0400
From: Camm Maguire
To: list
Subject: GCL 2.6.2 is released

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Greetings!  You can find the release notes here:

http://www.gnu.org/software/gcl/RELEASE-2.6.2.html

Over the next few days, we will be uploading binaries requested by
various users for convenience to ftp.gnu.org.  Shortly thereafter,
goals and priorities for 2.7.0 will be discussed and planned.  Closing
the remaining ansi compliance issues will be foremost on the list in
any case. Feedback to gcl-devel@gnu.org of course most appreciated.

\start
Date: Sat, 26 Jun 2004 17:41:10 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom-developer post from Magnus Larsson requires approval

Magnus,

Thanks for trying. It does appear that something broke due to binutils.
I'll have to look at binutils. The problem appears to have something to
do with gcl and binutils because the code being compiled (apply.clisp)
is just standard common lisp. There are no axiom dependencies in the file.
It's very puzzling.

Please look at the file int/interp/apply.clisp from the broken system if
you still have it. It should compare, byte for byte, with the one
generated by the working system. And you should be able to fire up 
a copy of axiom in the int/interp directory, type
  )lisp (compile-file "apply.clisp")
and get the apply.o file. 

The only possible connection with binutils is that perhaps binutils
contains the loader. GCL cares about the loader and perhaps something
has changed (or is broken) in the latest binutils.

\start
Date: Sat, 26 Jun 2004 17:06:10 -0400
From: Bill Page
To: Tim Daly
Subject: RE: indefinites

Tim,

On Thursday, June 24, 2004 2:49 PM you wrote:
> 
> The distinction between Integer and Indefinite Integer is 
> quite subtle.

I really don't see it as much more subtle than high school
level algebra. For example, it is not difficult to imagine
assigning a problem such as: Let x be a positive
integer, show that 0^x = 0.

> > (6) -> x:Integer
> >                                            Type: Void
> 
> Here you've told the interpreter that 'x' is of type Integer. 
> Unlike Symbol, the Integer has no default value. Since you 
> didn't assign 'x' a value it has a value whose type is Void.
> 

Yes, of course. This is the axiom-developer forum not the
user forum. Your explanation isn't really necessary. What
Axiom is doing is clear. Why Axiom is designed to do what it
does is not so clear. Specifically, since x still has no
assigned value, it is not clear to me why Axiom does not at
least coerce it to Variable x which does have a value.

In the Axiom book p. 24 the expression x:Integer is called
a "declaration" and says only that it restricts the values
that can be assigned to the variable, certain not that it
is no longer a variable simply because we have declared a
type! That's why I found Axiom's behaviour very surprising.

The glossary of the Axiom book, p. 715 defines 'variable'
as follows: "a means of referring to an object, but not an
object itself...". Therefore it also seemed quite surprising
and inconsistent to me that when no declaration has been
made for x, I saw the Axiom output

   x
                  Type: Variable x

which treats x as an *object* of type Variable. In fact we
can do some rather weird things with the fact that Variable
is a domain. For example, suppose we declare

   x:Variable y

Then

   x

gives the result

   x is declared as being in Variable y but has not been
   given a value.

We can write

  x:='y

but not

  x:='z

to which Axiom replies that it cannot convert the symbol z to
type Variable y.

All this seems a little strange and redundant since we can do
the same thing with symbols, but I guess it is mostly harmless.

> 
> > ... declaring the type of a variable to be Integer (or
> > Float etc.) prevents this coercion to symbol and so this
> > variable can no longer be used to form a Polynomial.
> 
> If you do a 
>   )show Integer
> (the output is too long to include here) you'll find that 
> Integer does not have a 'coerce' function from Integer to 
> Symbol. You told the interpreter that 'x' is an Integer and 
> thus you told the interpreter that only functions supported
> by Integer apply. Since there is no function that will coerce
> an Integer to a Symbol what you want doesn't exist. The
> interpreter is just doing what you told it to do.

Of course the interpret is just doing what I told it to do.
The point is that I think there *should be* a function that
will coerce an Integer to a Symbol (well actually Variable,
I suppose) when it has not been assigned a value.

> 
> > So I wouldn't mind so much if I got the following result
> > above
> > 
> > (7) -> x
> > 
> >    (7)  x
> >                                    Type: Indefinite Integer
> 
> Ummm, the issue is MUCH more subtle than it appears. 
> Indefinite(Integer), indeed, Indefinite anything is a whole 
> new type tower with completely different meanings for all of 
> the operations. The issues are subtle enough to be considered 
> material for a PhD thesis (or two) so I can't really explain 
> them in detail as I'm still pondering the questions.
>

I think you are looking at this from the wrong perspective,
focusing too much on the way Axiom does things now and not
enough on basic design and the ways in which Axiom represents
a compromise. I don't see why you claim "Indefinite anything is
a whole new type tower with completely different meanings for
all of the operations." After all the theory of types and the
use of variables (even typed variables) is a relatively old
subject in mathematics. But I can't really comment on what
counts as material for PhD thesis these days ... :)
 
> > 
> > It seems to me that it should be quite simple to provide
> > symbolic overloading for almost all operations but do we
> > really want
> > 
> >   x+1
> > 
> > to be of type Indefinite Integer as you suggest above?
> > Axiom already has several possible types for this.
> 
> Axiom has the machinery to handle this but no types that 
> handle it. That's the point of the research questions raised 
> by Davenport, Fateman, Sit, and myself (and probably others
> I've yet to discover).

To tentatively answer my own question above, I think that we
do not want the expression

  x+1

to be of type Indefinite Integer. If x was coercible to type
Variable then it would simply be of type Polynomial Integer as
before. But if the domains such as Polynomial and Expression
could know that x was declared as say PostiveInteger then it
could do things like evaluate

  0^x

as

        1
                              Type: PositiveInteger

even though x has no assigned value.

To do this, I think we need to extend the Variable domain to
allow, for example, the following domain constructor

  Variable(PositiveInteger,x)

Then the declaration

   x:PositiveInteger

should default to

      x
                     Type: Variable(PositiveInteger,x)

and most of the rest of Axiom would be unaffected except for
some additional evaluations in those domains involving variables
that can make use of the additional type information.

> 
> > > The key issue is that symbolic computation systems do very
> > > little "symbolic" computation (hasty generalization to make 
> > > the point). We'd like to be able to do computation "along the 
> > > theorem line" (that is, reasoning with known theorems) rather 
> > > than basic algebra.
> > > 
> > > Comments?
> > 
> > Tim, I agree with your point especially as it applies to Axiom. 
> > Perhaps the strict typing makes such symbolic computation more 
> > difficult. Other systems such as Maple and Mathematica seem to have 
> > more abilities when it comes to this kind of computation. I am also 
> > reminded of systems like Reduce in which symbolic tensor algebra 
> > (ITENSOR?), in the sense you mean above and in a manner similar to 
> > that described in Richard Fateman's paper that you quoted.
> 
> You can't even raise the question or construct a proper 
> answer in a system that does not do strict typing. The 
> research question itself is about strict typing so it makes 
> no sense to talk about the M* systems as they can't construct 
> types (at least in the meaning of the question).

I don't agree. Your claim was that

> ... symbolic computation systems do very little "symbolic"
> computation ...

I don't think that this has anything directly to do with strict
typing. It seems to me that the way that Axiom implements strict
typing (specifically: no typed variables) makes this sort of
"symbolic" computation more difficult. And my counter claim is
that other systems have more functionality in this regard than
Axiom, but I agree that they do this through means other than
strict typing. For example, Maple has the "assume" facility,
e.g.

  assume(x,posint);

that interacts with many other different symbolic operations.

And I want to repeat for emphasis that even without any form
of typing, systems like Reduce have been used to implement
purely symbolic operations on tensors and differential forms
that, for some applications, are much more powerful than
manipulating the underlying (coordinate) representations of
these objects.

> 
> Hope this doesn't add to the confusion too much.
> 

There is confusion???  :)

Seriously, I think this dialogue continues to be quite
worthwhile.

\start
Date: Sat, 26 Jun 2004 19:02:06 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom-developer post from Magnus Larsson requires approval

Magnus,

Another possibility has occured to me. The Axiom build creates a
GCL lisp image (with some Axiom code added) and saved as an 
executable named "Lisp", then it compiles the boot compiler, loads
it and saves it as an executable called "bootsys". Next it compiles
apply.clisp. It seems odd that so much compiling/linking happens
without error until the bootsys image is run. It appears that
bootsys must not have been saved properly. That means that the
save-system function is failing. You could try this:

start obj/linux/bin/lisp
compile a simple foo.lisp file
load it.
(system::save-system "newlisp")
start newlisp
compile foo.lisp

If this fails it means that save-system is broken.

\start
Date: Sat, 26 Jun 2004 22:22:22 -0400
From: Bill Page
To: Tim Daly
Subject: RE: indefinites

I wrote:

> ...
> If [x:Integer with no assigned value] was coercible to type
> Variable then it would simply be of type Polynomial Integer as
> before. But if the domains such as Polynomial and Expression
> could know that x was declared as say PostiveInteger then it
> could do things like evaluate
> 
>   0^x
> 
> as
> 
>         1
>                               Type: PositiveInteger
> 
> even though x has no assigned value.
> ...

Ah, of course what I should have written was:

> could do things like evaluate
>
>  0^x
>
> as
>
>        0
>                                Type: Expression Integer
>
> even though x has no assigned value. 
> 
> To do this, I think we need to extend the Variable domain to
> allow, for example, the following domain constructor
> 
>   Variable(PositiveInteger,x)
> 
> Then the declaration
> 
>    x:PositiveInteger
> 
> should default to
> 
>       x
>                      Type: Variable(PositiveInteger,x)
> ...

\start
Date: Sat, 26 Jun 2004 23:56:16 -0400
From: William Sit
To: Bill Page
Subject: Re: indefinites

Bill Page wrote:
> 
> Tim,
> 
> On Thursday, June 24, 2004 2:49 PM you wrote:
> >
> > The distinction between Integer and Indefinite Integer is
> > quite subtle.
> 
> I really don't see it as much more subtle than high school
> level algebra. For example, it is not difficult to imagine
> assigning a problem such as: Let x be a positive
> integer, show that 0^x = 0.

Whether the distinction is subtle or not is subjective. However, there should be
no disagreement that the two mathematically are equivalent (that is, both obey
the same rules operating on integers) but computationally different.

Bill continues:

> In the Axiom book p. 24 the expression x:Integer is called
> a "declaration" and says only that it restricts the values
> that can be assigned to the variable, certain not that it
> is no longer a variable simply because we have declared a
> type! That's why I found Axiom's behaviour very surprising.
> 
> The glossary of the Axiom book, p. 715 defines 'variable'
> as follows: "a means of referring to an object, but not an
> object itself...". Therefore it also seemed quite surprising
> and inconsistent to me that when no declaration has been
> made for x, I saw the Axiom output
>    x
>                   Type: Variable x
> 
> which treats x as an *object* of type Variable.

The double meaning of "variable" is unfortunate. The above paragraph should have
used the term "identifier" instead of "variable". "Variable" should be reserved
for the domain constructor, and symbols used in polynomials should be referred
to as (algebraic) indeterminates.

An "indefinite", the way Tim and I use it, is not the same as an indeterminate.
It is a what Davenport called an "unknown" and is simply a place holder for a
(perhaps never) to-be-assigned value of a certain type (say integer). An
indefinite, ideally, may be used wherever an integer may be used in Axiom. The
problem of how to implement something like
  Do (body of loop) for i in 1..n
where n is an indefinite integer is not straightforward. Fateman's article
discusses possible implementation strategies.

Bill continues:

> > > It seems to me that it should be quite simple to provide
> > > symbolic overloading for almost all operations but do we
> > > really want
> > >
> > >   x+1
> > >
> > > to be of type Indefinite Integer as you suggest above?
> > > Axiom already has several possible types for this.
> [Tim's response]
> > Axiom has the machinery to handle this but no types that
> > handle it. That's the point of the research questions raised
> > by Davenport, Fateman, Sit, and myself (and probably others
> > I've yet to discover).
> 
> To tentatively answer my own question above, I think that we
> do not want the expression
> 
>   x+1
> 
> to be of type Indefinite Integer. If x was coercible to type
> Variable then it would simply be of type Polynomial Integer as
> before. But if the domains such as Polynomial and Expression
> could know that x was declared as say PostiveInteger then it
> could do things like evaluate
> 
>   0^x
> 
> as
> 
>         0 [corrected typo]
>                               Type: PositiveInteger
> 
> even though x has no assigned value.

EXPR INT is one way to handle the indefinites but as your example shows, it is
not thorough. Sure we can easily modify EXPR to handle this example. Note this
works only when x has not been declared to be of type Integer, so the
interpreter can treat x as a Symbol and coerced it first to POLY INT then to
EXPR INT.
An example of where this has been done is
   binomial(x,x)
Axiom will give 1 when x is undeclared and unassigned. This works because the
CombinatorialFunctions was designed to work within EXPR INT, AND the coercion of
x to EXPR INT succeeds.

> To do this, I think we need to extend the Variable domain to
> allow, for example, the following domain constructor
> 
>   Variable(PositiveInteger,x)
> 
> Then the declaration
> 
>    x:PositiveInteger
> 
> should default to
> 
>       x
>                      Type: Variable(PositiveInteger,x)
> 
> and most of the rest of Axiom would be unaffected except for
> some additional evaluations in those domains involving variables
> that can make use of the additional type information.

The Type ANY is very similar to what you suggested above. However, as currently
implemented, the interpreter flags any object which has not been assigned a
value in any function call as an error. So I don't know if we can define a
function that would not be flagged to produce Variable(PositiveInteger,x) if x
has no value but has been declared to be of some type.

Precisely because of this "restriction" or "feature" (which is reasonable given
the current paradym of symbolic computation), to allow such a coercion requires
a new implementation (namely, to create a value when there is none --- and the
natural choice is similar to how an undefined (AND undeclared) symbol x is
handled as Variable x --- the difference being that in the case of an
indefinite, x IS declared.

Declaration is of paramount importance in the world of indefinites. For example,
we may want to be able to compute the way we do in mathematics: Let  p be a
polynomial of degree m > 0. Then dp/dx is a polynomial of degree m-1. Here we
want p to be an indefinite polynomial in one variable x and m be an indefinite
positive integer. So we would like to be able to do:

  p: Indefinite DMP([x],INT)
                              Type: Indefinite DMP([x],INT)
  m:= degree p
                              Type: Indefinite NNI
  degree D(p,x)
    m-1                       Type: Indefinite NNI

(there may need be provisos on m, but let's ignore that for now). Eventually,
when this is operational, neither the input nor the output need to use the word
"Indefinite" (which is needed only internally: so every declaration without an
accompanying assignment will belong to the indefinite domain; an object of the
indefinite domain can be "assigned" a value and be "retracted" to the domain,
all transparently done. This may suggest a simple method is to put a tag on the
object, whether it has been assigned a domain value or not. This would probably
work for a while until we want to go to more abstract levels such as computing
with indefinites like p+q. The code for the underlying domain will be so messed
up with conditionals that it may be wiser to separate the domain from its
indefinite version. After all, we separate the domain INT from POLY INT. Fateman
has some good suggestions to use lazy evaluation techniques to hold the
proliferation of conditionals and handle indefinite loops.

However this is done, the representation of the indefinite integer x will be
different from the representation of an integer x that has not been assigned a
value (indeed, the latter does not yet have one). This necessary change in
representation causes all the operations involving integers to be syntactically
invalid on indefinite integers.

Bill continues:

> [Tim wrote:]
> > ... symbolic computation systems do very little "symbolic"
> > computation ...
> 
> I don't think that this has anything directly to do with strict
> typing. It seems to me that the way that Axiom implements strict
> typing (specifically: no typed variables) makes this sort of
> "symbolic" computation more difficult. And my counter claim is
> that other systems have more functionality in this regard than
> Axiom, but I agree that they do this through means other than
> strict typing. For example, Maple has the "assume" facility,
> e.g.
> 
>   assume(x,posint);
> 
> that interacts with many other different symbolic operations.
> 
> And I want to repeat for emphasis that even without any form
> of typing, systems like Reduce have been used to implement
> purely symbolic operations on tensors and differential forms
> that, for some applications, are much more powerful than
> manipulating the underlying (coordinate) representations of
> these objects.

Can you give some such examples? (for discussion's sake).

\start
Date: Sun, 27 Jun 2004 10:02:00 +0200
From: Magnus Larsson
To: Tim Daly
Subject: Re: Axiom-developer post from Magnus Larsson requires approvalHello 

Hello Tim,

I am not a Lisp user. I only use Lisp to bootstrap me to Axiom or Maxima.
I would like to execute the test, but I need exact Lisp step-by-step 
instructions. foo.lisp contains (+ 2 3).

This is what I did, please advice:

obj/linux/bin/lisp
(compile-file "foo.lisp")
	Compiling foo.lisp.
	End of Pass 1.
	End of Pass 2.
	OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
	Finished compiling foo.lisp.
	#p"foo.o"
(load "foo.lisp")
	Loading foo.lisp
	Finished loading foo.lisp
	T
(system::save-system "newlisp")

./newlisp
#### Newlist starts and gives me the input prompt >
#### How do I compile the loaded foo.lisp 
(compile-file "foo.lisp")??? Compile-file foo-lisp works fine , but I do not 
think this is what you meant. How to compile the loaded foo.lisp?

Magnus

On Sunday 27 June 2004 01.02, root wrote:
> Magnus,
>
>
> Another possibility has occured to me. The Axiom build creates a
> GCL lisp image (with some Axiom code added) and saved as an
> executable named "Lisp", then it compiles the boot compiler, loads
> it and saves it as an executable called "bootsys". Next it compiles
> apply.clisp. It seems odd that so much compiling/linking happens
> without error until the bootsys image is run. It appears that
> bootsys must not have been saved properly. That means that the
> save-system function is failing. You could try this:
>
> start obj/linux/bin/lisp
> compile a simple foo.lisp file
> load it.
> (system::save-system "newlisp")
> start newlisp
> compile foo.lisp
>
> If this fails it means that save-system is broken.

\start
Date: Sun, 27 Jun 2004 11:32:53 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom-developer post from Magnus Larsson requires approvalHello

Magnus,

You have the correct idea. There is just one more step...

obj/linux/bin/lisp                   (start the lisp image)
(compile-file "foo.lisp")            (compile a lisp file)
(load "foo")                         (load the compiled file (note: no .lisp))
(system::save-system "newlisp")      (save a new image)
newlisp                              (start the newimage lisp)
(compile-file "foo.lisp")            (compile in the new image)
(load "foo")                         (load the result)


It is conjectured that the second compile-file will fail because
the save-system did not build a correct image. That's what I'm
trying to test.

\start
Date: Sun, 27 Jun 2004 11:34:01 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: Axiom-developer post from Magnus Larsson requires approvalHello

Magnus,

in foo.lisp put the code:

(defun foo (x) x)

\start
Date: Sun, 27 Jun 2004 12:11:36 -0400
From: Tim Daly
To: list
Subject: changes

A newer set of changes has been checked in.

There is a change to the src/doc/book.pamphlet due to discussions and
work by C Y Student, David Mentre, and Bertfried Fauser. The book now
renders graphics and is suitable for bulding under pdflatex. More
graphics needs to be added but this has not yet happened.

The various 'echo' messages at the start of each stanza have been
cleaned up. These are unimportant except as a debugging tool. The
echo messages for each directory contain a unique number (that may
be changed across updates but will be unique). The unique number 
allows you to find the exact failing stanza along with a trivial
statement of what the stanza is trying to achieve.

The major change is that src/graph now exists. The graphics portion
of the system now exists. It is not yet connected to the axiom
interpreter and is still undergoing changes. Most of the files
are now in pamphlet format. I've documented the file formats 
for the 2D case in src/graph/fileformats.pamphlet
(see mnt/linux/doc/src/graph/fileformats.dvi). You can test this
version in a newly built system by typing:

export PATH=$AXIOM/bin:$PATH
cd int/graph
viewAlone parabola

You should see a graph of a parabola. If you click on the graph you
will get the menu. To quit, click twice on the quit button in the
bottom right corner of the menu. The viewAlone program has been
modified to output detailed information from the graph files.

The 3D case should also work but I have to reverse engineer the
process and document it, develop a test case, etc.

Calls from the Axiom interpreter do not yet work because I need
to set up sman (superman) which is the overall process that gets
invoked in the axiom script. I'm working on that.

If you happen to download and build the system, please try it
and give me feedback.

Work continues.

\start
Date: Sun, 27 Jun 2004 17:38:44 +0200
From: David Mentre
To: Magnus Larsson
Subject: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Magnus Larsson writes:

> Ooops, I did not know, for sure, that Axiom relied on its own GCL 2.6.
> Will it not be hard to maintain a separate GCL version for Axiom alone? Why 
> not rely on the build platfrom to supply GCL? Well, I am sure this has been 
> discussed already and I do not mind the current strategy.

This was discussed before. In short:

 - Tim prefers to have a big sources with all included dependencies in
   order to control the built system;

 - it is possible to build Axiom with an external GCL. In fact, Camm
   Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
   and other software, is doing exactly that for the axiom debian
   package. I don't know however if the machinery has been included in
   current sources of Axiom.

\start
Date: Sun, 27 Jun 2004 17:55:22 +0200
From: David Mentre
To: Tim Daly
Subject: Re: changes

Hello Tim,

Tim Daly writes:

> (see mnt/linux/doc/src/graph/fileformats.dvi). You can test this
> version in a newly built system by typing:
>
> export PATH=$AXIOM/bin:$PATH
> cd int/graph
> viewAlone parabola

I've updated my CVS tree, the graph sources is there but it does not
seems to be built.

In the int/graph/viewAlone/ directory I have sources and no binaries. A
typo in a Makefile?

\start
Date: Sun, 27 Jun 2004 16:55:14 +0100
From: Mark Murray
To: David Mentre
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error) 

David Mentre writes:
>  - it is possible to build Axiom with an external GCL. In fact, Camm
>    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
>    and other software, is doing exactly that for the axiom debian
>    package. I don't know however if the machinery has been included in
>    current sources of Axiom.

And I'm doing the same thing for FreeBSD.

I believe that my patches may be generic enought to incorporate into
Axiom. Any chances of getting them in? Who should I send them to?

\start
Date: Sun, 27 Jun 2004 18:12:59 +0200
From: David Mentre
To: Mark Murray
Subject: Re: Axiom & internal/external GCL

Hi Mark,

Mark Murray writes:

> I believe that my patches may be generic enought to incorporate into
> Axiom. Any chances of getting them in?

Very good chance.

> Who should I send them to?

To Tim Daly <axiom@tenkan.org> with a copy on this mailing list (we're
supposed to be Axiom developers ;)

\start
Date: Sun, 27 Jun 2004 13:00:07 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

>  - Tim prefers to have a big sources with all included dependencies in
>    order to control the built system;

that's correct. Axiom is a very complex beast (probably over a million
lines in the fully developed system). It is very version dependent for
many subsystems, including GCL. In order to keep the quality of the
system at a high level the system is built and tested with particular
versions of GCL. In fact, a great deal of effort goes into making sure
that it works with the latest version. Axiom periodically takes 
snapshots of the GCL CVS in order to get the latest version. The
snapshots are then modified during the build. 

It is possible, if you have locally modified GCL, to replace the
GCL snapshot version (it is in src/zips) with your local version
but I can't guarantee that Axiom will work. I've tried to fully
document every change for every version of GCL with a complete
explanation so you can understand the what and why. The documentation
is in the various Makefile.pamphlet files (see the Makefile.dvi).

> 
>  - it is possible to build Axiom with an external GCL. In fact, Camm
>    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
>    and other software, is doing exactly that for the axiom debian
>    package. I don't know however if the machinery has been included in
>    current sources of Axiom.

that's not strictly correct. Axiom will not fully run on an external GCL.
depending on what you are doing it will fail. in particular, axiom adds
special socket handling code to GCL which will be used by the newly added
graph capabilities. further, axiom has special build-time flags (documented
in the top level Makefile) that need to be set to your particular version
of GCL. If you are not using the same version that is included with the
Axiom CVS you need to change these flags and rebuild your local version.

in addition to sockets Axiom is adding code to do machine-level numeric
support. i have a local version (not yet documented, tested, and checked in)
which contains support for BLAS (Basic Linear Algebra Subroutines). These
are built into the GCL image at system build time. Axiom's numerics will
depend on these routines as well as additional routines that are in the
queue to add. There has been some discussion about pushing the numerics
support into GCL as Camm is also the BLAS maintainer. Since Axiom is
currently the only user it is not clear that GCL wants or needs them.

A third package is also in my local version that is going to be added
which requires GCL changes. I've been working with ltk. This is a 
lisp TK toolkit that runs on almost every lisp (except, it seems, GCL).
The current GCL/TK package is broken as far as I can tell. I can get it
to work but it promptly crashes. We're working on a new Axiom GUI to
replace the lost techexplorer and it is being developed using TCL/TK.
Since the current GCL/TK doesn't work and ltk is almost all native
common lisp we're going to use it going forward. Hopefully once it
runs I can convince Camm to support it also but, again, since Axiom is
the only user it is not clear that it is worth adding it to GCL.

so it is unlikely, going forward, that Axiom will run on your installed
version of GCL.

\start
Date: Sun, 27 Jun 2004 13:03:59 -0400
From: Tim Daly
To: David Mentre
Subject: Re: changes

d,

The int directory should only contain sources and not binaries.
int is defined to be system-independent, machine-generated code.
thus, the c sources are system-independent but generated by axiom notangle.

obj/linux/graph should contain binaries.
obj is defined to be system-dependent, machine-generated code.

mnt/linunx/bin/viewAlone should exist.

you might try:

make clean
make 

but i think it should work from an update (since the Makefile.pamphlet
files in the subdirectories should be newer than the Makefiles and will
cause the Makefiles to be regenerated).

Let me know if you finally succeed or fail.

\start
Date: Sun, 27 Jun 2004 13:06:03 -0400
From: Tim Daly
To: Mark Murray
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Mark,

If you have patches to anything that are required to run Axiom I'd
be happy to incorporate them into Axiom's build. Please run

diff -Naur original-file changed-file >changed-file.patch

and send me the patch files.

\start
Date: Sun, 27 Jun 2004 20:36:25 +0200
From: David Mentre
To: Tim Daly
Subject: Re: changes

Tim Daly writes:

> The int directory should only contain sources and not binaries.
> int is defined to be system-independent, machine-generated code.
>
> thus, the c sources are system-independent but generated by axiom notangle.
> obj/linux/graph should contain binaries.
> obj is defined to be system-dependent, machine-generated code.

I knew that...

> mnt/linunx/bin/viewAlone should exist.

... but at that time viewAlone was probably missing.

> you might try:
>
> make clean
> make 

I've done that (in fact by mistake, forgot that the PART= thing was not
functional) and now viewAlone exists.

And it works!! :)

Great.

Nice resurrection Tim, one more less.

\start
Date: Sun, 27 Jun 2004 20:36:40 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error) 

root writes:
> Mark,

Hi!

> If you have patches to anything that are required to run Axiom I'd
> be happy to incorporate them into Axiom's build. Please run
> 
> diff -Naur original-file changed-file >changed-file.patch

I'm using CVS, so enclosed is the output from

# cvs -q diff -ud

Which should be the same thing. For FreeBSD, I use the noweb _port_,
so some of my diffs are to kill the building of noweb as part of axiom.
These could be done differently, as they are a bit hackish. Also, I
make sure that zips/ is empty, to make sure I get all the build tools
from the environment. I've added no files locally, only modified some.

I'm sort-of expecting that some of the patches will be treated as
local (to me) preferences to be carried as local diffs.

> and send me the patch files.

Enclosed!

M
--
Mark Murray
iumop ap!sdn w,I idlaH

------- =_aaaaaaaaaa0

Index: Makefile
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile,v
retrieving revision 1.9
diff -u -d -r1.9 Makefile
--- Makefile	19 Jun 2004 22:21:25 -0000	1.9
+++ Makefile	27 Jun 2004 19:24:08 -0000
@@ -6,7 +6,8 @@
 #GCLVERSION=gcl-2.5
 #GCLVERSION=gcl-2.5.2
 #GCLVERSION=gcl-2.6.1
-GCLVERSION=gcl-2.6.2
+#GCLVERSION=gcl-2.6.2
+GCLVERSION=gcl-system
 AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
@@ -20,7 +21,7 @@
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
 COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -68,6 +69,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "FreeBSD" "FreeBSD"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -79,6 +81,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -95,7 +98,13 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
 	@echo 79 Axiom installation finished.
Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile.pamphlet,v
retrieving revision 1.22
diff -u -d -r1.22 Makefile.pamphlet
--- Makefile.pamphlet	27 Jun 2004 15:00:46 -0000	1.22
+++ Makefile.pamphlet	27 Jun 2004 19:24:12 -0000
@@ -186,7 +186,7 @@
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
 COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -268,6 +268,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "FreeBSD" "FreeBSD"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -279,6 +280,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -402,7 +404,13 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
 	@echo 79 Axiom installation finished.
@@ -410,7 +418,7 @@
 	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
 	@echo Start Axiom with the command $(shell basename ${COMMAND})
 	@echo 
-
+	
 	
 @
 \subsection{document}
@@ -546,6 +554,11 @@
 optimizations for function calling in Axiom. This is handled automatically
 by changing this variable.
 
+If GCLVERSION is ``gcl-system'', then no GCL is not built locally,
+and it is assumed that the ``gcl'' command is available off the
+path. If this GCL is unsuitable for building Axiom, then very bad
+things will happen.
+
 NOTE WELL: IF YOU CHANGE THIS YOU SHOULD ERASE THE lsp/Makefile FILE.
 This will cause the build to remake the lsp/Makefile from the
 lsp/Makefile.pamphlet file and get the correct version. If you
@@ -555,7 +568,8 @@
 #GCLVERSION=gcl-2.5
 #GCLVERSION=gcl-2.5.2
 #GCLVERSION=gcl-2.6.1
-GCLVERSION=gcl-2.6.2
+#GCLVERSION=gcl-2.6.2
+GCLVERSION=gcl-system
 @
 
 \subsection{Makefile.axposf1v3}
@@ -851,6 +865,51 @@
 <<clean>>
 
 @
+\subsection{Makefile.freebsd}
+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.
+<<Makefile.freebsd>>=
+# System dependent Makefile for the freebsd platform
+# Platform variable
+PLF:=FREEBSDplatform
+# C compiler flags
+CCF:="-O -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11R6/include -I/usr/local/include"
+# Loader flags
+LDF:="-L/usr/X11R6/lib -L/usr/local/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} TANGLE=${TANGLE}
+
+all: rootdirs srcsetup lspdir srcdir
+	@echo 45 Makefile.freebsd called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
 \subsection{Makefile.linux}
 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
@@ -1332,7 +1391,5 @@
 Bath BA2 5QR UK Tel. +44-1225-837430 
 {\bf http://www.codemist.co.uk}
 \bibitem{4} \$SPAD/zips/noweb-2.10a.tgz, the noweb source tree
-\bibitem{5} \$SPAD/zips/advi-1.2.0.tar.gz, the advi source tree
 \end{thebibliography}
 \end{document}
-
Index: lsp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/lsp/Makefile.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 Makefile.pamphlet
--- lsp/Makefile.pamphlet	28 Apr 2004 00:14:08 -0000	1.7
+++ lsp/Makefile.pamphlet	27 Jun 2004 19:24:16 -0000
@@ -650,15 +650,48 @@
 	  echo 20 applying toploop patch to unixport/init_gcl.lsp ; \
 	  patch <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.patch )
 @ 
+\subsection{GCL already installed}
+<<gcl-system>>=
+# locally installed GCL
+OUT=${OBJ}/${SYS}/bin
+
+all:
+	@echo 21 building ${LSP} ${GCLVERSION}
+
+gcldir: 
+	@echo 22 building for ${GCLVERSION}
+	echo "(compiler::link nil \"${OUT}/lisp\" \"(setq compiler::*default-system-p* t)\" \"${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a\")" | gcl
+	@echo 23 finished gcl build on `date` | tee >gcldir
+
+ccldir: ${LSP}/ccl/Makefile
+	@echo 24 building CCL
+	@mkdir -p ${INT}/ccl
+	@mkdir -p ${OBJ}/${SYS}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} )
+
+${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
+	@echo 25 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
+	@( cd ccl ; ${SPADBIN}/document ${NOISE} Makefile )
+
+document:
+	@echo 26 making docs in ${LSP}
+	@mkdir -p ${INT}/doc/lsp/ccl
+	@( cd ccl ; ${ENV} ${MAKE} document )
+
+clean:
+	@echo 27 cleaning ${LSP}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} clean )
+@
+\eject
 <<*>>=
 # gcl version 2.4.1
 OUT=${OBJ}/${SYS}/bin
 
 all:
-	@echo 14 building ${LSP} ${GCLVERSION}
+	@echo 28 building ${LSP} ${GCLVERSION}
 
 gcldir: 
-	@echo 15 building ${GCLVERSION}
+	@echo 29 building ${GCLVERSION}
 	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
 <<gcl-2.4.1.socket.patch>>
 <<gcl-2.4.1.fortran.patch>>
@@ -668,25 +701,25 @@
 	./configure --enable-vssize=65536 ; \
 	${ENV} ${MAKE} ; \
 	cp unixport/saved_gcl ${OUT}/lisp )
-	@echo 21 finished system build on `date` | tee >gcldir
+	@echo 30 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
-	@echo 22 building CCL
+	@echo 31 building CCL
 	@mkdir -p ${INT}/ccl
 	@mkdir -p ${OBJ}/${SYS}/ccl
 	@( cd ccl ; ${ENV} ${MAKE} )
 
 ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
-	@echo 23 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
+	@echo 32 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
 	@( cd ccl ; ${SPADBIN}/document ${NOISE} Makefile )
 
 document:
-	@echo 24 making docs in ${LSP}
+	@echo 33 making docs in ${LSP}
 	@mkdir -p ${INT}/doc/lsp/ccl
 	@( cd ccl ; ${ENV} ${MAKE} document )
 
 clean:
-	@echo 25 cleaning ${LSP}/ccl
+	@echo 34 cleaning ${LSP}/ccl
 	@( cd ccl ; ${ENV} ${MAKE} clean )
 @
 \eject
Index: src/booklets/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Makefile.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 Makefile.pamphlet
--- src/booklets/Makefile.pamphlet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Makefile.pamphlet	27 Jun 2004 19:24:21 -0000
@@ -19,6 +19,7 @@
 clean:
 	@echo 2 cleaning ${INT}/docs/src/booklets
 	@rm -rf ${INT}/docs/src/booklets
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/booklets/Sorting.booklet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Sorting.booklet,v
retrieving revision 1.1
diff -u -d -r1.1 Sorting.booklet
--- src/booklets/Sorting.booklet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Sorting.booklet	27 Jun 2004 19:24:34 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{/home/axiomgnu/new/mnt/linux/bin/tex/noweb}
+\usepackage{../../src/scripts/tex/noweb}
 \begin{document}
 \title{Sorting Facilities}
 \author{Timothy Daly}
Index: src/boot/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/boot/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/boot/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.6
+++ src/boot/Makefile.pamphlet	27 Jun 2004 19:24:42 -0000
@@ -1615,6 +1615,7 @@
 clean:
 	@echo 43 cleaning ${OUT}
 	@rm -f ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \section{The Makefile}
Index: src/clef/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 Makefile.pamphlet
--- src/clef/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.3
+++ src/clef/Makefile.pamphlet	27 Jun 2004 19:24:42 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{../../mnt/${SYS}/bin/axiom}
 \begin{document}
 \title{\$SPAD/src/clef Makefile}
 \author{Timothy Daly}
Index: src/clef/edible.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/edible.c.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 edible.c.pamphlet
--- src/clef/edible.c.pamphlet	7 Feb 2004 03:24:24 -0000	1.3
+++ src/clef/edible.c.pamphlet	27 Jun 2004 19:24:44 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{../../mnt/${SYS}/bin/axiom}
 \begin{document}
 \title{\$SPAD/src/clef edible.c}
 \author{The Axiom Team}
@@ -159,7 +159,7 @@
     perror("ptyopen failed");
     exit(-1);
   }
-  
+
   /* call the routine that handles signals */
   catch_signals();
   
Index: src/doc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/Makefile.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 Makefile.pamphlet
--- src/doc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.7
+++ src/doc/Makefile.pamphlet	27 Jun 2004 19:24:44 -0000
@@ -105,6 +105,7 @@
 
 clean:
 	@echo 4 cleaning ${SRC}/doc
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/doc/axiom.bib.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/axiom.bib.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 axiom.bib.pamphlet
--- src/doc/axiom.bib.pamphlet	28 Aug 2003 12:28:30 -0000	1.1
+++ src/doc/axiom.bib.pamphlet	27 Jun 2004 19:25:44 -0000
@@ -12231,7 +12231,7 @@
 \subsection{Makefile}
 <<Makefile>>=
 @MISC{Makefile,
-   path=./mnt/linux/bin/Makefile.pamphlet
+   path=./mnt/${SYS}/bin/Makefile.pamphlet
 }
 
 @
Index: src/etc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/etc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.6
+++ src/etc/Makefile.pamphlet	27 Jun 2004 19:25:44 -0000
@@ -91,6 +91,7 @@
 	@rm -rf ${MID}
 	@echo 4 cleaning ${DOC}
 	@rm -rf ${DOC}
+	@rm -f Makefile Makefile.dvi
 
 @
 \eject
Index: src/etc/axiom
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/axiom,v
retrieving revision 1.3
diff -u -d -r1.3 axiom
--- src/etc/axiom	7 Feb 2004 03:24:24 -0000	1.3
+++ src/etc/axiom	27 Jun 2004 19:25:44 -0000
@@ -1,8 +1,10 @@
-export AXIOM
 
 system=`uname -s`
 
 case "$system" in
+    FreeBSD) clef -e $AXIOM/bin/AXIOMsys "$@"
+        ;;
+    
     Linux) clef -e $AXIOM/bin/AXIOMsys "$@"
         ;;
     
Index: src/include/useproto.h
===================================================================
RCS file: /cvsroot/axiom/axiom/src/include/useproto.h,v
retrieving revision 1.2
diff -u -d -r1.2 useproto.h
--- src/include/useproto.h	9 Oct 2003 10:45:16 -0000	1.2
+++ src/include/useproto.h	27 Jun 2004 19:25:44 -0000
@@ -34,7 +34,7 @@
 #ifndef _USEPROTO_H_
 #define _USEPROTO_H_ 1
 
-#if defined(SGIplatform)||defined(LINUXplatform)||defined(HPplatform) ||defined(RIOSplatform) ||defined(RIOS4platform) || defined(SUN4OS5platform)
+#if defined(SGIplatform)||defined(LINUXplatform)||defined(HPplatform) ||defined(RIOSplatform) ||defined(RIOS4platform) || defined(SUN4OS5platform)||defined(FREEBSDplatform)
 #ifdef _NO_PROTO
 #undef _NO_PROTO
 #endif
Index: src/input/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/input/Makefile.pamphlet,v
retrieving revision 1.9
diff -u -d -r1.9 Makefile.pamphlet
--- src/input/Makefile.pamphlet	27 Jun 2004 15:01:25 -0000	1.9
+++ src/input/Makefile.pamphlet	27 Jun 2004 19:26:10 -0000
@@ -6841,6 +6841,7 @@
 	@rm -rf ${MID}
 	@echo 7 cleaning ${OUT}
 	@rm -rf ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 <<algaggr>>
 <<algbrbf>>
Index: src/interp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- src/interp/Makefile.pamphlet	27 Jun 2004 15:01:27 -0000	1.11
+++ src/interp/Makefile.pamphlet	27 Jun 2004 19:26:49 -0000
@@ -616,8 +616,10 @@
 	@ echo '(load "${OUT}/c-util")' >> ${OUT}/makedep.lisp
 	@ echo '(unless (probe-file "${OUT}/g-util.${O}") (compile-file "${OUT}/g-util.${LISP}" :output-file "${OUT}/g-util.${O}"))' >> ${OUT}/makedep.lisp
 	@ echo '(load "${OUT}/g-util")' >> ${OUT}/makedep.lisp
-	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+#	@ (cd ${MNT}/${SYS}/bin ; \
+#	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+	@ ( cd ${OBJ}/${SYS}/bin && \
+	   echo '(setq si::*collect-binary-modules* t)(load "${OUT}/makedep.lisp")(compiler::link (remove-duplicates si::*binary-modules* :test (quote equal)) "$(DEPSYS)" "(setq si::*collect-binary-modules* t)(load \"$(OUT)/makedep.lisp\")(gbc t)(when si::*binary-modules* (error si::*binary-modules*))(setq si::collect-binary-modules* nil si::*binary-modules* nil)(gbc t)(setq compiler::*default-system-p* t)" "" nil)' | ${LISPSYS})
 	@ echo 4 ${DEPSYS} created
 
 @
@@ -669,8 +671,10 @@
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >> ${OUT}/makeint.lisp
-	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+#	@ (cd ${OBJ}/${SYS}/bin ; \
+#	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	@ (cd ${OBJ}/${SYS}/bin && \
+	  echo '(setq si::*collect-binary-modules* t)(setq x si::*system-directory*)(load "${OUT}/makeint.lisp")(setq si::*system-directory* x)(compiler::link (remove-duplicates si::*binary-modules* :test (quote equal)) "$(SAVESYS)" "(setq si::*collect-binary-modules* t)(load \"$(OUT)/makeint.lisp\")(when si::*binary-modules* (error si::*binary-modules*)(setq si::collect-binary-modules* nil si::*binary-modules* nil)(setq compiler::*default-system-p* t)(gbc t))" "$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" nil)' | ${LISPSYS})
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
Index: src/interp/debugsys.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/debugsys.lisp.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 debugsys.lisp.pamphlet
--- src/interp/debugsys.lisp.pamphlet	24 May 2004 22:53:51 -0000	1.2
+++ src/interp/debugsys.lisp.pamphlet	27 Jun 2004 19:26:49 -0000
@@ -79,7 +79,7 @@
       (thesymb "/int/interp/buildom.clisp")
       (thesymb "/int/interp/cattable.clisp")
       (thesymb "/int/interp/cformat.clisp")
-      (thesymb "/obj/linux/interp/cfuns.o")
+      (thesymb "/obj/${SYS}/interp/cfuns.o")
       (thesymb "/int/interp/clam.clisp")
       (thesymb "/int/interp/clammed.clisp")
       (thesymb "/int/interp/comp.lisp")
@@ -152,7 +152,7 @@
       (thesymb "/int/interp/sfsfun.clisp")
       (thesymb "/int/interp/simpbool.clisp")
       (thesymb "/int/interp/slam.clisp")
-      (thesymb "/obj/linux/interp/sockio.o")
+      (thesymb "/obj/${SYS}/interp/sockio.o")
       (thesymb "/int/interp/spad.lisp")
       (thesymb "/int/interp/spaderror.lisp")
       (thesymb "/int/interp/template.clisp")
@@ -232,13 +232,13 @@
    ())
   (list 
    (thesymb "/int/interp/ax.clisp"))
-  "/mnt/linux"
+  "/mnt/${SYS}"
   "/lsp"
   "/src"
   "/int"
   "/obj"
   "/mnt"
-  "linux")
+  "${SYS}")
 (in-package "SCRATCHPAD-COMPILER")
 (boot::set-restart-hook)
 (in-package "BOOT")
@@ -247,7 +247,7 @@
 (load (user::thepath "/int/interp/obey.lsp"))
 ;(si::multiply-bignum-stack 10)
 (si::gbc-time 0)
-(setq si::*system-directory* (user::thepath "/mnt/linux/bin/"))
+(setq si::*system-directory* (user::thepath "/mnt/${SYS}/bin/"))
 (gbc t)
 
 @
Index: src/interp/util.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/util.lisp.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 util.lisp.pamphlet
--- src/interp/util.lisp.pamphlet	24 May 2004 22:54:05 -0000	1.5
+++ src/interp/util.lisp.pamphlet	27 Jun 2004 19:27:00 -0000
@@ -813,7 +813,7 @@
 This function will do that. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(recompile-all-libs "/spad/mnt/linux/algebra")
+(recompile-all-libs "/spad/mnt/${SYS}/algebra")
 \end{verbatim}
 <<recompile-all-libs>>=
 (defun recompile-all-libs (dir)
@@ -838,11 +838,11 @@
 Note that it will build a pathname from the current {\bf AXIOM}
 shell variable. So if the {\bf AXIOM} shell variable had the value
 \begin{verbatim}
-/spad/mnt/linux
+/spad/mnt/${SYS}
 \end{verbatim}
 then the wildcard expands to
 \begin{verbatim}
-/spad/mnt/linux/nalg/*.spad
+/spad/mnt/${SYS}/nalg/*.spad
 \end{verbatim}
 and all of the matching files would be recompiled.
 <<recompile-all-algebra-files>>=
@@ -879,7 +879,7 @@
 before compiling this file. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(reroot "/spad/mnt/linux")
+(reroot "/spad/mnt/${SYS}")
 \end{verbatim}
 <<reroot>>=
 (defun reroot (dir)
Index: src/lib/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/Makefile.pamphlet,v
retrieving revision 1.8
diff -u -d -r1.8 Makefile.pamphlet
--- src/lib/Makefile.pamphlet	27 Jun 2004 15:01:39 -0000	1.8
+++ src/lib/Makefile.pamphlet	27 Jun 2004 19:27:02 -0000
@@ -490,6 +490,7 @@
 clean:
 	@echo 70 cleaning ${IN}
 	@rm -rf ${MID} ${OUT} ${DOCINT} ${DOCMNT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \subsection{Makefile documentation}
Index: src/lib/XDither.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XDither.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XDither.c.pamphlet
--- src/lib/XDither.c.pamphlet	27 Jun 2004 15:01:41 -0000	1.4
+++ src/lib/XDither.c.pamphlet	27 Jun 2004 19:27:02 -0000
@@ -51,7 +51,6 @@
 
 #include <stdio.h>
 #include <stdlib.h>
-#include <malloc.h>
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
Index: src/lib/XShade.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XShade.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XShade.c.pamphlet
--- src/lib/XShade.c.pamphlet	27 Jun 2004 15:01:42 -0000	1.4
+++ src/lib/XShade.c.pamphlet	27 Jun 2004 19:27:04 -0000
@@ -50,7 +50,6 @@
 #include "useproto.h"
 
 #include <stdio.h>
-#include <malloc.h>
 #include <stdlib.h>
 
 #include <X11/Xlib.h>
Index: src/lib/cfuns-c.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/cfuns-c.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 cfuns-c.c.pamphlet
--- src/lib/cfuns-c.c.pamphlet	27 Jun 2004 15:01:43 -0000	1.4
+++ src/lib/cfuns-c.c.pamphlet	27 Jun 2004 19:27:04 -0000
@@ -52,7 +52,6 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <string.h>
-#include <malloc.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 
Index: src/lib/fnct_key.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/fnct_key.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 fnct_key.c.pamphlet
--- src/lib/fnct_key.c.pamphlet	27 Jun 2004 15:01:43 -0000	1.4
+++ src/lib/fnct_key.c.pamphlet	27 Jun 2004 19:27:06 -0000
@@ -352,7 +352,7 @@
                 close(fd);
             }
         }
-        bsdSignal(SIGCLD, null_fnct,RestartSystemCalls);
+        bsdSignal(SIGCHLD, null_fnct,RestartSystemCalls);
         switch (id = fork()) {
           case -1:
             perror("Special key");
Index: src/lib/openpty.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/openpty.c.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 openpty.c.pamphlet
--- src/lib/openpty.c.pamphlet	27 Jun 2004 15:01:44 -0000	1.7
+++ src/lib/openpty.c.pamphlet	27 Jun 2004 19:27:06 -0000
@@ -92,7 +92,7 @@
 #endif
 
 {
-#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) 
+#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(FREEBSDplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
   
@@ -204,7 +204,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-#if defined(SUNplatform) || defined (HP9platform) || defined(LINUXplatform) 
+#if defined(FREEBSDplatform) || defined(SUNplatform) || defined (HP9platform) || defined(LINUXplatform) 
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
Index: src/lib/pixmap.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/pixmap.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 pixmap.c.pamphlet
--- src/lib/pixmap.c.pamphlet	27 Jun 2004 15:01:44 -0000	1.4
+++ src/lib/pixmap.c.pamphlet	27 Jun 2004 19:27:16 -0000
@@ -361,8 +361,7 @@
 write_pixmap_file(Display *dsp, int scr, char  *fn, Window wid, int x, int y, int width,int height)
 #endif
 {
-  XpmAttributes attr;
-  XImage *xi,*xireturn;
+  XImage *xi;
   int status;
   
   /* reads image structure in ZPixmap format */
Index: src/lib/wct.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/wct.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 wct.c.pamphlet
--- src/lib/wct.c.pamphlet	27 Jun 2004 15:01:44 -0000	1.4
+++ src/lib/wct.c.pamphlet	27 Jun 2004 19:27:16 -0000
@@ -287,7 +287,7 @@
   printTime((long *)&(pwct->ftime));
   cc = skimString(pwct->fimage, pwct->fsize, NHEAD, NTAIL);
   printf("%s", "            " + (cc - (NHEAD + NTAIL)));
-  printf(" [%d w, %d c]", pwct->wordc, pwct->fsize);
+  printf(" [%d w, %ld c]", pwct->wordc, (long)pwct->fsize);
   printf("\n");
 
 #ifdef SHOW_WORDS
Index: src/scripts/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/Makefile.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 Makefile.pamphlet
--- src/scripts/Makefile.pamphlet	27 Jun 2004 15:01:44 -0000	1.2
+++ src/scripts/Makefile.pamphlet	27 Jun 2004 19:27:16 -0000
@@ -19,6 +19,10 @@
 	@cp -pr * ${OUT}
 	@mkdir -p ${OUT}/tex
 	@rm -f ${OUT}/Makefile*
+
+clean:
+	@echo 2 cleaning ${SRC}/scripts
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/scripts/document
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/document,v
retrieving revision 1.3
diff -u -d -r1.3 document
--- src/scripts/document	12 Nov 2003 11:16:15 -0000	1.3
+++ src/scripts/document	27 Jun 2004 19:27:16 -0000
@@ -1,12 +1,14 @@
 #!/bin/sh
+
 latex=`which latex`
 if [ "$latex" = "" ] ; then
   echo document ERROR You must install latex first
   exit 0
 fi
 
-tangle=$AXIOM/bin/lib/notangle
-weave=$AXIOM/bin/lib/noweave
+tangle=notangle
+weave=noweave
+
 if [ "$#" = "3" ]; then
  REDIRECT=$2
  FILE=`basename $3 .pamphlet`


\start
Date: Sun, 27 Jun 2004 21:53:15 +0200
From: Magnus Larsson
To: Tim Daly
Subject: Re: Axiom-developer post from Magnus Larsson requires approvalHello

Hello Tim,

I checked out Axiom from CVS today around 9 pm and tried to build it using my 
i686-pc-linux-gnu, GCC-3.3.1, Binutils 2.15 system. I got the same build 
errors as before. I then performed the test as you stated them below. The 
second compile did not fail.

>
The source 
file /home/magnus/usr/source/axiom/cvs040627/axiom/int/interp/apply.clisp is 
not found.
9 
making /home/magnus/usr/source/axiom/cvs040627/axiom/mnt/linux/autoload/apply.o 
from /home/magnus/usr/source/axiom/cvs040627/axiom/obj/linux/interp/apply.o
cp: cannot stat 
`/home/magnus/usr/source/axiom/cvs040627/axiom/obj/linux/interp/apply.o': No 
such file or directory
make[3]: *** 
[/home/magnus/usr/source/axiom/cvs040627/axiom/mnt/linux/autoload/apply.o] 
Error 1
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs040627/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/magnus/usr/source/axiom/cvs040627/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs040627/axiom'
make: *** [all] Error 2
magnus@lfs:~/usr/source/axiom/cvs040627/axiom> obj/linux/bin/lisp

>(compile-file "foo.lisp")

Compiling foo.lisp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.lisp.
#p"foo.o"

>(load "foo")

Loading foo.o
start address -T 0x83ec630 Finished loading foo.o
128

>(system::save-system "newlisp")
magnus@lfs:~/usr/source/axiom/cvs040627/axiom> ./newlisp

>(compile-file "foo.lisp")

Compiling foo.lisp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.lisp.
#p"foo.o"

>(load "foo")

Loading foo.o
start address -T 0x83fff30 Finished loading foo.o
128

>(quit)
magnus@lfs:~/usr/source/axiom/cvs040627/axiom>

The second compile did not fail.

Magnus L

On Sunday 27 June 2004 17.32, root wrote:
> Magnus,
>
> You have the correct idea. There is just one more step...
>
> obj/linux/bin/lisp                   (start the lisp image)
> (compile-file "foo.lisp")            (compile a lisp file)
> (load "foo")                         (load the compiled file (note: no
> .lisp)) (system::save-system "newlisp")      (save a new image)
> newlisp                              (start the newimage lisp)
> (compile-file "foo.lisp")            (compile in the new image)                 
> (load "foo")                         (load the result)
>
>
> It is conjectured that the second compile-file will fail because
> the save-system did not build a correct image. That's what I'm
> trying to test.

\start
Date: Sun, 27 Jun 2004 21:19:54 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error) 

root writes:
> >  - Tim prefers to have a big sources with all included dependencies in
> >    order to control the built system;
> 
> that's correct. Axiom is a very complex beast (probably over a million
> lines in the fully developed system). It is very version dependent for
> many subsystems, including GCL. In order to keep the quality of the
> system at a high level the system is built and tested with particular
> versions of GCL. In fact, a great deal of effort goes into making sure
> that it works with the latest version. Axiom periodically takes 
> snapshots of the GCL CVS in order to get the latest version. The
> snapshots are then modified during the build. 

This bit makes it very hard to port :-). Would it be possible check in
an _untarred_ GCL? The current method of tarball+patches makes it hard
to have patches of our own, particularly when they conflict with yours.

> It is possible, if you have locally modified GCL, to replace the
> GCL snapshot version (it is in src/zips) with your local version
> but I can't guarantee that Axiom will work. I've tried to fully
> document every change for every version of GCL with a complete
> explanation so you can understand the what and why. The documentation
> is in the various Makefile.pamphlet files (see the Makefile.dvi).

Yeah. :-( I had GCL-current working for ages, but in a conflict-merge
I seem to have broken something (perhaps).

> >  - it is possible to build Axiom with an external GCL. In fact, Camm
> >    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
> >    and other software, is doing exactly that for the axiom debian
> >    package. I don't know however if the machinery has been included in
> >    current sources of Axiom.
> 
> that's not strictly correct. Axiom will not fully run on an external GCL.

It needs patches, which Camm gave me a year or so ago, and which are now
broken. (Maybe).

> depending on what you are doing it will fail. in particular, axiom adds
> special socket handling code to GCL which will be used by the newly added
> graph capabilities. further, axiom has special build-time flags (documented
> in the top level Makefile) that need to be set to your particular version
> of GCL. If you are not using the same version that is included with the
> Axiom CVS you need to change these flags and rebuild your local version.

Not strictly true; GCL can load code fragments, and an external build of
GCL build Axiom successfully for me for a long time.

> in addition to sockets Axiom is adding code to do machine-level numeric
> support. i have a local version (not yet documented, tested, and checked in)
> which contains support for BLAS (Basic Linear Algebra Subroutines). These
> are built into the GCL image at system build time. Axiom's numerics will
> depend on these routines as well as additional routines that are in the
> queue to add. There has been some discussion about pushing the numerics
> support into GCL as Camm is also the BLAS maintainer. Since Axiom is
> currently the only user it is not clear that GCL wants or needs them.

You should be able to to the GCL dlopen(3) equivalent load of stuff like that.

> A third package is also in my local version that is going to be added
> which requires GCL changes. I've been working with ltk. This is a 
> lisp TK toolkit that runs on almost every lisp (except, it seems, GCL).
> The current GCL/TK package is broken as far as I can tell. I can get it
> to work but it promptly crashes. We're working on a new Axiom GUI to
> replace the lost techexplorer and it is being developed using TCL/TK.
> Since the current GCL/TK doesn't work and ltk is almost all native
> common lisp we're going to use it going forward. Hopefully once it
> runs I can convince Camm to support it also but, again, since Axiom is
> the only user it is not clear that it is worth adding it to GCL.

dlopen equivalent?

> so it is unlikely, going forward, that Axiom will run on your installed
> version of GCL.

... without a bit of work :-)

\start
Date: Sun, 27 Jun 2004 17:14:15 -0400
From: Tim Daly
To: Magnus Larsson
Subject: re: Axiom-developer post from Magnus Larsson requires approvalHello

so much for that idea.
i'm still puzzled about why it fails. 
the code is straight common lisp.
is there someplace to download your version of SUSE?

\start
Date: Sun, 27 Jun 2004 17:30:36 -0400
From: Tim Daly
To: Mark Murray
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Well, in theory I believe I can dynamically load the C code to
interface to external libraries. Unfortunately I know how to 
link C code with C code so I know how to modify images. I never
learned how to dynamically link the C code. If I learned how to 
dynamically link the code I could probably get away without 
modifying the image.

\start
Date: Sun, 27 Jun 2004 23:05:45 +0200
From: Magnus Larsson
To: Tim Daly
Subject: re: Axiom-developer post from Magnus Larsson requires approvalHello

Hello Tim,

Yes, SUSE 9.1 can be downloaded from
http://www.suse.com/us/private/download/ftp/int_mirrors.html
Instruction:
http://www.suse.com/us/private/download/suse_linux/index.html

SUSE relies on a two step process with a boot CD followed by a network 
install. I have not tried this. 

Best regards,

Magnus L
======================
Installation Guideline:
This SUSE Linux 9.1 installation tree is suitable for installation via ftp,
http, nfs, smb or hard disk.

System requirements

  You need at least 96MB main memory. To install on a machine with less
  memory a (linux) swap partition is necessary.

Preparation

  o booting from CD

    Download the iso image boot/boot.iso and burn a CD with it.

  o booting from floppy

    Download the floppy disk image boot/bootdisk as well as the module disk
    image files you need (at least boot/modules1 and likely the network
    modules from boot/modules3).

    Write the images to floppy disks using the 'dd' command:

      dd if=[path_to_image] of=/dev/fd0 bs=36b

    On non-linux systems, use the rawrite utility from the dosutils/rawrite
    directory (rawrite.exe).

Installation

  Boot from CD/floppy and at the bootpromt enter the installation source:

    linux install=ftp://ftp_server/directory

  Remember to substitute 'ftp_server' and 'directory' with the appropriate
  values (e.g. install=ftp://[IP-ADDRESS]/pub/suse/i386/9.1 if you're
  installing from the SUSE ftp server).
  
  Alternatively, choose 'manual installation' and configure the network in
  the installation program.


Preparing your own installation server

  Just copy the whole installation tree to your local disk and make it
  available via network.



  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  !!!!                  IMPORTANT NOTE                              !!!!!
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  If you get errors such as "No installation media found on server" or
  "Package foo.rpm does not exist" it most likely means that
        a) The ftp/http server you are using is not accepting new
           connections.
        b) You've misconfigured the local network or proxy settings
  In either case, please don't contact ftpadmin about this since
  we can't fix your network and/or have no control over how busy the
  ftp servers are.

On Sunday 27 June 2004 23.14, root wrote:
> so much for that idea.
> i'm still puzzled about why it fails.
> the code is straight common lisp.
> is there someplace to download your version of SUSE?

\start
Date: Sun, 27 Jun 2004 18:01:05 -0400
From: Tim Daly
To: Magnus Larsson
Subject: re: Axiom-developer post from Magnus Larsson requires approvalHello

rats. that can't work for me. 
all of my compile-farm machines are
offline and can't do network installs.

\start
Date: Mon, 28 Jun 2004 08:44:18 +1000
From: Mike Thomas
To: David Mentre
Subject: GCL version in Axiom CVS

Hi David.

| This might pinpoint an issue with GCL. Axiom is using its own version of
| GCL (2.6.2-something)

For the record, as a completely separate issue and without hindering the
point of your email to Magnus note that in fact, although labelled 2.6.2 in
the Axiom CVS source tree, I believe that this is in fact GCL CVS HEAD based
on the debugging output from "o/unexnt.c" when built under Windows.

\start
Date: Sun, 27 Jun 2004 23:40:16 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error) 

root writes:
> Well, in theory I believe I can dynamically load the C code to
> interface to external libraries. Unfortunately I know how to 
> link C code with C code so I know how to modify images. I never
> learned how to dynamically link the C code. If I learned how to 
> dynamically link the code I could probably get away without 
> modifying the image.

Would you like an account on a FreeBSD box?

\start
Date: Sun, 27 Jun 2004 20:40:49 -0400
From: Tim Daly
To: Mark Murray
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Mark,

If there is a FreeBSD box where I could try an Axiom build
that would be great. I can debug a failing Axiom build faster.
Be forewarned that an Axiom build can eat a system for several
days (depending on CPU speed, 3hrs at 2Ghz, 6hrs at 1Ghz, etc).

\start
Date: Sun, 27 Jun 2004 22:50:07 -0400
From: Tim Daly
To: Jonathan Aidan
Subject: Re: Build Axiom on MacosX Panther 10.3.4

Unfortunately Unix (BSD, Apple) and Linux are not the same thing.
I don't have access to either kind of system so I'm unable to work
on the porting issues (although someone just offered FreeBSD access). 

I believe that debian has a port of axiom that might run on
apple. Please check the debian site.

It is a long term plan to support these systems but, of course,
it will take work.

================================================================

I m really a newbie in UNIX world. I interested in Axiom for
mathematical purposes. I have tried to build axiom from the CVS
distribution but i don t succeded. I have installed the X11 package
from Apple. The first problem i encounter was the SIGCLD/SIGCHLD
problem in the fnct_key.h file that i fix. But there are many more
problems... MacosX is build on Darwin, itself build on a BSD
distribution.

Jonathan Aidan <Jonathan Aidan>
Best Regards.

\start
Date: Mon, 28 Jun 2004 10:28:14 +0000
From: Martin Rubey
To: list
Subject: RE: Complex exponentiation and 0

Shouldn't 

[bugs #9313] 0^0 handled inconsistently

be closed=3F David Mentr=E9 has submitted a second bug report,

[bugs #9424] Bug in handling 0^0 in Axiom

which subsumes the discussion, I think. To summarize:

bugs:
-----------------------------
0::CARD ^ 0::CARD gives 

0**0 not defined for cardinal numbers.

but should be 1::CARD (a reference should be included in both the bug report
and eventually in the patch)
-----------------------------
complex(0,0)^complex(2,2.0) gives

log 0 generated

but should give 0

-----------------------------
non-bugs:
-----------------------------

0^0
1 Type: PositiveInteger

0.0^0
1.0 Type: Float

are correct, since there is no limit for Integers and the type of zero in the
exponent is Integer.
------------------------------
0^0.0

 0**0 is undefined

0.0^0.0

 0**0 is undefined

are correct, since there is a limit for Floats
------------------------------ 
----------------------------------------------------------------

If all of this is correct, could somebody who is entitled to do so 

* add a comment to [bugs #9313] 0^0 handled inconsistently that it is not a
  bug, (maybe simply include a pointer to this mail) but there are related bugs
  described in [bugs #9424] Bug in handling 0^0 in Axiom

* close it.

\start
Date: Mon, 28 Jun 2004 11:12:57 +0000
From: Martin Rubey
To: list
Subject: Re: indefinites

William Sit writes:

...

 > Eventually, when this is operational, neither the input nor the output need
 > to use the word "Indefinite" (which is needed only internally: so every
 > declaration without an accompanying assignment will belong to the indefinite
 > domain; an object of the indefinite domain can be "assigned" a value and be
 > "retracted" to the domain, all transparently done. This may suggest a simple
 > method is to put a tag on the object, whether it has been assigned a domain
 > value or not. This would probably work for a while until we want to go to
 > more abstract levels such as computing with indefinites like p+q. The code
 > for the underlying domain will be so messed up with conditionals that it may
 > be wiser to separate the domain from its indefinite version. After all, we
 > separate the domain INT from POLY INT. Fateman has some good suggestions to
 > use lazy evaluation techniques to hold the proliferation of conditionals and
 > handle indefinite loops.
 > 
 > However this is done, the representation of the indefinite integer x will be
 > different from the representation of an integer x that has not been assigned
 > a value (indeed, the latter does not yet have one). This necessary change in
 > representation causes all the operations involving integers to be
 > syntactically invalid on indefinite integers.

I think I agree with this.

A little while ago I thought about how I could make EXPR smarter (in order to
allow for expressions over finite fields) and the idea occurred to me that it
would be "more" correct to have a domain

MY-EXPR [[var1, type1], [var2, type2] ...].

Awful, isn't it?

On the other hand, given the possibility that we could declare variables to be
of some type, this is not so far fetched! In fact, wouldn't this make the
domain EXPR obsolate altogether?

Given x an Indefinite Integer,

2^x*factorial(x)/sqrt(x)

would be an Indefinite AlgebraicNumber, and we could have a modeline

sum(Indefinite AlgebraicNumber, SegmentBinding Indefinite AlgebraicNumber).

Or, given x a Variable

(x^3+2*x^2+x+1)::POLY PF 5

would be a Polynomial, but x an Indefinite PF 5, it would an Indefinite PF 5...

Is this correct?

It seems, that a domain for transcendental numbers is missing...

\start
Date: Mon, 28 Jun 2004 14:58:37 +0200
From: Juergen Weiss
To: Tim Daly, Mark Murray
Subject: RE: Axiom & internal/external GCL (was: Re: Axiomcvs 040624 build error)

Hi,

I think, we should unbundle gcl and other additional software. To
get Axiom running and some gcl interactions resolved, it was
certainly ok to pack everything together in the beginning. But these
problems
should be solved now. Most package systems (debian, BSDs etc)
expect that the lisp system and other packages are 
separate. Besides it will make Axiom much easier to port to
other platforms. The technical details of loading C code
have already been adressed in Camm's mails. 

> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org 
>  On Behalf Of root
> Sent: Sunday, June 27, 2004 11:31 PM
> To: Mark Murray
> Cc: list; Tim Daly
> Subject: Re: Axiom & internal/external GCL (was: Re: 
> Axiomcvs 040624 build error)
> 
> Well, in theory I believe I can dynamically load the C code to
> interface to external libraries. Unfortunately I know how to 
> link C code with C code so I know how to modify images. I never
> learned how to dynamically link the C code. If I learned how to 
> dynamically link the code I could probably get away without 
> modifying the image.

\start
Date: Mon, 28 Jun 2004 09:49:02 -0400
From: Bill Page
To: William Sit
Subject: RE: indefinites

William,

Thank you for bearing with my scepticism of the notion of
Indefinite Integer as a type.

On Saturday, June 26, 2004 11:56 PM William Sit
William Sit wrote:
> 
> Bill Page wrote:
> > On Thursday, June 24, 2004 2:49 PM you Tim wrote:
> > >
> > > The distinction between Integer and Indefinite Integer is quite 
> > > subtle.
> > ...
> However, there should be no disagreement that the two
> mathematically are equivalent (that is, both obey the same 
> rules operating on integers) but computationally different.
>

I think we need to define more clearly what you mean by
"mathematically equivalent" and "computationally different",
but I don't think that I can agree that they are mathematically
equivalent, or at least not logically equivalent. For example
2=4 is a proposition but x=4 where x is an Integer is a predicate.
In the predicate calculus x=4 is neither true nor false until
we supply a quantifier or an instance. Computationally, at the
root of this is the notion of a (typed) lambda calculus. See
for example

  http://www.lfcs.inf.ed.ac.uk/reports/98/ECS-LFCS-98-381/

Programming languages like Haskel and the ML family pretty
much seem to have worked this out in detail. Perhaps what
you are trying to do is to make Axiom more "functional" in
the sense of these languages?

I will comment on other points in your email a little later.

Regards,
Bill Page.
 
> Bill continues:
> 
> > In the Axiom book p. 24 the expression x:Integer is called
> > a "declaration" and says only that it restricts the values 
> > that can be assigned to the variable, certain not that it
> > is no longer a variable simply because we have declared a
> > type! That's why I found Axiom's  behaviour very surprising.
> > ...

\start
Date: Mon, 28 Jun 2004 10:05:36 -0400
From: Bill Page
To: list
Subject: RE: Axiom & internal/external GCL (was: Re: [Axiom-developer]Axiomcvs	040624 build error)

On Monday, June 28, 2004 8:59 AM Juergen Weiss wrote:
> 
> I think, we should unbundle gcl and other additional
> software. To get Axiom running and some gcl interactions 
> resolved, it was certainly ok to pack everything together in 
> the beginning. But these problems should be solved now. Most 
> package systems (debian, BSDs etc) expect that the lisp 
> system and other packages are separate. Besides it will
> make Axiom much easier to port to other platforms. The
> technical details of loading C code have already been
> adressed in Camm's mails. 

I agree with this. It is normal practice for complex systems
like Axiom to specify dependencies. After all, GCL depends
intimately on GCC and binutils but we do not include a copy
of these in the Axiom installation. What is needed is simply
to document the known dependencies and to modify the Axiom
build to make patching GCL (and noweb) unnecessary.

Regarding ports to other systems, we are already doing this
in the case of the port to Windows.

\start
Date: Mon, 28 Jun 2004 12:03:37 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Axiom & internal/external GCL (was: Re: [Axiom-developer]Axiomcvs	040624 build error)

> > I think, we should unbundle gcl and other additional
> > software. To get Axiom running and some gcl interactions 
> > resolved, it was certainly ok to pack everything together in 
> > the beginning. But these problems should be solved now. Most 
> > package systems (debian, BSDs etc) expect that the lisp 
> > system and other packages are separate. Besides it will
> > make Axiom much easier to port to other platforms. The
> > technical details of loading C code have already been
> > adressed in Camm's mails. 
> 
> I agree with this. It is normal practice for complex systems
> like Axiom to specify dependencies. After all, GCL depends
> intimately on GCC and binutils but we do not include a copy
> of these in the Axiom installation. What is needed is simply
> to document the known dependencies and to modify the Axiom
> build to make patching GCL (and noweb) unnecessary.
> 
> Regarding ports to other systems, we are already doing this
> in the case of the port to Windows.

Well, as they say, advocacy is volunteering. :-)

If we were to attack the problem of making Axiom live without 
specific GCL dependencies I'd suggest that we need to broaden
the base of lisps that it runs on. The lisp code in the interpreter
already contains #+ and #- for some half-dozen lisp systems (I used
to have it running on spice (cmucl), allegro, symbolics, vmlisp, etc.
It also was released to me running on CCL by Arthur Norman. In fact,
I've continued to include CCL with the specific intention of getting
that code running again. 

The top level makefile contains parameters for customizing the
system to other lisps (e.g. the name of the extensions vary among
the lisps (.clisp, .lisp, .lsp, .l, etc for source, .o, .x86, .obj, etc
for binaries). These can easily be customized by simple one-line
changes. (Which will, of course, break things where I was forgetful
but the design and most of the implementation exists).

The plan is to build on other lisps. CMUCL is an important one
because it has a lot of nice optimization tools that were used
to improve the lisp code. CCL is important because it allows the
system to be quickly ported (it is a byte-coded lisp similar to
the java runtime). 

The issue is not intention but time and knowledge.

It is true that Camm knows and has written down the technique for
dynamically loading C code with GCL lisp cover functions. I've seen it
but not internalized it. However, in order to "do it right" we need
to find the same functions in at least 2 other lisps (e.g. CMUCL
and CCL) or if they don't exist to implement those techniques. Then
we need to create new files that #+ and #- the various lisp-level
enhancements so they work in a transparent way. And then we need
to add a layer to the build process so that the code is properly
compiled at the right time (likely between the lisp and boot steps).

Someone needs to build a GCL image (the code is there already)
and explain how to dynamically link to C code with lisp cover 
functions.

Someone needs to build a CCL image (the code is there already)
and explain how to dynamically link to C code with lisp cover 
functions.

Someone needs to build a CMUCL image (the code used to be there)
and explain how to dynamically link to C code with lisp cover 
functions.

Given these three examples we can design a generic layer that
handles all three. It should then be a simple job to make it
fully portable and we can stop shipping any lisp CVS information.


My general plan (at the moment) lies along the following lines:

current state
  rebuild
    graphics capability  (1st draft just uploaded)
    numeric capability   (1st draft in process locally)
    hypertex capapility  (1st draft in process locally)
    GUI capability       (ltk?)
  document
    complete original axiom book (1st draft uploaded)
    complete 'gemstone' book based on littlewood (on private website)
    literate framework to handle all pamphlets/booklets (advi rewrite)
    literate version of algebra (outstanding requests for papers)
    literate version of internals (ongoing)
  testing
    re-automate regression testing 
    CATS (computer algebra test suite) documented test cases (locally)
  platform port
    windows (Camm, Bill, etc)
    apple   (BSD tested but failed)
  lisp port
    ccl     (partial documentation)
    cmucl   
    clisp

within each of these areas (rebuild, document, testing, platform port,
and lisp port) are the mundane tasks, the "up to date and innovate"
tasks and the research tasks.

For example, in the algebra area we need to rebuild the numerics, 
document the existing code and re-automate the regression tests (the
machinery is there but not yet recovered). That is all mundane work.
For "up to date and innovate" in the algebra we need to bring Axiom
in line with the state of the art. For instance, we need to have the
capability to do symbolic summation. For the research work, there is
the push to integrate ACL2 (a proof language), the indefinite research
recently discussed here, the push to do more symbolic manipulation
(i.e. solve problems by theorems rather than computation), develop
the GUI to be able to derive an "intensional stance", etc.

Axiom is a reasonably large project and I'm very open to suggestion
about development. The fact that it ships with GCL sources is not
really by design but is due to my ignorance about a general mechanism.
If anyone designs a general mechanism that works in GCL, CCL, and
CMUCL we can rewrite the whole lower layer to use it and elide the GCL
sources. I know it can be done, I just haven't had the time yet.

\start
Date: 28 Jun 2004 11:34:58 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] GCL version in Axiom CVS

Greetings!

Mike Thomas writes:

> Hi David.
> 
> | This might pinpoint an issue with GCL. Axiom is using its own version of
> | GCL (2.6.2-something)
> 
> For the record, as a completely separate issue and without hindering the
> point of your email to Magnus note that in fact, although labelled 2.6.2 in
> the Axiom CVS source tree, I believe that this is in fact GCL CVS HEAD based
> on the debugging output from "o/unexnt.c" when built under Windows.
> 

Yes, apart from the discussion on gcl bundling, if it would suit
Axiom's needs I'd like to recommend that the just released official
2.6.2 source be used if possible.  This will allow people to work
heavily on cvs head without worrying that an important user like axiom
would find the need to do a gcl cvs upgrade and be disappointed with
the results :-).

\start
Date: Mon, 28 Jun 2004 12:25:48 -0400
From: Tim Daly
To: Bill Page
Subject: Re: indefinites

> On Saturday, June 26, 2004 11:56 PM William Sit
> William Sit wrote:
> > 
> > Bill Page wrote:
> > > On Thursday, June 24, 2004 2:49 PM you Tim wrote:
> > > >
> > > > The distinction between Integer and Indefinite Integer is quite 
> > > > subtle.
> > > ...
> > However, there should be no disagreement that the two
> > mathematically are equivalent (that is, both obey the same 
> > rules operating on integers) but computationally different.
> >
> 
> I think we need to define more clearly what you mean by
> "mathematically equivalent" and "computationally different",
> but I don't think that I can agree that they are mathematically
> equivalent
.....[snip].....

Integer (INT) and Indefinite(Integer) INDEF(INT) are not categorically
equivalent.  Nor are they computationally equivalent. The algorithms
for working with INDEF(INT) need to work at a symbolic level so that
it knows that given x::INDEF(INT) and y::INDEF(INT) then
(x + y) = (y + x)

The subtle part that I mentioned is (given the subtle nature) harder
to explain. It turns out that the idea of an Indefinite(Integer) 
interacts strongly with another idea called Provisos (a limited
example of which is Maxima and Maple's assume facility).

For example, if we look at manipulating equations that contain only
INTs and INDEF(INT)s we can see the interaction. Suppose we have

 1*x = y*x

and we wish to divide both sides by 'x':

  1*x   y*x
  --- = ---
   x     x

should this be written

  1*x   y*x
  --- = ---   provided [x != 0]
   x     x

but clearly the equation is true even if 'x' is zero. How is the
divide operator supposed to know this? Clearly it can't so the
divide operator has to 'decorate' the result with the Proviso that
[x != 0] for both sides of the equation. However the higher level
operator ('equation divide') knows enough to elide the Proviso.
Or does it? EquationDivide might be able to make this conclusion
over the Integers but what if there are multiple zero-divisors?
Suppose the domain allows a provision that [x^p != 0] when 
dividing both sides of an equation? Can the equation-level divide
conclude that this is true for all x^p? What happens if 'x' is a
Indefinite(Polynomial(Integer)) or Polynomial(Indefinite(Integer))?

Indefinites and Provisos are intimately linked. The mathematics
of Provisos and its interaction with Indefinites, especially when
they are contained in both the equations and the Provisos is a
very subtle topic. 

Provisos, in general, are a hard topic. I've done some unpublished
research on this topic (which I'll try to scrape together and put on
this list so we can review the issues). Many of the manipulations
of Indefinites rely on Provisos for correctness.

Fateman's paper on matricies and Davenport's paper on indefinites
are worth a read.

\start
Date: 28 Jun 2004 11:39:12 -0400
From: Camm Maguire
To: David Mentre
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Greetings!

David Mentre writes:

> Magnus Larsson writes:
> 
> > This does not work:
> > I can still not build Axiom CVS 040624 on my original system using gcc-3.3.1, 
> > gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I might have trashed 
> > something on this system, but I am not aware of any seroius malconfiguration.
> > (CVS 5-june-2004 does build on this system)
> > The Binutils version is the only difference I can pinpoint right now.
> 

OK, I'm missing the head of the thread so far, but first off, axiom
will not build with gcl in ANSI mode due at the very least to the
in-package issue.  GCL will support both CLtL1 and ANSI modes going
forward.  Hopefully this will be considered a strong feature of GCL
given all the historical high quality work done under the earlier
dialect. 

Magnus, are you using the gcl in the axiom source tree?  If so, I
believe you and I have incorporated openbsd changes which are not in
this version yet (but are in the latest 2.6.2 release).  I take it
this is an openbsd build.  Or is this SuSE?

Take care,

> This might pinpoint an issue with GCL. Axiom is using its own version of
> GCL (2.6.2-something) but there might be an issue with this release of
> GCL and the releases of binutils and other utilities on your system.

\start
Date: Mon, 28 Jun 2004 12:27:53 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] GCL version in Axiom CVS
Cc: Mike Thomas

ok. I'll download the latest cvs image. I presume that 

cvs -d:ext:anoncvs@savannah.nongnu.org:/projects/gcl co gcl 

will get the version you want me to use?

\start
Date: 28 Jun 2004 11:54:47 -0400
From: Camm Maguire
To: Magnus Larsson
Subject: Re: [Gcl-devel] re: Axiom-developer post from Magnus Larsson requires approvalHello

Greetings!

OK, so this problem is SuSE, not openbsd, right?

Magnus, if I recall, there was a memory fault detected in compiling
apply.lisp.  To go further, one needs to configure whatever gcl one is
using with --enable-debug, rebuild, and run the command compiling
apply.lisp in gdb.  Then report a backtrace with bt from the fault
location. I don't know at what stage this file is compiled.  If in
bootsys, I think a simple (compile-file...) should do.  If in
interpsys, )co APPLY is likely.  Try to replicate exactly what the
Makefile is doing.

Just a double check here -- gcl 2.6.2 and later (check the dates and
logs of cvs snapshots please) has automatic support for the
'randomized sbrk' 'security feature' of some distros' newer
kernels. If this is the issue, you should see 'randomized sbrk'
detected and reported in the configure stage.  This appears unlikely
in your case, but just checking.

Take care,

Magnus Larsson writes:

> Hello Tim,
> 
> Yes, SUSE 9.1 can be downloaded from
> http://www.suse.com/us/private/download/ftp/int_mirrors.html
> Instruction:
> http://www.suse.com/us/private/download/suse_linux/index.html
> 
> SUSE relies on a two step process with a boot CD followed by a network 
> install. I have not tried this. 
> 
> Best regards,
> 
> Magnus L
> ======================
> Installation Guideline:
> This SUSE Linux 9.1 installation tree is suitable for installation via ftp,
> http, nfs, smb or hard disk.
> 
> System requirements
> 
>   You need at least 96MB main memory. To install on a machine with less
>   memory a (linux) swap partition is necessary.
> 
> Preparation
> 
>   o booting from CD
> 
>     Download the iso image boot/boot.iso and burn a CD with it.
> 
>   o booting from floppy
> 
>     Download the floppy disk image boot/bootdisk as well as the module disk
>     image files you need (at least boot/modules1 and likely the network
>     modules from boot/modules3).
> 
>     Write the images to floppy disks using the 'dd' command:
> 
>       dd if=[path_to_image] of=/dev/fd0 bs=36b
> 
>     On non-linux systems, use the rawrite utility from the dosutils/rawrite
>     directory (rawrite.exe).
> 
> Installation
> 
>   Boot from CD/floppy and at the bootpromt enter the installation source:
> 
>     linux install=ftp://ftp_server/directory
> 
>   Remember to substitute 'ftp_server' and 'directory' with the appropriate
>   values (e.g. install=ftp://[IP-ADDRESS]/pub/suse/i386/9.1 if you're
>   installing from the SUSE ftp server).
>   
>   Alternatively, choose 'manual installation' and configure the network in
>   the installation program.
> 
> 
> Preparing your own installation server
> 
>   Just copy the whole installation tree to your local disk and make it
>   available via network.
> 
> 
> 
>   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>   !!!!                  IMPORTANT NOTE                              !!!!!
>   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
>   If you get errors such as "No installation media found on server" or
>   "Package foo.rpm does not exist" it most likely means that
>         a) The ftp/http server you are using is not accepting new
>            connections.
>         b) You've misconfigured the local network or proxy settings
>   In either case, please don't contact ftpadmin about this since
>   we can't fix your network and/or have no control over how busy the
>   ftp servers are.
> 
> On Sunday 27 June 2004 23.14, root wrote:
> > so much for that idea.
> > i'm still puzzled about why it fails.
> > the code is straight common lisp.
> > is there someplace to download your version of SUSE?

\start
Date: 28 Jun 2004 12:15:44 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] GCL version in Axiom CVS
Cc: Mike Thomas

Greetings, and thanks!

Tim Daly writes:

> ok. I'll download the latest cvs image. I presume that 
> 
> cvs -d:ext:anoncvs@savannah.nongnu.org:/projects/gcl co gcl 
> 
> will get the version you want me to use?
> 

cvs -d:ext:anoncvs@savannah.nongnu.org:/projects/gcl co -r \
Version_2_6_2 gcl 

should do the trick.  The command you posted would take a snapshot of
the latest development version. the 'stable' 2.6.2 is specifically
designed to support maxima, acl2, and axiom while we try to make gcl
cvs head ansi compliant.

\start
Date: Mon, 28 Jun 2004 13:12:31 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] GCL version in Axiom CVS
Cc: Mike Thomas

Camm,

will the ansi compliant version handle ltk? 
(http://www.peter-herth.de/ltk)

I tried to run it but it fails. I'm unsure why as I got interrupted
shortly after I started playing with it and haven't touched it since.

The sweet part about this work is that it is all common lisp except
for one function that runs a program and captures the i/o stream.
I believe GCL has that function somewhere. 

\start
Date: Mon, 28 Jun 2004 13:17:16 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] GCL version in Axiom CVS
Cc: Mike Thomas

Camm, all I get is:

cvs -d:ext:anoncvs@savannah.nongnu.org:/projects/gcl co -r Version_2_6_2 gcl 

cvs [checkout aborted]: end of file from server (consult above messages if any)

\start
Date: 28 Jun 2004 12:55:10 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] GCL version in Axiom CVS
Cc: Mike Thomas

Greetings!

Tim Daly writes:

> Camm, all I get is:
> 
> cvs -d:ext:anoncvs@savannah.nongnu.org:/projects/gcl co -r
> Version_2_6_2 gcl 


Sorry -- its:
cvs -d:ext:anoncvs@subversions.gnu.org:/cvsroot/gcl co -r Version_2_6_2 gcl 

\start
Date: 28 Jun 2004 18:34:07 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Build Axiom on MacosX Panther 10.3.4
Cc: Jonathan Aidan

Greetings!

Yes, axiom/gcl works on macosx natively compiled.  I also believe the
debian powerpc binary might work via the Fink mechanism.  The man to
contact is Aurelien on the gcl-devel list.

Take care,

Tim Daly writes:

> Unfortunately Unix (BSD, Apple) and Linux are not the same thing.
> I don't have access to either kind of system so I'm unable to work
> on the porting issues (although someone just offered FreeBSD access). 
> 
> I believe that debian has a port of axiom that might run on
> apple. Please check the debian site.
> 
> It is a long term plan to support these systems but, of course,
> it will take work.
> 
> Tim
> 
> 
> ================================================================
> 
> I m really a newbie in UNIX world. I interested in Axiom for
> mathematical purposes. I have tried to build axiom from the CVS
> distribution but i don t succeded. I have installed the X11 package
> from Apple. The first problem i encounter was the SIGCLD/SIGCHLD
> problem in the fnct_key.h file that i fix. But there are many more
> problems... MacosX is build on Darwin, itself build on a BSD
> distribution.

\start
Date: 28 Jun 2004 18:32:30 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Greetings!

First of all, regarding the general question of whether gcl source
should be bundled with axiom, I personally feel that whatever Tim
feels is best should prevail here.  

There seem to be a few misconceptions about what can be achieved with
a generic non-source gcl installation however.  I thought I'd clarify
these in case the bundling decision might pivot around them.

Tim Daly writes:

> >  - it is possible to build Axiom with an external GCL. In fact, Camm
> >    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
> >    and other software, is doing exactly that for the axiom debian
> >    package. I don't know however if the machinery has been included in
> >    current sources of Axiom.
> 
> that's not strictly correct. Axiom will not fully run on an external GCL.
> depending on what you are doing it will fail. in particular, axiom adds
> special socket handling code to GCL which will be used by the newly added
> graph capabilities. further, axiom has special build-time flags (documented
> in the top level Makefile) that need to be set to your particular version
> of GCL. If you are not using the same version that is included with the
> Axiom CVS you need to change these flags and rebuild your local version.

I believe that every GCL patch/add-on currently utilized by axiom can
be incorporated without reference to the gcl source, rather simply
having gcl installed in binary form.

To link in C code from C source, one can

1) Put (clines ".....") in a .lsp file, add any lisp interfaces needed
   with (defentry...), compile-file, load, and save-system.

or

2) (compiler::link '("compiled_lisp_modules.o" "if_any.o") "new_image"
   "any_interpreted_init_code_to_be_run_in_the_new_image" "c_module.o
   -lclib.a")

   This also works for dynamic, shared libraries.  The resulting
   new_image will link against any such named in the command above via
   the system's linker loader "ld.so" at runtime.  Check it out with
   ldd. 

Most of the other items if I recall can be effected by setting special
compiler variables (e.g. suppressing warnings and the like).  If we
are deficient in this area and you wish to pursue this, please let me
know.  I want GCL to be as useful to axiom as possible.

> 
> in addition to sockets Axiom is adding code to do machine-level numeric
> support. i have a local version (not yet documented, tested, and checked in)
> which contains support for BLAS (Basic Linear Algebra Subroutines). These
> are built into the GCL image at system build time. Axiom's numerics will
> depend on these routines as well as additional routines that are in the
> queue to add. There has been some discussion about pushing the numerics
> support into GCL as Camm is also the BLAS maintainer. Since Axiom is
> currently the only user it is not clear that GCL wants or needs them.
> 

Here again, you can take your friendly external gcl, run a
compiler::link, and voila, you have your new image.  I hope shortly to
make this even easier.

What's more, if you use -lblas -lg2c in compiler::link, rather that
...libblas.a, you will dynamically link against blas, and I can
guarantee you transparent speedups of a factor of 5 to 10 depending on
the running cpu without recompilation!

> A third package is also in my local version that is going to be added
> which requires GCL changes. I've been working with ltk. This is a 
> lisp TK toolkit that runs on almost every lisp (except, it seems, GCL).
> The current GCL/TK package is broken as far as I can tell. I can get it
> to work but it promptly crashes. We're working on a new Axiom GUI to

I'd be very grateful for a reproducible example so I can fix it :-).

> replace the lost techexplorer and it is being developed using TCL/TK.
> Since the current GCL/TK doesn't work and ltk is almost all native
> common lisp we're going to use it going forward. Hopefully once it
> runs I can convince Camm to support it also but, again, since Axiom is
> the only user it is not clear that it is worth adding it to GCL.
> 

We'd like to support everything, but I feel we have a scalability
problem with the conventional scenario in which lisp add-ons are
linked in.  I.e. special build options or patches/forks for every
xgcl, blasgcl, mpigcl, blasmpixgcl, etc. would rightly appear quite
ludicrous to one used to C development.  GCL is primarily a compiler
and runtime 'libc' -- one should be able to just grab it and compile
whatever code linking against whatever externally supplied libraries
one wants to.  This is clearly a much more modular approach.  And I
don't think we are that far away.  We can doubtlessly make things
easier -- this is something I'd like to work on.

> so it is unlikely, going forward, that Axiom will run on your installed
> version of GCL.
> 

\start
Date: 28 Jun 2004 18:54:31 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom & internal/external GCL (was: Re: [Axiom-developer]Axiomcvs 040624 build error)
Cc: Bill Page

Greetings!

Tim Daly writes:

> > > I think, we should unbundle gcl and other additional
> > > software. To get Axiom running and some gcl interactions 
> > > resolved, it was certainly ok to pack everything together in 
> > > the beginning. But these problems should be solved now. Most 
> > > package systems (debian, BSDs etc) expect that the lisp 
> > > system and other packages are separate. Besides it will
> > > make Axiom much easier to port to other platforms. The
> > > technical details of loading C code have already been
> > > adressed in Camm's mails. 
> > 
> > I agree with this. It is normal practice for complex systems
> > like Axiom to specify dependencies. After all, GCL depends
> > intimately on GCC and binutils but we do not include a copy
> > of these in the Axiom installation. What is needed is simply
> > to document the known dependencies and to modify the Axiom
> > build to make patching GCL (and noweb) unnecessary.
> > 
> > Regarding ports to other systems, we are already doing this
> > in the case of the port to Windows.
> 
> Well, as they say, advocacy is volunteering. :-)
> 

Just another thought here.  I agree that ultimately it would be ideal
to have this image linking stage isolated and made generic for future
use with other lisps.  I just wanted to indicate that I don't think
both steps (e.g. build in Makefile rules to use external gcl and make
a generic external lisp interface) need happen at the same time.  The
first is quite easy, and if it were determined that it would provide
value, could be accomplished in short order.  I'd volunteer to commit
the necessary changes to the Makefile.pamphlets, should you wish.  It
can be argued that this is a low priority item gaining us nothing in
the near term, and I can respect this point of view.  But I fear we
will truly stretch our already meager developer resources too thin
should we simultaneously work on different compilers, at least at this
stage.  I'm just imagining in my C projects using gcc, and icc, then
the sgi compiler ....  If GCL is holding axiom back on any front, that
is another matter of course -- axiom should use the best tool for the
job.   I would greatly appreciate any reports on GCL deficiencies vis
a vis axiom should this be the case so we can address them.

\start
Date: Mon, 28 Jun 2004 19:41:35 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom & internal/external GCL (was: Re: Axiom cvs 040624 build error)

Camm,

> I believe that every GCL patch/add-on currently utilized by axiom can
> be incorporated without reference to the gcl source, rather simply
> having gcl installed in binary form.

I'm sure it's possible, in fact I'm certain it is possible. 
What it implies is that somebody (likely me) will have to take the
various C routines that Axiom depends upon, code some lisp above
them to talk to GCL, rework the Makefiles to compile and add the
routines at the appropriate build time, and document the process. 

I think this is the correct and elegant path to take.

However, to be truly elegant, it should be the case that the same
approach (not the same code) should be generic enough to work in
several lisps, in particular, for GCL, CCL, and CMUCL. 

Since the lisp is working at the moment and things like graphics
are not I don't have the cycles to go back and figure out a general
mechanism. When I get back to porting issues at the lisp level I'm
certain to take a whack at this problem as it is clearly a "community
issue" and my design choice is crimethink.

It may even get solved "looking forward" as I've done some work with
axiom's numerics and want to figure out a general mechanism to include
BLAS, LAPACK, QUADPACK, etc. Clearly I'd be foolish to link them into
the image at compile time.

The issue is time and learning, not intransigence.

If someone is willing to strip out Axiom's C routines, write them up
as a dynamically linkable .lsp file (in isolation, without the rest of
axiom) and send them to me I'll struggle with the rest of the tasks.

\start
Date: 28 Jun 2004 19:11:57 -0400
From: Camm Maguire
To: Martin Rubey
Subject: Re: [Gcl-devel] Re: Patches
Cc: Manuel Bronstein

Greetings!

Martin Rubey writes:

> Camm Maguire writes:
>  > Greetings!
>  > 
>  > Martin Rubey writes:
>  > 
>  > > Dear Prof. Bronstein,
>  > > 
>  > > thanks a lot for your answer!
>  > > 
>  > > Manuel Bronstein writes:
>  > >  > - new()$Symbol is working properly in the NAG version, so 9298 is
>  > >  >   probably a lisp problem.
>  > > 
>  > > Good. I remember that somebody was building axiom on cmucl -- I think it was 
>  > > Juergen Weiss. Could he try to reproduce bug #9298 on cmucl? Camm Muguire (GCL)
>  > > already offered to track down the bug:
>  > > 
>  > > Camm Maguire wrote:
>  > >  > 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.
>  > > 
>  > > However, I don't know how to "boil it down" :-(
>  > > 
>  > 
>  > OK, I'm afraid I've lost the thread.  If you could please give me the
>  > commands you are using in axiom, what the result is, and what you
>  > think it should be, in of course as simple an example as you can, I'll
>  > be happy to take a look.
> 
> Here you go:
> 
>                         AXIOM Computer Algebra System 
>                Version of Wednesday June 9, 2004 at 15:38:25 
> -----------------------------------------------------------------------------
>    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) -> %A::Symbol
> 
>    (1)  %A
>                                                                  Type: Symbol
> (2) -> new()$Symbol
> 
>    (2)  %A
>                                                                  Type: Symbol

OK, I've had a brief look at this, and from what I can see thus far,
|SYMBOL;new;$;27| in SYMBOL.lsp is not being called in the former
case, but is in the latter, as is proper.  This function increments an
element in the symbol constructor vector to keep track of which
symbols it has interned/generated:

(SPADCALL (QREFELT |$| 9) (|+| (SPADCALL (QREFELT |$| 9) (QREFELT |$| 90)) 1) 
(QREFELT |$| 91))

I can only find references to this ninth element in |SYMBOL;new;2$;28|
and |SYMBOL;resetNew;V;29| of the same file.  I think the former is
the one that should be invoked but is not for some reason.  

This is all just preliminary, but I wanted to ask -- is the adjustment
to the constructor vector supposed to happen at the same time the
symbol is interned?  Any idea of a generic place to look for updates
to this vector?


Some lisp debugging info in case it triggers anything: 


Lisp backtraces set at |Symbol|:

#0   BREAK {loc0="Symbol",loc1=((system::arglist nil)),loc2=nil,loc3=nil,loc4=((cons (quote...} [ihs=41]
#1   Symbol {} [ihs=40]
#2   TRACE-CALL {} [ihs=39]
#3   Symbol {} [ihs=38]
#4   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block |Symbol| (&rest system::args) ......} [ihs=37]
#5   TRACE-CALL {} [ihs=36]
#6   evalDomain {(|Symbol|)=nil,} [ihs=35]
#7   coerceByFunction {|OutputForm|=nil,} [ihs=27]
#8   TRACE-CALL {} [ihs=26]
#9   coerceByFunction {((|Symbol|) wrapped . %s)=(|OutputForm|),} [ihs=25]
#10   coerceIntTableOrFunction {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|),loc2=((|Symbol|) wrapped . %...} [ihs=24]
#11   coerceIntTower {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|)} [ihs=23]
#12   coerceInt1 {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|),loc2=#:g1443,loc3=((wrapped ...} [ihs=22]
#13   coerceInt {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|),loc2=nil,loc3=((|isWrapped| ...} [ihs=21]
#14   coerceInt0 {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|)} [ihs ]
#15   coerceInteractive {loc0=((|Symbol|) wrapped . %s),loc1=(|OutputForm|),loc2=((system::args (%s #)))} [ihs=19]
#16   output {expr=%s,domain=(|Symbol|),loc2=((system::trace-call (quote #:g1458) system::arg...} [ihs=18]
#17   recordAndPrint {loc0=%s,loc1=(|Symbol|),loc2=((system::args (#)))} [ihs=17]
#18   processInteractive1 {loc0=(|::| %s symbol),loc1=(|Coerceto| ((|id| #) . %s) ((|id| #) . symbol)),loc...} [ihs=16]
#19   processInteractive {loc0=(|::| %s symbol),loc1=(|Coerceto| ((|id| #) . %s) ((|id| #) . symbol)),loc...} [ihs=15]
#20   intInterpretPform {loc0=(|Coerceto| ((|id| #) . %s) ((|id| #) . symbol))} [ihs=14]
#21   ncConversationPhase {fn=#<compiled-function |phInterpret|>,args=(((|carrier| # # ...))),loc2=(((# . ...} [ihs=13]
#22   intloopSpadProcess,interp {loc0=((|carrier| (|ok?| . t) (|ptreePremacro| . #0=(|Coerceto| # #)) ...)),loc1...} [ihs=12]
#23   intloopSpadProcess {loc0=10,loc1=(((# . 1) . "%S::SYMBOL")),loc2=(|Coerceto| ((|id| #) . %s) ((|id|...} [ihs=11]
#24   intloopProcess {loc0=10,loc1=t,loc2=(((#) (|Coerceto| # #)) |nonnullstream| #<compiled-function...} [ihs=10]
#25   intloopProcessString {loc0="%S::SYMBOL",loc1=10} [ihs=9]
#26   intloopReadConsole {loc0="",loc1=1,loc2="",loc3="%S::SYMBOL",loc4=nil} [ihs=8]
#27   SpadInterpretStream {loc0=1,loc1=(tim daly ?),loc2=t,loc3=nil,loc4=nil,loc5=string-char,loc6=string-...} [ihs=7]
#28   RESTART {} [ihs=6]
#29   TOP-LEVEL {loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="/fix/k/camm/gc...} [ihs=5]
#30   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL


vs 

#0   BREAK {loc0="Symbol",loc1=((system::arglist nil)),loc2=nil,loc3=nil,loc4=((cons (quote...} [ihs=30]
#1   Symbol {} [ihs=29]
#2   TRACE-CALL {} [ihs=28]
#3   Symbol {} [ihs=27]
#4   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block |Symbol| (&rest system::args) ......} [ihs=26]
#5   evalDomain {loc0=(|Symbol|),loc1=(|Symbol|),loc2=(|Symbol|)} [ihs=25]
#6   evalForm {loc0=#<vector 08d40604>,loc1=|new|,loc2=nil,loc3=(((#0=# #0#) ($) nil)),loc4=|m...} [ihs=24]
#7   bottomUpForm2 {loc0=(#<vector 08d40604>),loc1=#<vector 08d40604>,loc2=|new|,loc3=nil,loc4=nil,...} [ihs=23]
#8   bottomUpForm3 {loc0=(#<vector 08d40604>),loc1=#<vector 08d40604>,loc2=|new|,loc3=nil,loc4=nil,...} [ihs=22]
#9   bottomUpForm {loc0=(#<vector 08d40604>),loc1=#<vector 08d40604>,loc2=|new|,loc3=nil,loc4=nil} [ihs=21]
#10   bottomUp {loc0=(#<vector 08d40604>),loc1=0} [ihs ]
#11   upDollar {loc0=(#<vector 08d405e8> |Symbol| (#<vector 08d40604>)),loc1=0} [ihs=19]
#12   bottomUp {loc0=(#<vector 08d405e8> |Symbol| (#<vector 08d40604>)),loc1=(#<vector 08d405e8...} [ihs=18]
#13   interpret1 {loc0=((|$elt| |Symbol| |new|)),loc1=nil,loc2=(|Application| (|Fromdom| (# . |ne...} [ihs=17]
#14   interpret {g3899=((|$elt| |Symbol| |new|)),loc1=(|Application| (|Fromdom| (# . |new|) (# ....} [ihs=16]
#15   interpretTopLevel {loc0=((|$elt| |Symbol| |new|)),loc1=(|Application| (|Fromdom| (# . |new|) (# . ...} [ihs=15]
#16   processInteractive1 {loc0=((|$elt| |Symbol| |new|)),loc1=(|Application| (|Fromdom| (# . |new|) (# . ...} [ihs=14]
#17   processInteractive {loc0=((|$elt| |Symbol| |new|)),loc1=(|Application| (|Fromdom| (# . |new|) (# . ...} [ihs=13]
#18   intInterpretPform {loc0=(|Application| (|Fromdom| (# . |new|) (# . |Symbol|)) (|Tuple| (|listOf|))...} [ihs=12]
#19   ncConversationPhase {fn=#<compiled-function |phInterpret|>,args=(((|carrier| # # ...))),loc2=(((# . ...} [ihs=11]
#20   intloopSpadProcess,interp {loc0=((|carrier| (|ok?| . t) (|ptreePremacro| . #0=(|Application| # #)) ...)),l...} [ihs=10]
#21   intloopSpadProcess {loc0=7,loc1=(((# . 1) . "new()$Symbol")),loc2=(|Application| (|Fromdom| (# . |n...} [ihs=9]
#22   intloopProcess {loc0=7,loc1=t,loc2=(((#) (|Application| # #)) |nonnullstream| #<compiled-functi...} [ihs=8]
#23   intloopProcessString {loc0="new()$Symbol",loc1=7} [ihs=7]
#24   RESTART {} [ihs=6]
#25   TOP-LEVEL {loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="/fix/k/camm/gc...} [ihs=5]
#26   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL


and the constructor itself:

)lisp (dotimes (i (length foo)) (format t "~S ~S~%" i (aref foo i)))
0 (|Symbol|)
1 (#<compiled-function |lookupComplete|> #<vector 08e04230> #<vector 08dbab98>)
2 NIL
3 0
4 (#<vector 08e0424c> #<vector 08dbab60> . #<vector 08dbaaf0>)
5 NIL
6 #<vector 08e04268>
7 #<vector 08e042a0>
8 (#<compiled-function |REF;ref;S$;2|> . #<vector 08e042a0>)
9 (3)
10 #<vector 08e042f4>
11 (#<compiled-function |ALIST;empty;$;2|> . #<vector 08e042f4>)
12 (NIL)
13 (|List| 28)
14 #<vector 08e0463c>
15 (#<compiled-function |A1AGG-;construct;LA;21|> . #<vector 08e04674>)
16 #<vector 08e046ac>
17 "0123456789"
18 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
19 "abcdefghijklmnopqrstuvwxyz"
20 (|Boolean|)
21 (#<compiled-function |SYMBOL;scripted?;$B;30|> . #<vector 08e04230>)
22 (|Void|)
23 (|Symbol|)
24 (|OpenMathDevice|)
25 (|newGoGet| #<vector 08e04230> 14 . |OMputVariable|)
26 (|OpenMathEncoding|)
27 (|newGoGet| #<vector 08e04230> 20 . |OMencodingXML|)
28 #<vector 08e04498>
29 (|newGoGet| #<vector 08e04230> 24 . |OMopenString|)
30 (|newGoGet| #<vector 08e04230> 30 . |OMputObject|)
31 (|newGoGet| #<vector 08e04230> 35 . |OMputEndObject|)
32 (|newGoGet| #<vector 08e04230> 40 . |OMclose|)
33 (#<compiled-function |SYMBOL;OMwrite;$S;2|> . #<vector 08e04230>)
34 (#<compiled-function |SYMBOL;OMwrite;$BS;3|> . #<vector 08e04230>)
35 (#<compiled-function |SYMBOL;OMwrite;Omd$V;4|> . #<vector 08e04230>)
36 (#<compiled-function |SYMBOL;OMwrite;Omd$BV;5|> . #<vector 08e04230>)
37 "*"
38 1
39 #<vector 08e044b4>
40 (#<compiled-function |CHAR;char;S$;20|> . #<vector 08e044b4>)
41 (#<compiled-function |CHAR;ord;$I;7|> . #<vector 08e044b4>)
42 48
43 (|InputForm|)
44 (|newGoGet| #<vector 08e04230> 55 . |convert|)
45 (#<compiled-function |SYMBOL;convert;$If;6|> . #<vector 08e04230>)
46 (#<compiled-function |SYMBOL;convert;2$;7|> . #<vector 08e04230>)
47 (#<compiled-function |SYMBOL;coerce;S$;8|> . #<vector 08e04230>)
48 (#<compiled-function |SYMBOL;=;2$B;9|> . #<vector 08e04230>)
49 (#<compiled-function |SYMBOL;<;2$B;10|> . #<vector 08e04230>)
50 #<vector 08e04524>
51 (#<compiled-function |OUTFORM;outputForm;S$;8|> . #<vector 08e04524>)
52 (#<compiled-function |SYMBOL;coerce;$Of;11|> . #<vector 08e04230>)
53 (|List| 55)
54 (#<compiled-function |SYMBOL;script;$L$;22|> . #<vector 08e04230>)
55 (|List| 50)
56 (#<compiled-function |SYMBOL;subscript;$L$;12|> . #<vector 08e04230>)
57 (#<compiled-function |SYMBOL;elt;$L$;13|> . #<vector 08e04230>)
58 (#<compiled-function |SYMBOL;superscript;$L$;14|> . #<vector 08e04230>)
59 (#<compiled-function |SYMBOL;argscript;$L$;15|> . #<vector 08e04230>)
60 (|PatternMatchResult| 6 23)
61 (|Pattern| 6)
62 (|PatternMatchSymbol| 6)
63 (|newGoGet| #<vector 08e04230> 65 . |patternMatch|)
64 (|PatternMatchResult| 6 $)
65 (#<compiled-function |SYMBOL;patternMatch;$P2Pmr;16|> . #<vector 08e04230>)
66 (|PatternMatchResult| (|Float|) 23)
67 (|Pattern| (|Float|))
68 (|PatternMatchSymbol| (|Float|))
69 (|newGoGet| #<vector 08e04230> 72 . |patternMatch|)
70 (|PatternMatchResult| (|Float|) $)
71 (#<compiled-function |SYMBOL;patternMatch;$P2Pmr;17|> . #<vector 08e04230>)
72 (|newGoGet| #<vector 08e04230> 79 . |coerce|)
73 (#<compiled-function |SYMBOL;convert;$P;18|> . #<vector 08e04230>)
74 (|newGoGet| #<vector 08e04230> 84 . |coerce|)
75 (#<compiled-function |SYMBOL;convert;$P;19|> . #<vector 08e04230>)
76 (|List| $)
77 (|newGoGet| #<vector 08e04230> 89 . |concat|)
78 (|newGoGet| #<vector 08e04230> 94 . |concat|)
79 (|Record| (|:| |sub| 55) (|:| |sup| 55) (|:| |presup| 55) (|:| |presub| 55) (|:| |args| 55))
80 (#<compiled-function |SYMBOL;script;$R$;23|> . #<vector 08e04230>)
81 (#<compiled-function |SYMBOL;name;2$;31|> . #<vector 08e04230>)
82 (#<compiled-function |SYMBOL;string;$S;24|> . #<vector 08e04230>)
83 (#<compiled-function |ISTRING;elt;$IC;30|> . #<vector 08d40000>)
84 (|newGoGet| #<vector 08e04230> 106 . =)
85 (#<compiled-function |SYMBOL;scripts;$R;32|> . #<vector 08e04230>)
86 (|newGoGet| #<vector 08e04230> 112 . |latex|)
87 (#<compiled-function |SYMBOL;latex;$S;25|> . #<vector 08e04230>)
88 (#<compiled-function |ISTRING;minIndex;$I;11|> . #<vector 08d40000>)
89 (#<compiled-function |LNAGG-;concat;S2A;4|> . #<vector 08d40188>)
90 (#<compiled-function |REF;elt;$S;3|> . #<vector 08e042a0>)
91 (#<compiled-function |REF;setelt;$2S;4|> . #<vector 08e042a0>)
92 ((LAMBDA-BLOCK |SYMBOL;new;$;27| ($) (BREAK "new") (PROG (|sym|) (RETURN (SEQ (LETT |sym| (|SYMBOL;anyRadix| (SPADCALL (QREFELT $ 9) (QREFELT $ 90)) (QREFELT $ 18) $) |SYMBOL;new;$;27|) (SPADCALL (QREFELT $ 9) (+ (SPADCALL (QREFELT $ 9) (QREFELT $ 90)) 1) (QREFELT $ 91)) (EXIT (SPADCALL (STRCONC "%" |sym|) (QREFELT $ 47))))))) . #<vector 08e04230>)
93 (|Union| 6 (QUOTE "failed"))
94 (|newGoGet| #<vector 08e04230> 139 . |search|)
95 (|newGoGet| #<vector 08e04230> 145 . |setelt|)
96 (|newGoGet| #<vector 08e04230> 152 . |maxIndex|)
97 (|newGoGet| #<vector 08e04230> 157 . |position|)
98 (#<compiled-function |SYMBOL;new;2$;28|> . #<vector 08e04230>)
99 (|List| $$)
100 (|newGoGet| #<vector 08e04230> 163 . |keys|)
101 (|newGoGet| #<vector 08e04230> 168 . |remove!|)
102 (|newGoGet| #<vector 08e04230> 174 . |void|)
103 (#<compiled-function |SYMBOL;resetNew;V;29|> . #<vector 08e04230>)
104 (#<compiled-function |SYMBOL;list;$L;34|> . #<vector 08e04230>)
105 (|newGoGet| #<vector 08e04230> 178 . |first|)
106 (|newGoGet| #<vector 08e04230> 183 . |digit?|)
107 (|UniversalSegment| 6)
108 (|newGoGet| #<vector 08e04230> 188 . SEGMENT)
109 (|newGoGet| #<vector 08e04230> 194 . |elt|)
110 (|List| 112)
111 (|newGoGet| #<vector 08e04230> 200 . |minIndex|)
112 (|NonNegativeInteger|)
113 (|newGoGet| #<vector 08e04230> 205 . |setelt|)
114 (|newGoGet| #<vector 08e04230> 212 . |concat|)
115 (|newGoGet| #<vector 08e04230> 218 . |rest|)
116 (|newGoGet| #<vector 08e04230> 223 . |minIndex|)
117 (|newGoGet| #<vector 08e04230> 228 . |#|)
118 (|newGoGet| #<vector 08e04230> 233 . |first|)
119 (|newGoGet| #<vector 08e04230> 239 . |setelt|)
120 (|newGoGet| #<vector 08e04230> 246 . |rest|)
121 (|newGoGet| #<vector 08e04230> 252 . |elt|)
122 (|makeSpadConstant| #<compiled-function |SYMBOL;sample;$;35|> #<vector 08e04230> 122)
123 (|SingleInteger|)
Value = NIL


Take care,



> (3) -> G1419::SYMBOL
> 
> 
>    (3)  G1419
>                                                                  Type: Symbol
> (4) -> symbol(GENSYM()$Lisp)
>    Loading /home/rubey/axiom/mnt/linux/algebra/SEX.o for domain 
>       SExpression 
>    Loading /home/rubey/axiom/mnt/linux/algebra/DFLOAT.o for domain 
>       DoubleFloat 
>    Loading /home/rubey/axiom/mnt/linux/algebra/SEXOF.o for domain 
>       SExpressionOf 
> 
>    (4)  G1419
>                                                                  Type: Symbol
> 
> (5) -> b:=%B
> 
>    (5)  %B
>                                                             Type: Variable %B
> (6) -> new()$Symbol
> 
>    (6)  %B
> 
>  
> The problem seems to be, that somehow the lisp doesn't realize that the symbols
> are already around.
> 
> Would be great...

\start
Date: Tue, 29 Jun 2004 01:37:14 -0400
From: Tim Daly
To: list
Subject: cvs

The CVS has been updated with the latest release of GCL.
All tests passed on this change.

\start
Date: Tue, 29 Jun 2004 19:35:59 +0200
From: Magnus Larsson
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Hello Camm Maguire,

On Monday 28 June 2004 17.39, Camm Maguire wrote:
> Greetings!
>
> David Mentre writes:
> > Magnus Larsson writes:
> > > This does not work:
> > > I can still not build Axiom CVS 040624 on my original system using
> > > gcc-3.3.1, gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I
> > > might have trashed something on this system, but I am not aware of any
> > > seroius malconfiguration. (CVS 5-june-2004 does build on this system)
> > > The Binutils version is the only difference I can pinpoint right now.
>
> OK, I'm missing the head of the thread so far, but first off, axiom
> will not build with gcl in ANSI mode due at the very least to the
> in-package issue.  GCL will support both CLtL1 and ANSI modes going
> forward.  Hopefully this will be considered a strong feature of GCL
> given all the historical high quality work done under the earlier
> dialect.
>
> Magnus, are you using the gcl in the axiom source tree?  If so, I
> believe you and I have incorporated openbsd changes which are not in
> this version yet (but are in the latest 2.6.2 release).  I take it
> this is an openbsd build.  Or is this SuSE?

Please disregard my gcl-2.7.0 ANSI statement. Yes, I have gcl-2.7.0 ANSI, but 
I did not know that AXIOM had gcl-2.6.2 (or similar) built in. (I use gcl for 
Maxima). 

I have tried three systems using 040624 CVS AXIOM code.

SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
http://linuxfromscratch.mirror.ac.uk/lfs/news.html

>
> Take care,
>
> > This might pinpoint an issue with GCL. Axiom is using its own version of
> > GCL (2.6.2-something) but there might be an issue with this release of
> > GCL and the releases of binutils and other utilities on your system.

\start
Date: 29 Jun 2004 14:32:06 -0400
From: Camm Maguire
To: Magnus Larsson
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Greetings!

Magnus Larsson writes:

> Hello Camm Maguire,
> 
> On Monday 28 June 2004 17.39, Camm Maguire wrote:
> > Greetings!
> >
> > David Mentre writes:
> > > Magnus Larsson writes:
> > > > This does not work:
> > > > I can still not build Axiom CVS 040624 on my original system using
> > > > gcc-3.3.1, gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I
> > > > might have trashed something on this system, but I am not aware of any
> > > > seroius malconfiguration. (CVS 5-june-2004 does build on this system)
> > > > The Binutils version is the only difference I can pinpoint right now.
> >
> > OK, I'm missing the head of the thread so far, but first off, axiom
> > will not build with gcl in ANSI mode due at the very least to the
> > in-package issue.  GCL will support both CLtL1 and ANSI modes going
> > forward.  Hopefully this will be considered a strong feature of GCL
> > given all the historical high quality work done under the earlier
> > dialect.
> >
> > Magnus, are you using the gcl in the axiom source tree?  If so, I
> > believe you and I have incorporated openbsd changes which are not in
> > this version yet (but are in the latest 2.6.2 release).  I take it
> > this is an openbsd build.  Or is this SuSE?
> 
> Please disregard my gcl-2.7.0 ANSI statement. Yes, I have gcl-2.7.0 ANSI, but 
> I did not know that AXIOM had gcl-2.6.2 (or similar) built in. (I use gcl for 
> Maxima). 
> 
> I have tried three systems using 040624 CVS AXIOM code.
> 
> SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> http://linuxfromscratch.mirror.ac.uk/lfs/news.html
> 

OK

1) Could you please report the full binutils versions?
2) Could you please point me to a build log showing the failure 
3) If you would like, please check si::*plt-table* on the failing
    systems, as well as configuring with --disable-statsysbfd
    --enable-custreloc 

BTW, how is axiom on openbsd?

Take care,

> >
> > Take care,
> >
> > > This might pinpoint an issue with GCL. Axiom is using its own version of
> > > GCL (2.6.2-something) but there might be an issue with this release of
> > > GCL and the releases of binutils and other utilities on your system.

\start
Date: Tue, 29 Jun 2004 21:16:12 +0200
From: Magnus Larsson
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Hello again Camm Maguire ,

> 1) Could you please report the full binutils versions?
SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
	Binutils 2.15.90.0.3 20040415
LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
	Binutils 2.14 20030612
LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
	Binutils 2.15.90.0.1.1 20040303 (Suse Linux)

> 2) Could you please point me to a build log showing the failure
>
I will email you a log separately. It gets bounced off the list since it is 
too big. Please find a snippet below.
.....
LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
The source 
file /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is 
not found.
9 
making /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o 
from /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
cp: cannot stat 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o': No 
such file or directory
make[3]: *** 
[/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o] 
Error 1
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom'
make: *** [all] Error 2

> 3) If you would like, please check si::*plt-table* on the failing
>     systems, as well as configuring with --disable-statsysbfd
>     --enable-custreloc

I am sorry. I do not understand your instruction. "..si::*plt-table* ..". This 
probably points out a serious limit in my Lisp, debugger, Unix knowledge, but 
it is true. I do not mind checking as per your instructions if you do not 
mind a few more details. (That could be a lot of work for you...)
Configure what? The Axiom build ./configure?

>
> BTW, how is axiom on openbsd?
>
> Take care,
>
> > > Take care,
> > >
> > > > This might pinpoint an issue with GCL. Axiom is using its own version
> > > > of GCL (2.6.2-something) but there might be an issue with this
> > > > release of GCL and the releases of binutils and other utilities on
> > > > your system.

\start
Date: 29 Jun 2004 17:00:09 -0400
From: Camm Maguire
To: Magnus Larsson
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Greetings!

Magnus Larsson writes:

> Hello again Camm Maguire ,
> 
> > 1) Could you please report the full binutils versions?
> SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> 	Binutils 2.15.90.0.3 20040415
> LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> 	Binutils 2.14 20030612
> LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> 	Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
> 
> > 2) Could you please point me to a build log showing the failure
> >
> I will email you a log separately. It gets bounced off the list since it is 
> too big. Please find a snippet below.
> .....

OK, got your file.  It is as you suspect almost certainly a binutils
issue.  I would need access to a machine with these binutils to make
sure and propose a fix.  Has it been officially released yet?  Debian
doesn't have it.

In the meantime, there is a high likelihood that you can work around
the difficulty  by configuring your gcl with --disable-statsysbfd
--enable-locbfd, or --disable-statsysbfd --enable-custreloc on i386
and sparc only.  GCL carries around its own copy of binutils for
convenience.   Tim can show you how to edit the Makefile.pamplets to
try this out.  Just search for --enable in lsp/Makefile.pamphlet,
choose the correct stanza, and edit.

Take care, 

> LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> The source 
> file /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is 
> not found.
> 9 
> making /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o 
> from /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
> cp: cannot stat 
> `/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o': No 
> such file or directory
> make[3]: *** 
> [/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o] 
> Error 1
> make[3]: Leaving directory 
> `/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
> make[2]: *** [interpdir] Error 2
> make[2]: Leaving directory 
> `/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom'
> make: *** [all] Error 2
> 
> > 3) If you would like, please check si::*plt-table* on the failing
> >     systems, as well as configuring with --disable-statsysbfd
> >     --enable-custreloc
> 
> I am sorry. I do not understand your instruction. "..si::*plt-table* ..". This 
> probably points out a serious limit in my Lisp, debugger, Unix knowledge, but 
> it is true. I do not mind checking as per your instructions if you do not 
> mind a few more details. (That could be a lot of work for you...)
> Configure what? The Axiom build ./configure?
> 
> >
> > BTW, how is axiom on openbsd?
> >
> > Take care,
> >
> > > > Take care,
> > > >
> > > > > This might pinpoint an issue with GCL. Axiom is using its own version
> > > > > of GCL (2.6.2-something) but there might be an issue with this
> > > > > release of GCL and the releases of binutils and other utilities on
> > > > > your system.

\start
Date: 29 Jun 2004 17:20:32 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: cvs

Thanks!

Tim Daly writes:

> The CVS has been updated with the latest release of GCL.
> All tests passed on this change.

\start
Date: Wed, 30 Jun 2004 01:05:44 +0200
From: Magnus Larsson
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Hello Camm Maguire,

On Tuesday 29 June 2004 23.00, Camm Maguire wrote:
> Greetings!
>
> Magnus Larsson writes:
> > Hello again Camm Maguire ,
> >
> > > 1) Could you please report the full binutils versions?
> >
> > SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> > 	Binutils 2.15.90.0.3 20040415
> > LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> > 	Binutils 2.14 20030612
> > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > 	Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
> >
> > > 2) Could you please point me to a build log showing the failure
> >
> > I will email you a log separately. It gets bounced off the list since it
> > is too big. Please find a snippet below.
> > .....
>
> OK, got your file.  It is as you suspect almost certainly a binutils
> issue.  I would need access to a machine with these binutils to make
> sure and propose a fix.  Has it been officially released yet?  Debian
> doesn't have it.

Yes, I think it is released, recently. Please refer to:
ftp://ftp.gnu.org/gnu/binutils/

However, both SUSE 9.1 (have) and Red Hat Fedora Core 2 (have not) relies on 
"beta" Binutils 2.15.90.x. http://fedora.redhat.com/projects/package-list/

>
> In the meantime, there is a high likelihood that you can work around
> the difficulty  by configuring your gcl with --disable-statsysbfd
> --enable-locbfd, or --disable-statsysbfd --enable-custreloc on i386
> and sparc only.  GCL carries around its own copy of binutils for
> convenience.   Tim can show you how to edit the Makefile.pamplets to
> try this out.  Just search for --enable in lsp/Makefile.pamphlet,
> choose the correct stanza, and edit.

Ok, I will try.

>
> Take care,
>
> > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > The source
> > file
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is
> > not found.
> > 9
> > making
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o
> > from
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
> > cp: cannot stat
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o'
> >: No such file or directory
> > make[3]: ***
> > [/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.
> >o] Error 1
> > make[3]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
> > make[2]: *** [interpdir] Error 2
> > make[2]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
> > make[1]: *** [srcdir] Error 2
> > make[1]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom' make: *** [all] Error 2
> >
> > > 3) If you would like, please check si::*plt-table* on the failing
> > >     systems, as well as configuring with --disable-statsysbfd
> > >     --enable-custreloc
> >
> > I am sorry. I do not understand your instruction. "..si::*plt-table* ..".
> > This probably points out a serious limit in my Lisp, debugger, Unix
> > knowledge, but it is true. I do not mind checking as per your
> > instructions if you do not mind a few more details. (That could be a lot
> > of work for you...) Configure what? The Axiom build ./configure?
> >
> > > BTW, how is axiom on openbsd?
> > >
> > > Take care,
> > >
> > > > > Take care,
> > > > >
> > > > > > This might pinpoint an issue with GCL. Axiom is using its own
> > > > > > version of GCL (2.6.2-something) but there might be an issue with
> > > > > > this release of GCL and the releases of binutils and other
> > > > > > utilities on your system.

\start
Date: Tue, 29 Jun 2004 20:30:52 -0400
From: Tim Daly
To: Magnus Larsson
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error
Cc: Camm Maguire

Magnus,

In the axiom source tree there is a Makefile.pamphlet in every
subdirectory.  That Makefile.pamphlet is automatically expanded into a
Makefile in the same directory.  The Makefile in each directory is
responsible for building all files in that directory and calling
Makefiles in all subdirectories. Thus the Makefiles form a
self-executing tree.

In order to change the build properties of GCL you need to know that
GCL gets expanded in the lsp subdirectory. So in order to change 
configuration options you need to modify the lsp/Makefile.pamphlet file.

The line you want to change should be lsp/Makefile.pamphlet line 266.
It currently reads:

	./configure --enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=128*1024 ; \

Modify this line to add any configuration options you want then rebuild the
system (assuming it lives in (/home/magnus/usr/src/axiom):

export AXIOM=/home/magnus/usr/src/axiom/mnt/linux
cd /home/magnus/usr/src/axiom
make clean
make

The "make clean" will remove all copies of GCL.
The "make" will notice that lsp/Makefile.pamphlet is changed and so
it will regenerate the lsp/Makefile with your configuration changes.
Then it will rebuild the lisp with your changes.

There are shorter ways to go about this but this is known to work.

Also, you should note that each Makefile.pamphlet is also expanded into
a Makefile.dvi. So if you look in the lsp subdirectory you can do

xdvi Makefile.dvi

and you'll see an explanation of the current configure options being used.
The explanation is in section 2.1.1 of the Makefile.dvi document.

Let me know if you need any other help.

\start
Date: Wed, 30 Jun 2004 10:11:11 +0200
From: Magnus Larsson
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Hello Camm Maguire,

I have tried the new gcl switches. They did not work for me.
Details below.

On Tuesday 29 June 2004 23.00, Camm Maguire wrote:
> Greetings!
>
> Magnus Larsson writes:
> > Hello again Camm Maguire ,
> >
> > > 1) Could you please report the full binutils versions?
> >
> > SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> > 	Binutils 2.15.90.0.3 20040415
> > LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> > 	Binutils 2.14 20030612
> > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > 	Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
> >
> > > 2) Could you please point me to a build log showing the failure
> >
> > I will email you a log separately. It gets bounced off the list since it
> > is too big. Please find a snippet below.
> > .....
>
> OK, got your file.  It is as you suspect almost certainly a binutils
> issue.  I would need access to a machine with these binutils to make
> sure and propose a fix.  Has it been officially released yet?  Debian
> doesn't have it.
>
> In the meantime, there is a high likelihood that you can work around
> the difficulty  by configuring your gcl with --disable-statsysbfd
> --enable-locbfd, or --disable-statsysbfd --enable-custreloc on i386
> and sparc only.  GCL carries around its own copy of binutils for
> convenience.   Tim can show you how to edit the Makefile.pamplets to
> try this out.  Just search for --enable in lsp/Makefile.pamphlet,
> choose the correct stanza, and edit.


using:
LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1)
Binutils 2.15.90.0.3 20040415 (This system is a bit experimental, but it is 
what I normally use for Maxima, Texmacs, Pari,..)
I will try the SUSE 9.1 distro later).

CVS Axiom checkout today, 30-June. I used Tim's instructions to patch 
lsp/Makefile.pamphlet line 266.

	./configure --enable-vssize=65536*2 --disable-statsysbfd 
=2D-enable-maxpage=128*1024 --enable-locbfd ; \
=> fails as before

	./configure --enable-vssize=65536*2 --disable-statsysbfd 
=2D-enable-maxpage=128*1024 --enable-custreloc ; \
=> fails as before

Btw, i mixed the Binutils up in the list i sent before. The correct list lokes 
like this:

SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
=A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
=A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.14 20030612
LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
=A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.15.90.0.3 20040415 

>
> Take care,
>
> > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > The source
> > file
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is
> > not found.
> > 9
> > making
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o
> > from
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
> > cp: cannot stat
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o'
> >: No such file or directory
> > make[3]: ***
> > [/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.
> >o] Error 1
> > make[3]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
> > make[2]: *** [interpdir] Error 2
> > make[2]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
> > make[1]: *** [srcdir] Error 2
> > make[1]: Leaving directory
> > `/home/magnus/usr/source/axiom/cvs-040624/axiom' make: *** [all] Error 2
> >
> > > 3) If you would like, please check si::*plt-table* on the failing
> > >     systems, as well as configuring with --disable-statsysbfd
> > >     --enable-custreloc
> >
> > I am sorry. I do not understand your instruction. "..si::*plt-table* ..".
> > This probably points out a serious limit in my Lisp, debugger, Unix
> > knowledge, but it is true. I do not mind checking as per your
> > instructions if you do not mind a few more details. (That could be a lot
> > of work for you...) Configure what? The Axiom build ./configure?
> >
> > > BTW, how is axiom on openbsd?
> > >
> > > Take care,
> > >
> > > > > Take care,
> > > > >
> > > > > > This might pinpoint an issue with GCL. Axiom is using its own
> > > > > > version of GCL (2.6.2-something) but there might be an issue with
> > > > > > this release of GCL and the releases of binutils and other
> > > > > > utilities on your system.

\start
Date: 30 Jun 2004 07:28:12 -0400
From: Camm Maguire
To: Magnus Larsson
Subject: Re: [Gcl-devel] Re: Axiom cvs 040624 build error

Greetings!

Magnus Larsson writes:

> Hello Camm Maguire,
> 
> I have tried the new gcl switches. They did not work for me.
> Details below.
> 
> On Tuesday 29 June 2004 23.00, Camm Maguire wrote:
> > Greetings!
> >
> > Magnus Larsson writes:
> > > Hello again Camm Maguire ,
> > >
> > > > 1) Could you please report the full binutils versions?
> > >
> > > SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> > > 	Binutils 2.15.90.0.3 20040415
> > > LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> > > 	Binutils 2.14 20030612
> > > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > > 	Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
> > >
> > > > 2) Could you please point me to a build log showing the failure
> > >
> > > I will email you a log separately. It gets bounced off the list since it
> > > is too big. Please find a snippet below.
> > > .....
> >
> > OK, got your file.  It is as you suspect almost certainly a binutils
> > issue.  I would need access to a machine with these binutils to make
> > sure and propose a fix.  Has it been officially released yet?  Debian
> > doesn't have it.
> >
> > In the meantime, there is a high likelihood that you can work around
> > the difficulty  by configuring your gcl with --disable-statsysbfd
> > --enable-locbfd, or --disable-statsysbfd --enable-custreloc on i386
> > and sparc only.  GCL carries around its own copy of binutils for
> > convenience.   Tim can show you how to edit the Makefile.pamplets to
> > try this out.  Just search for --enable in lsp/Makefile.pamphlet,
> > choose the correct stanza, and edit.
> 
> 
> using:
> LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1)
> Binutils 2.15.90.0.3 20040415 (This system is a bit experimental, but it is 
> what I normally use for Maxima, Texmacs, Pari,..)
> I will try the SUSE 9.1 distro later).
> 
> CVS Axiom checkout today, 30-June. I used Tim's instructions to patch 
> lsp/Makefile.pamphlet line 266.
> 
> 	./configure --enable-vssize=65536*2 --disable-statsysbfd 
> --enable-maxpage=128*1024 --enable-locbfd ; \
> => fails as before
> 
> 	./configure --enable-vssize=65536*2 --disable-statsysbfd 
> --enable-maxpage=128*1024 --enable-custreloc ; \
> => fails as before
> 

OK, so the loader is perhaps not the problem.

Now we need to configure with --enable-debug, cd
lsp/gcl-2.6.2/unixport, gdb saved_gcl, r, (load "../gcl-tk/tkl.o") and
see if you can reproduce the crash.  If so, please give a gdb
backtrace with the command 'bt'.  Or get me acces to a failing box and
I'll take a look.  If this does not reproduce the crash, try q, cd
../gcl-tk/demos, r, (load "../tkl.o")(TK::GET-AUTOLOADS (directory
"*.lisp")).

Take care,

> Btw, i mixed the Binutils up in the list i sent before. The correct list lokes 
> like this:
> 
> SUSE 9.1 (i686-pc-linux-gnu system, Binutils 2.15.90, gcc 3.3.1) => fail
> =A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.15.90.0.1.1 20040303 (Suse Linux)
> LFS 5.0 (i686-pc-linux-gnu system, Binutils 2.14, gcc 3.3.1) => ok.
> =A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.14 20030612
> LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> =A0=A0=A0=A0=A0=A0=A0=A0Binutils 2.15.90.0.3 20040415 
> 
> >
> > Take care,
> >
> > > LFS 6.0 CVS (i686-pc-linux-gnu system, Binutils 2.15, gcc 3.3.1) => fail
> > > The source
> > > file
> > > /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is
> > > not found.
> > > 9
> > > making
> > > /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o
> > > from
> > > /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
> > > cp: cannot stat
> > > `/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o'
> > >: No such file or directory
> > > make[3]: ***
> > > [/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.
> > >o] Error 1
> > > make[3]: Leaving directory
> > > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
> > > make[2]: *** [interpdir] Error 2
> > > make[2]: Leaving directory
> > > `/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
> > > make[1]: *** [srcdir] Error 2
> > > make[1]: Leaving directory
> > > `/home/magnus/usr/source/axiom/cvs-040624/axiom' make: *** [all] Error 2
> > >
> > > > 3) If you would like, please check si::*plt-table* on the failing
> > > >     systems, as well as configuring with --disable-statsysbfd
> > > >     --enable-custreloc
> > >
> > > I am sorry. I do not understand your instruction. "..si::*plt-table* ..".
> > > This probably points out a serious limit in my Lisp, debugger, Unix
> > > knowledge, but it is true. I do not mind checking as per your
> > > instructions if you do not mind a few more details. (That could be a lot
> > > of work for you...) Configure what? The Axiom build ./configure?
> > >
> > > > BTW, how is axiom on openbsd?
> > > >
> > > > Take care,
> > > >
> > > > > > Take care,
> > > > > >
> > > > > > > This might pinpoint an issue with GCL. Axiom is using its own
> > > > > > > version of GCL (2.6.2-something) but there might be an issue with
> > > > > > > this release of GCL and the releases of binutils and other
> > > > > > > utilities on your system.

\start
Date: Thu, 24 Jun 2004 21:59:47 +0200
From: Magnus Larsson
To: list
Subject: Re: Axiom cvs 040624 build error

--Boundary-00=_zKz2A6CeUPiO60/
  charset="iso-8859-1"

Hello Tim Daly,

Thank you for your feedback.

I have rebuilt from scratch. The AXIOM variable appears to be correct. I
use the output from ./configure to set the AXIOM variable.
I tried make clean from within the old tree. It did not build.
Please find my comments below.

On Thursday 24 June 2004 21.16, root wrote:
> > Magnus,
> >
> > It appears that the AXIOM variable is not set properly.
> > It should be set as follows:
> >
> > If the top level Makefile lives in
> >
> > /foo/bar/baz
> >
> > then you set the AXIOM variable to be:
> >
> > /foo/bar/baz/mnt/linux
> >             ^^^^^^^^^^
> >
> > I could not figure out from your message exactly where the
> > top level Makefile resides. Axiom uses the AXIOM variable for
> > two things. First it parses out where it is installed
> > (/foo/bar/baz) and second, which kind of system to build ('linux').
>
The Makefile resides in:
/usr/source/axiom/cvs-040624/axiom

echo $AXIOM gives
/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux

This conforms to the rule adding /mnt/linux to the directory where Makefile
resides. This is what ./configure outputs as well.

> > I test every build before I check it in so, unless the checkin
> > failed it should build.
> >
> > You've likely confused the Axiom build system. I'd recommend
> > destroying the directory and re-fetching the sources.

I have tried to rebuild from scratch: cvs, ./configure, export AXIOM=,
make. It did not build. The console output is attached in make-scratch.log.

> > Alternatively, you need to do the following steps
> >
> > 1) keep the AXIOM variable set to its current setting
> > 2) make clean
> >
> >   This will cleanup the broken directories and restore the
> >   original systems.
> >
> > 3) set the AXIOM variable to the new value above
> > 4) make
>
I have tried make clean. It did not build. The console output is attached
in make.log. I did not change the AXIOM variable since it seems to be
correct. The Makefile resides in: /usr/source/axiom/cvs-040624/axiom
echo $AXIOM gives
/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux

> >   This will build the system with the correct paths.
> >
> > Let me know if you succeed or fail.
> > If you run the build in an emacs shell buffer you can send me
> > the complete console output.
> >
> > Tim
>
I have built Axiom from cvs sources several times before using my curent
Linux system. The 5-june-2004 version builds using the same cvs,
./configure, export AXIOM=, make procedure that fails here.

Best regards,

Magnus Larsson

--Boundary-00=_zKz2A6CeUPiO60/
  charset="iso-8859-1";
  name="make-scratch.log"
	filename="make-scratch.log"

11 making /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp from /home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp/apply.boot.pamphlet

>
Error: Caught fatal error [memory may be damaged]
=46ast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LET.
Broken at APPLY.  Type :H for Help.
BOOT>>10 making /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o from /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp

>
The source file /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is not found.
9 making /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o from /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o
cp: cannot stat `/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o': No such file or directory
make[3]: *** [/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o] Error 1
make[3]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom'
make: *** [all] Error 2


\start
Date: Sat, 26 Jun 2004 20:59:01 +0200
From: Magnus Larsson
To: David Mentre
Subject: Re: Axiom cvs 040624 build error

Hello David Mentre, cc: axiom-developer,

I have moved away from my linuxfromscratch systems to a regular distro, 
SUSE-9.1 in order to make my results more traceable.  Please find my comments 
below.

On Saturday 26 June 2004 13.40, you wrote:
> Magnus Larsson writes:
> > This does not work:
> > I can still not build Axiom CVS 040624 on my original system using
> > gcc-3.3.1, gcl-2.7.0 ANSI, binutils 2.15.90.0.3 20040415, NPTL.  I might
> > have trashed something on this system, but I am not aware of any seroius
> > malconfiguration. (CVS 5-june-2004 does build on this system)
> > The Binutils version is the only difference I can pinpoint right now.
>
> This might pinpoint an issue with GCL. Axiom is using its own version of
> GCL (2.6.2-something) but there might be an issue with this release of
> GCL and the releases of binutils and other utilities on your system.

Ooops, I did not know, for sure, that Axiom relied on its own GCL 2.6.
Will it not be hard to maintain a separate GCL version for Axiom alone? Why 
not rely on the build platfrom to supply GCL? Well, I am sure this has been 
discussed already and I do not mind the current strategy.

>
> Yours,
> d.

SUSE 9.1, standard installation, results using Axiom CVS 040624:

SUSE-9.1 utilises GCC-3.3.3 and Binutils 2.15.90.0.1.1 20040303 (Suse Linux)

This build fails due to a GCC-3.3.3 problem with the GMP version used in Axiom 
(or GCL). Why not rely on the build platform to supply GMP?

...
aorsmul.c:44: error: conflicting types for `__gmpz_aorsmul'
aorsmul.c:39: error: previous declaration of `__gmpz_aorsmul'
...

Please refer to the suse-9.1-standard-gcc3.3.3 log attached.

This GMP fault is a known issue. I think that there are GMP patches, or at 
least a patch strategy around this problem.

==========================
SUSE 9.1 results using Axiom CVS 040624, GCC downgraded to GCC-3.3.1:

GCC-3.3.1 is compatible with the GMP code supplied. The Binutils version is 
unchanged 2.15.90.0.1.1 20040303.

However, this build fails with the same result as originaly reported when I 
started this thread.

...
making /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp 
from /home/magnus/usr/source/axiom/cvs-040 
624/axiom/src/interp/apply.boot.pamphlet

>
Error: Caught fatal error [memory may be damaged]
=46ast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LET.
Broken at APPLY. =A0Type :H for Help.
BOOT>>10 
making /home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o 
from /home/magnus/usr/source/axiom /cvs-040624/axiom/int/interp/apply.clisp

>
The source 
file /home/magnus/usr/source/axiom/cvs-040624/axiom/int/interp/apply.clisp is 
not found.
9 
making /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o 
from /home/magnus/usr/source/axiom/cvs- 040624/axiom/obj/linux/interp/apply.o
cp: cannot stat 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/obj/linux/interp/apply.o': No 
such file or directory
make[3]: *** 
[/home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux/autoload/apply.o] 
Error 1
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory 
`/home/magnus/usr/source/axiom/cvs-040624/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/cvs-040624/axiom'
make: *** [all] Error 2
...
There are several "The source file .../int/interp/<filename> is not found" 
before the final error reference to "... int/interp/apply.clisp is not found" 
shown in the text above.
...

SUSE-9.1 is a fairly common Linux distro. (The system I normally use is not).

I do value the excellent work of the Axiom community. I hope that Axiom will 
permit using SUSE (and other distros) as a build platform when released, in 
order not to exlude SUSE users from Axiom. :-)

Conclusion?
SUSE-9.1 can not build Axiom CVS, not even after a GCC downgrade in order to 
work around the GMP problem.

A SUSE-9.1 system downgraded to GCC-3.3.1 fails with the same problem as 
originally reported, starting this thread.

I can build Axiom CVS using GCC-3.3.1 a binutils 2.14 system.

This might pinpoint an issue with GCL, as you, David, pointed out. 

If Binutils problem:
Please note, I think Binutils 2.15.90.xx is becoming more common among Linux 
distros, aiming for NPTL instead of Linuxthreads, as a thread linrary. 
Binutils 2.14 does not support NPTL. (you need Binutils 2.14.0.7 or .8 for 
that). I am not in a position to make any definitive statements regarding 
this. I am not familiar with the details of Binutils.

Best regards,

Magnus Larsson


--Boundary-00=_1dc3Av9QL3/6HOy
	name="suse-9.1-standard-gcc3.3.3.log"
	filename="suse-9.1-standard-gcc3.3.3.log"

13 making noweb
patching file modules.c
mnt.o(.text+0x369): In function `emitfile':
: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
make[1]: [install-elisp] Error 1 (ignored)
0 SPAD=/home/magnus/usr/source/axiom/axiom/mnt/linux SYS=linux SPD=/home/magnus/usr/source/axiom/axiom LSP=/home/magnus/usr/source/axiom/axiom/lsp GCLDIR=/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2 SRC=/home/magnus/usr/source/axiom/axiom/src INT=/home/magnus/usr/source/axiom/axiom/int OBJ=/home/magnus/usr/source/axiom/axiom/obj MNT=/home/magnus/usr/source/axiom/axiom/mnt ZIPS=/home/magnus/usr/source/axiom/axiom/zips TMP=/home/magnus/usr/source/axiom/axiom/obj/tmp SPADBIN=/home/magnus/usr/source/axiom/axiom/mnt/linux/bin INC=/home/magnus/usr/source/axiom/axiom/src/include CCLBASE=/home/magnus/usr/source/axiom/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/magnus/usr/source/axiom/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.2 TANGLE=/home/magnus/usr/source/axiom/axiom/mnt/linux/bin/lib/notangle
10 copying /home/magnus/usr/source/axiom/axiom/src/scripts to /home/magnus/usr/source/axiom/axiom/mnt/linux/bin
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/home/magnus/usr/source/axiom/axiom/mnt/linux SYS=linux SPD=/home/magnus/usr/source/axiom/axiom LSP=/home/magnus/usr/source/axiom/axiom/lsp GCLDIR=/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2 SRC=/home/magnus/usr/source/axiom/axiom/src INT=/home/magnus/usr/source/axiom/axiom/int OBJ=/home/magnus/usr/source/axiom/axiom/obj MNT=/home/magnus/usr/source/axiom/axiom/mnt ZIPS=/home/magnus/usr/source/axiom/axiom/zips TMP=/home/magnus/usr/source/axiom/axiom/obj/tmp SPADBIN=/home/magnus/usr/source/axiom/axiom/mnt/linux/bin INC=/home/magnus/usr/source/axiom/axiom/src/include CCLBASE=/home/magnus/usr/source/axiom/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/magnus/usr/source/axiom/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.2 TANGLE=/home/magnus/usr/source/axiom/axiom/mnt/linux/bin/lib/notangle
make[1]: Entering directory `/home/magnus/usr/source/axiom/axiom'
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/home/magnus/usr/source/axiom/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/home/magnus/usr/source/axiom/axiom/src/share XLIB=/usr/X11R6/lib
18 making /home/magnus/usr/source/axiom/axiom/src
make[2]: Entering directory `/home/magnus/usr/source/axiom/axiom/src'
1 making /home/magnus/usr/source/axiom/axiom/src/scripts
make[3]: Entering directory `/home/magnus/usr/source/axiom/axiom/src/scripts'
1 making /home/magnus/usr/source/axiom/axiom/src/scripts
make[3]: Leaving directory `/home/magnus/usr/source/axiom/axiom/src/scripts'
17 making /home/magnus/usr/source/axiom/axiom/src/lib
make[3]: Entering directory `/home/magnus/usr/source/axiom/axiom/src/lib'
1 making /home/magnus/usr/source/axiom/axiom/int/lib/bsdsignal.c from /home/magnus/usr/source/axiom/axiom/src/lib/bsdsignal.c.pamphlet
2 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/bsdsignal.o from /home/magnus/usr/source/axiom/axiom/int/lib/bsdsignal.c
9 making /home/magnus/usr/source/axiom/axiom/int/lib/cursor.c from /home/magnus/usr/source/axiom/axiom/src/lib/cursor.c.pamphlet
10 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/cursor.o from /home/magnus/usr/source/axiom/axiom/int/lib/cursor.c
13 making /home/magnus/usr/source/axiom/axiom/int/lib/edin.c from /home/magnus/usr/source/axiom/axiom/src/lib/edin.c.pamphlet
14 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/edin.o from /home/magnus/usr/source/axiom/axiom/int/lib/edin.c
17 making /home/magnus/usr/source/axiom/axiom/int/lib/fnct_key.c from /home/magnus/usr/source/axiom/axiom/src/lib/fnct_key.c.pamphlet
18 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/fnct_key.o from /home/magnus/usr/source/axiom/axiom/int/lib/fnct_key.c
21 making /home/magnus/usr/source/axiom/axiom/int/lib/halloc.c from /home/magnus/usr/source/axiom/axiom/src/lib/halloc.c.pamphlet
22 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/halloc.o from /home/magnus/usr/source/axiom/axiom/int/lib/halloc.c
29 making /home/magnus/usr/source/axiom/axiom/int/lib/openpty.c from /home/magnus/usr/source/axiom/axiom/src/lib/openpty.c.pamphlet
30 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/openpty.o from /home/magnus/usr/source/axiom/axiom/int/lib/openpty.c
33 making /home/magnus/usr/source/axiom/axiom/int/lib/pixmap.c from /home/magnus/usr/source/axiom/axiom/src/lib/pixmap.c.pamphlet
34 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/pixmap.o from /home/magnus/usr/source/axiom/axiom/int/lib/pixmap.c
/home/magnus/usr/source/axiom/axiom/int/lib/pixmap.c: In function `write_pixmap_file':
/home/magnus/usr/source/axiom/axiom/int/lib/pixmap.c:348: warning: unused variable `attr'
/home/magnus/usr/source/axiom/axiom/int/lib/pixmap.c:349: warning: unused variable `xireturn'
37 making /home/magnus/usr/source/axiom/axiom/int/lib/prt.c from /home/magnus/usr/source/axiom/axiom/src/lib/prt.c.pamphlet
38 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/prt.o from /home/magnus/usr/source/axiom/axiom/int/lib/prt.c
41 making /home/magnus/usr/source/axiom/axiom/int/lib/sockio-c.c from /home/magnus/usr/source/axiom/axiom/src/lib/sockio-c.c.pamphlet
42 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/sockio-c.o from /home/magnus/usr/source/axiom/axiom/int/lib/sockio-c.c
/home/magnus/usr/source/axiom/axiom/int/lib/sockio-c.c: In function `connect_to_local_server':
/home/magnus/usr/source/axiom/axiom/int/lib/sockio-c.c:933: warning: `code' might be used uninitialized in this function
45 making /home/magnus/usr/source/axiom/axiom/int/lib/spadcolors.c from /home/magnus/usr/source/axiom/axiom/src/lib/spadcolors.c.pamphlet
46 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/spadcolors.o from /home/magnus/usr/source/axiom/axiom/int/lib/spadcolors.c
49 making /home/magnus/usr/source/axiom/axiom/int/lib/util.c from /home/magnus/usr/source/axiom/axiom/src/lib/util.c.pamphlet
50 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/util.o from /home/magnus/usr/source/axiom/axiom/int/lib/util.c
53 making /home/magnus/usr/source/axiom/axiom/int/lib/wct.c from /home/magnus/usr/source/axiom/axiom/src/lib/wct.c.pamphlet
54 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/wct.o from /home/magnus/usr/source/axiom/axiom/int/lib/wct.c
/home/magnus/usr/source/axiom/axiom/int/lib/wct.c: In function `skim1Wct':
/home/magnus/usr/source/axiom/axiom/int/lib/wct.c:274: warning: int format, off_t arg (arg 3)
57 making /home/magnus/usr/source/axiom/axiom/int/lib/XDither.c from /home/magnus/usr/source/axiom/axiom/src/lib/XDither.c.pamphlet
58 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/XDither.o from /home/magnus/usr/source/axiom/axiom/int/lib/XDither.c
61 making /home/magnus/usr/source/axiom/axiom/int/lib/XShade.c from /home/magnus/usr/source/axiom/axiom/src/lib/XShade.c.pamphlet
62 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/XShade.o from /home/magnus/usr/source/axiom/axiom/int/lib/XShade.c
65 making /home/magnus/usr/source/axiom/axiom/int/lib/XSpadFill.c from /home/magnus/usr/source/axiom/axiom/src/lib/XSpadFill.c.pamphlet
66 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/XSpadFill.o from /home/magnus/usr/source/axiom/axiom/int/lib/XSpadFill.c
73 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/libspad.a
ar: creating /home/magnus/usr/source/axiom/axiom/obj/linux/lib/libspad.a
5 making /home/magnus/usr/source/axiom/axiom/int/lib/cfuns-c.c from /home/magnus/usr/source/axiom/axiom/src/lib/cfuns-c.c.pamphlet
6 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/cfuns-c.o from /home/magnus/usr/source/axiom/axiom/int/lib/cfuns-c.c
/home/magnus/usr/source/axiom/axiom/int/lib/cfuns-c.c: In function `make_path_from_file':
/home/magnus/usr/source/axiom/axiom/int/lib/cfuns-c.c:113: warning: `pos' might be used uninitialized in this function
25 making /home/magnus/usr/source/axiom/axiom/int/lib/hash.c from /home/magnus/usr/source/axiom/axiom/src/lib/hash.c.pamphlet
26 making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/hash.o from /home/magnus/usr/source/axiom/axiom/int/lib/hash.c
3 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/bsdsignal.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/bsdsignal.c.pamphlet
4 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/bsdsignal.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/bsdsignal.c.dvi
7 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/cfuns-c.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/cfuns-c.c.pamphlet
8 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/cfuns-c.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/cfuns-c.c.dvi
11 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/cursor.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/cursor.c.pamphlet
12 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/cursor.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/cursor.c.dvi
15 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/edin.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/edin.c.pamphlet
16 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/edin.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/edin.c.dvi
19 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/fnct_key.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/fnct_key.c.pamphlet
20 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/fnct_key.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/fnct_key.c.dvi
23 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/halloc.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/halloc.c.pamphlet
24 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/halloc.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/halloc.c.dvi
27 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/hash.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/hash.c.pamphlet
28 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/hash.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/hash.c.dvi
31 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/openpty.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/openpty.c.pamphlet
32 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/openpty.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/openpty.c.dvi
35 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/pixmap.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/pixmap.c.pamphlet
36 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/pixmap.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/pixmap.c.dvi
39 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/prt.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/prt.c.pamphlet
40 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/prt.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/prt.c.dvi
43 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/sockio-c.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/sockio-c.c.pamphlet
44 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/sockio-c.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/sockio-c.c.dvi
71 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/Makefile.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/Makefile.dvi
47 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/spadcolors.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/spadcolors.c.pamphlet
48 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/spadcolors.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/spadcolors.c.dvi
51 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/util.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/util.c.pamphlet
52 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/util.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/util.c.dvi
55 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/wct.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/wct.c.pamphlet
56 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/wct.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/wct.c.dvi
59 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XDither.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/XDither.c.pamphlet
60 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/XDither.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XDither.c.dvi
63 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XShade.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/XShade.c.pamphlet
64 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/XShade.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XShade.c.dvi
67 making /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XSpadFill.c.dvi from /home/magnus/usr/source/axiom/axiom/src/lib/XSpadFill.c.pamphlet
68 making /home/magnus/usr/source/axiom/axiom/mnt/linux/doc/src/lib/XSpadFill.c.dvi from /home/magnus/usr/source/axiom/axiom/int/doc/src/lib/XSpadFill.c.dvi
72 finished making /home/magnus/usr/source/axiom/axiom/obj/linux/lib/libspad.a /home/magnus/usr/source/axiom/axiom/obj/linux/lib/cfuns-c.o /home/magnus/usr/source/axiom/axiom/obj/linux/lib/hash.o
make[3]: Leaving directory `/home/magnus/usr/source/axiom/axiom/src/lib'
make[2]: Leaving directory `/home/magnus/usr/source/axiom/axiom/src'
0 PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/home/magnus/usr/source/axiom/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/home/magnus/usr/source/axiom/axiom/src/share XLIB=/usr/X11R6/lib
10 copying /home/magnus/usr/source/axiom/axiom/src/scripts to /home/magnus/usr/source/axiom/axiom/mnt/linux/bin
19 making /home/magnus/usr/source/axiom/axiom/lsp
make[2]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp'
2 building gcl-2.6.2
3 applying EXTRAS patch to h/linux.defs
patching file linux.defs
4 setup ini files for EXTRAS patch
6 applying libspad.a patch to unixport/makefile
patching file makefile
7 applying toploop patch to unixport/init_gcl.lsp
patching file init_gcl.lsp.in
18 applying MAX_STACK_SIZE patch
patching file main.c
11 applying tail-recursive noise patch
patching file gcl_cmpflet.lsp
12 applying tail-recursive noise patch
patching file gcl_cmpcall.lsp
26 copy gcl_collectfn.lsp to collectfn.lsp
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
host=i686-pc-linux-gnu
enable_machineuse=386-linux
checking for gcc... gcc
checking whether the C compiler (gcc   ) works... yes
checking whether the C compiler (gcc   ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for gawk... gawk
checking system version (for dynamic loading)... checking for makeinfo... no
Linux-2.6.5-7.75-default
checking use_gmp=yes, doing configure in gmp directory... 
#
#
# -------------------
# Subconfigure of GMP
#
#
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... athlon-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking compiler gcc -g -O2 -fomit-frame-pointer ... yes
checking compiler gcc -g -O2 -fomit-frame-pointer  -mcpu=pentiumpro... yes
checking whether gcc -march=pentiumpro is good... configure: WARNING: unrecognised gcc version string: gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
no
checking compiler gcc -g -O2 -fomit-frame-pointer -mcpu=pentiumpro  -march=i486... yes
checking for i686-pc-linux-gnu-gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... 
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
using ABI="standard"
      CC="gcc"
      CFLAGS="-g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486"
      CPPFLAGS=""
checking for gcc option to accept ANSI C... none needed
checking for function prototypes... yes
checking for ANSI C header files... yes
checking for string.h... yes
checking for i686-pc-linux-gnu-ar... no
checking for ar... ar
checking for BSD-compatible nm... nm
checking for ld used by GCC... /usr/i586-suse-linux/bin/ld
checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes
checking for /usr/i586-suse-linux/bin/ld option to reload object files... -r
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 49153
checking command to parse nm output from gcc object... ok
checking for objdir... .libs
checking for i686-pc-linux-gnu-ranlib... ranlib
checking for i686-pc-linux-gnu-strip... no
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for locale.h... yes
checking for sys/mman.h... yes
checking for sys/param.h... yes
checking for sys/processor.h... no
checking for sys/resource.h... yes
checking for sys/sysctl.h... yes
checking for sys/systemcfg.h... no
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... (cached) yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether fgetc is declared... yes
checking whether fscanf is declared... yes
checking whether optarg is declared... yes
checking whether ungetc is declared... yes
checking whether vfprintf is declared... yes
checking return type of signal handlers... void
checking for intmax_t... yes
checking for long double... yes
checking for long long... yes
checking for ptrdiff_t... yes
checking for quad_t... yes
checking for preprocessor stringizing operator... yes
checking whether <stdarg.h> exists and works... yes
checking whether gcc __attribute__ ((const)) works... yes
checking whether gcc __attribute__ ((malloc)) works... yes
checking whether gcc __attribute__ ((mode (XX))) works... yes
checking whether gcc __attribute__ ((noreturn)) works... yes
checking for inline... inline
checking for main in -lm... yes
checking for working alloca.h... yes
checking for alloca (via gmp-impl.h)... yes
checking how to allocate temporary memory... alloca
checking for alarm... yes
checking for getpagesize... yes
checking for getrusage... yes
checking for gettimeofday... yes
checking for localeconv... yes
checking for memset... yes
checking for mmap... yes
checking for mprotect... yes
checking for obstack_vprintf... yes
checking for popen... yes
checking for processor_info... no
checking for read_real_time... no
checking for strchr... yes
checking for strnlen... yes
checking for strtoul... yes
checking for sysconf... yes
checking for sysctl... yes
checking for sysctlbyname... no
checking for times... yes
checking for vsnprintf... yes
checking whether vsnprintf works... yes
checking whether sscanf needs writable input... no
checking for suitable m4... m4
checking if m4wrap produces spurious output... no
checking how to switch to text section... .text
checking how to switch to data section... .data
checking what assembly label suffix to use... :
checking how to export a symbol... .globl
checking if globals are prefixed by underscore... no
checking how to switch to read-only data section... 	.section	.rodata
checking if the export directive needs an attribute... 
checking for assembler .type directive... .type	$1,@$2
checking for assembler .size directive... .size	$1,$2
checking what prefix to use for a local label... .L
checking how to define a 32-bit word... .long
checking if .align assembly directive is logarithmic... no
checking if the .align directive accepts an 0x90 fill in .text... yes
checking if the assembler takes cl with shldl... yes
creating config.m4
configure: creating ./config.status
config.status: creating Makefile
config.status: creating mpbsd/Makefile
config.status: creating mpf/Makefile
config.status: creating mpn/Makefile
config.status: creating mpq/Makefile
config.status: creating mpz/Makefile
config.status: creating printf/Makefile
config.status: creating scanf/Makefile
config.status: creating cxx/Makefile
config.status: creating tests/Makefile
config.status: creating tests/devel/Makefile
config.status: creating tests/mpbsd/Makefile
config.status: creating tests/mpf/Makefile
config.status: creating tests/mpn/Makefile
config.status: creating tests/mpq/Makefile
config.status: creating tests/mpz/Makefile
config.status: creating tests/rand/Makefile
config.status: creating tests/misc/Makefile
config.status: creating tests/cxx/Makefile
config.status: creating tune/Makefile
config.status: creating demos/Makefile
config.status: creating demos/calc/Makefile
config.status: creating demos/expr/Makefile
config.status: creating gmp.h
config.status: creating mp.h
config.status: creating demos/expr/expr-impl.h
config.status: creating config.h
config.status: linking ./mpn/x86/udiv.asm to mpn/udiv.asm
config.status: linking ./mpn/x86/umul.asm to mpn/umul.asm
config.status: linking ./mpn/generic/add.c to mpn/add.c
config.status: linking ./mpn/generic/add_1.c to mpn/add_1.c
config.status: linking ./mpn/x86/aors_n.asm to mpn/add_n.asm
config.status: linking ./mpn/generic/sub.c to mpn/sub.c
config.status: linking ./mpn/generic/sub_1.c to mpn/sub_1.c
config.status: linking ./mpn/x86/aors_n.asm to mpn/sub_n.asm
config.status: linking ./mpn/x86/mul_1.asm to mpn/mul_1.asm
config.status: linking ./mpn/x86/p6/aorsmul_1.asm to mpn/addmul_1.asm
config.status: linking ./mpn/x86/p6/aorsmul_1.asm to mpn/submul_1.asm
config.status: linking ./mpn/x86/lshift.asm to mpn/lshift.asm
config.status: linking ./mpn/x86/rshift.asm to mpn/rshift.asm
config.status: linking ./mpn/x86/p6/dive_1.asm to mpn/dive_1.asm
config.status: linking ./mpn/x86/p6/diveby3.asm to mpn/diveby3.asm
config.status: linking ./mpn/generic/divis.c to mpn/divis.c
config.status: linking ./mpn/generic/divrem.c to mpn/divrem.c
config.status: linking ./mpn/x86/divrem_1.asm to mpn/divrem_1.asm
config.status: linking ./mpn/generic/divrem_2.c to mpn/divrem_2.c
config.status: linking ./mpn/generic/fib2_ui.c to mpn/fib2_ui.c
config.status: linking ./mpn/x86/p6/mod_1.asm to mpn/mod_1.asm
config.status: linking ./mpn/x86/mod_34lsub1.asm to mpn/mod_34lsub1.asm
config.status: linking ./mpn/x86/p6/mode1o.asm to mpn/mode1o.asm
config.status: linking ./mpn/generic/dump.c to mpn/dump.c
config.status: linking ./mpn/generic/mul.c to mpn/mul.c
config.status: linking ./mpn/generic/mul_fft.c to mpn/mul_fft.c
config.status: linking ./mpn/generic/mul_n.c to mpn/mul_n.c
config.status: linking ./mpn/x86/mul_basecase.asm to mpn/mul_basecase.asm
config.status: linking ./mpn/x86/p6/sqr_basecase.asm to mpn/sqr_basecase.asm
config.status: linking ./mpn/generic/random.c to mpn/random.c
config.status: linking ./mpn/generic/random2.c to mpn/random2.c
config.status: linking ./mpn/generic/sqrtrem.c to mpn/sqrtrem.c
config.status: linking ./mpn/generic/get_str.c to mpn/get_str.c
config.status: linking ./mpn/generic/set_str.c to mpn/set_str.c
config.status: linking ./mpn/generic/scan0.c to mpn/scan0.c
config.status: linking ./mpn/generic/scan1.c to mpn/scan1.c
config.status: linking ./mpn/generic/popcount.c to mpn/popcount.c
config.status: linking ./mpn/generic/hamdist.c to mpn/hamdist.c
config.status: linking ./mpn/generic/cmp.c to mpn/cmp.c
config.status: linking ./mpn/generic/perfsqr.c to mpn/perfsqr.c
config.status: linking ./mpn/generic/bdivmod.c to mpn/bdivmod.c
config.status: linking ./mpn/generic/gcd_1.c to mpn/gcd_1.c
config.status: linking ./mpn/generic/gcd.c to mpn/gcd.c
config.status: linking ./mpn/generic/gcdext.c to mpn/gcdext.c
config.status: linking ./mpn/generic/tdiv_qr.c to mpn/tdiv_qr.c
config.status: linking ./mpn/generic/dc_divrem_n.c to mpn/dc_divrem_n.c
config.status: linking ./mpn/generic/sb_divrem_mn.c to mpn/sb_divrem_mn.c
config.status: linking ./mpn/generic/jacbase.c to mpn/jacbase.c
config.status: linking ./mpn/x86/copyi.asm to mpn/copyi.asm
config.status: linking ./mpn/x86/p6/copyd.asm to mpn/copyd.asm
config.status: linking ./mpn/x86/p6/gmp-mparam.h to gmp-mparam.h
#
#
#
# Subconfigure of GMP done
# ------------------------
#
checking for size of gmp limbs... 4
checking _SHORT_LIMB... no
checking _LONG_LONG_LIMB... no
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
-I/usr/X11R6/include
-L/usr/X11R6/lib

-lSM -lICE
checking for main in -lXmu... yes
checking for main in -lXt... yes
checking for main in -lXext... yes
checking for main in -lXaw... yes
checking for main in -lX11... yes
checking for bfd.h... yes
checking for bfd_init in -lbfd... yes
checking if need to define CONST for bfd... no
checking for useable bfd_boolean... yes
checking size of long... 4
checking sizeof struct contblock... 8
checking for endian.h... yes
checking endianness... little
checking finding DBEGIN... got 0x8000000
checking finding CSTACK_ADDRESS... got -1073747084
checking sizeof long long int... yes
checking for pagewidth... 12
checking for getcwd... yes
checking for getwd... yes
checking for uname... yes
checking for gettimeofday... yes
checking for sys/ioctl.h... yes
checking for BSDgettimeofday... no
checking for gettimeofday... (cached) yes
checking for gettimeofday declaration... present
checking for sin in -lm... yes
checking for main in -lmingwex... no
checking for math.h... yes
checking for values.h... yes
checking for float.h... yes
checking for isnormal... yes
checking for isfinite... yes
checking for sockets... checking for connect... (cached) yes
checking for gethostbyname... (cached) yes
checking for readline/readline.h... yes
checking for main in -lreadline... yes
checking For network code for nsocket.c... yes
checking check for listen using fcntl... yes
checking for profil... yes
checking for setenv... yes
checking for _cleanup... no
checking FIONBIO vs. O_NONBLOCK for nonblocking I/O... O_NONBLOCK
checking check for SV_ONSTACK... yes
checking check for SIGSYS... yes
checking check for SIGEMT... no
checking for asm/sigcontext.h... yes
checking for asm/signal.h... yes
sigcontext in signal.h
checking for emacs... /usr/bin/emacs
checking emacs site lisp directory... /usr/share/emacs/21.3/site-lisp
checking emacs default.el... /usr/share/emacs/21.3/site-lisp/default.el
checking emacs info/dir... /usr/share/info/
checking for tcl/tk... checking for tclsh... tclsh
checking for main in -llieee... no
using TK_VERSION=8.4 in /usr/lib
checking alloca... yes
checking Checking for buggy gcc version from redhat... no
updating cache ./config.cache
creating ./config.status
creating makedefc
creating windows/gcl.iss
creating windows/sysdir.bat
creating windows/install.lsp
creating h/gclincl.h
makedefc

# begin makedefs

# use=386-linux

# for main link of raw_gcl
LIBS= -lm  /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../libbfd.a /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../libiberty.a -lreadline -lncurses

#The multi precision library stuff
MPFILES=$(MPDIR)/@MPI_FILE@ $(MPDIR)/libmport.a


# root for the installation, eg /usr/local
# This would cause make install to create /usr/local/bin/gcl and
# /usr/local/lib/gcl-2-??/* with some basic files.
prefix=/usr/local

# where to place the info files
INFO_DIR=/usr/share/info/

# where to put emacs lisp files.
EMACS_SITE_LISP=/usr/share/emacs/21.3/site-lisp

# the default.el file
EMACS_DEFAULT_EL=/usr/share/emacs/21.3/site-lisp/default.el

# numerous TCL/TK variables culled from the tkConfig.sh and tclConfig.sh
# if these are found.
TK_CONFIG_PREFIX=/usr/lib
TK_LIBRARY=/usr/lib/tk8.4
TCL_LIBRARY=/usr/lib/tcl8.4
TK_XINCLUDES=-I/usr/X11R6/include
TK_INCLUDE=-I/usr/lib/../include
TCL_INCLUDE=-I/usr/lib/../include
TK_LIB_SPEC=-L/usr/lib -ltk8.4
TK_BUILD_LIB_SPEC=-L/usr/src/packages/BUILD/tk8.4.6/build -ltk8.4
TK_XLIBSW=-L/usr/X11R6/lib -lX11
TK_XINCLUDES=-I/usr/X11R6/include
TCL_LIB_SPEC=-L/usr/lib -ltcl8.4${TCL_DBGX}
TCL_DL_LIBS=-ldl
TCL_LIBS=-ldl  -lm

NOTIFY=yes
CC=gcc
CFLAGS=  -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I$(GCLDIR)/o
FINAL_CFLAGS=  -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe 
NIFLAGS=  -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe   -I$(GCLDIR)/o
O3FLAGS=-O3 -fomit-frame-pointer
O2FLAGS=-O

RL_OBJS=gcl_readline.o

RL_LIB
MAKEINFO=false

FLISP=saved_gcl
SYSTEM=gcl
BUILD_BFDGMPDIR=gmp3
X_LIBS= -L/usr/X11R6/lib -lXmu -lXt -lXext -lXaw -lX11
X_CFLAGS= -I/usr/X11R6/include

PROCESSOR_FLAGS
EXTRA_LOBJSadd-defs1 386-linux
using 386-linux.defs
make[3]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2'
(cd o && make ../h/new_decl.h)
make[4]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o'
gcc  -o grab_defs  grab_defs.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E main.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > main.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E alloc.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > alloc.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E gbc.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > gbc.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E bitop.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > bitop.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E typespec.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > typespec.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E eval.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > eval.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E macros.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > macros.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E lex.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > lex.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E bds.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > bds.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E frame.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > frame.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E predicate.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > predicate.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E reference.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > reference.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E assignment.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > assignment.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E bind.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > bind.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E let.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > let.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E conditional.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > conditional.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E block.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > block.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E iteration.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > iteration.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E mapfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > mapfun.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E prog.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > prog.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E multival.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > multival.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E catch.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > catch.ini
gcc -I../h -I../gcl-tk -o ../bin/dpp ../bin/dpp.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp symbol
dpp: symbol.d -> symbol.c
./grab_defs < symbol.c > symbol.ini
rm symbol.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E cfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > cfun.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E cmpaux.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > cmpaux.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp package
dpp: package.d -> package.c
./grab_defs < package.c > package.ini
rm package.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E big.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > big.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E number.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > number.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_pred.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_pred.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_comp.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_comp.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_arith.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_arith.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_sfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_sfun.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_co.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_co.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_log.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_log.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E num_rand.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > num_rand.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E earith.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > earith.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp character
dpp: character.d -> character.c
./grab_defs < character.c > character.ini
rm character.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp sequence
dpp: sequence.d -> sequence.c
./grab_defs < sequence.c > sequence.ini
rm sequence.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp list
dpp: list.d -> list.c
./grab_defs < list.c > list.ini
rm list.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp hash
dpp: hash.d -> hash.c
./grab_defs < hash.c > hash.ini
rm hash.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E array.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > array.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp string
dpp: string.d -> string.c
./grab_defs < string.c > string.ini
rm string.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E regexpr.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > regexpr.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E structure.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > structure.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E toplevel.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > toplevel.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp file
dpp: file.d -> file.c
./grab_defs < file.c > file.ini
rm file.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp read
dpp: read.d -> read.c
./grab_defs < read.c > read.ini
rm read.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E backq.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > backq.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp print
dpp: print.d -> print.c
./grab_defs < print.c > print.ini
rm print.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E format.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > format.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp pathname
dpp: pathname.d -> pathname.c
./grab_defs < pathname.c > pathname.ini
rm pathname.c
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E unixfsys.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > unixfsys.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E unixfasl.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > unixfasl.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E error.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > error.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E unixtime.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > unixtime.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E unixsys.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > unixsys.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E unixsave.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > unixsave.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E funlink.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > funlink.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E fat_string.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > fat_string.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E run_process.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > run_process.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E nfunlink.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > nfunlink.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E usig.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > usig.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E usig2.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > usig2.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E utils.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > utils.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E makefun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > makefun.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E sockets.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > sockets.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E clxsocket.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > clxsocket.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E init_pari.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > init_pari.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E nsocket.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > nsocket.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -O3 -fomit-frame-pointer  -I/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o -I../h -I../gcl-tk -E sfasl.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > sfasl.ini
[ -e ../h/new_decl.h ] || touch ../h/new_decl.h
../bin/dpp gcl_readline
dpp: gcl_readline.d -> gcl_readline.c
./grab_defs < gcl_readline.c > gcl_readline.ini
rm gcl_readline.c
echo '#include "make-decl.h"' > foo.c
cat main.ini alloc.ini gbc.ini bitop.ini typespec.ini eval.ini macros.ini lex.ini bds.ini frame.ini predicate.ini reference.ini assignment.ini bind.ini let.ini conditional.ini block.ini iteration.ini mapfun.ini prog.ini multival.ini catch.ini symbol.ini cfun.ini cmpaux.ini package.ini big.ini number.ini num_pred.ini num_comp.ini num_arith.ini num_sfun.ini num_co.ini num_log.ini num_rand.ini earith.ini character.ini sequence.ini list.ini hash.ini array.ini string.ini regexpr.ini structure.ini toplevel.ini file.ini read.ini backq.ini print.ini format.ini pathname.ini unixfsys.ini unixfasl.ini error.ini unixtime.ini unixsys.ini unixsave.ini funlink.ini fat_string.ini ./run_process.ini nfunlink.ini usig.ini usig2.ini utils.ini makefun.ini sockets.ini clxsocket.ini init_pari.ini nsocket.ini ./sfasl.ini /home/magnus/usr/source/axiom/axiom/obj/linux/lib/cfuns-c.ini /home/magnus/usr/source/axiom/axiom/obj/linux/lib/sockio-c.ini gcl_readline.ini >> foo.c
gcc -E -I../h/ foo.c | sed -n -e '/#/d' -e '/DO_/d' -e '/[a-zA-Z;]/p' > ../h/new_decl.h
rm foo.c
make[4]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/o'
cat h/config.h | sed -e "1,/Begin for cmpincl/d" \
	-e "/End for cmpinclude/,50000d" > tmpx
echo -e '#include "h/config.h"\n#ifdef SGC\n"#define SGC"\n#else\n"#undef SGC"\n#endif' | cpp 2>/dev/null| grep -v '^ *$' | tail -1l | tr -d '"' >>tmpx
cat h/cmpincl1.h h/gclincl.h h/compbas.h h/enum.h h/mgmp.h h/object.h h/vs.h h/bds.h h/frame.h h/lex.h h/eval.h    h/funlink.h h/att_ext.h h/new_decl.h h/compbas2.h h/compat.h h/cmponly.h o/regexp.h h//protoize.h >> tmpx
./xbin/move-if-changed mv tmpx h/cmpinclude.h
tmpx and h/cmpinclude.h were not the same.
ln tmpx h/cmpinclude.h
./xbin/move-if-changed cp h/cmpinclude.h o/cmpinclude.h
h/cmpinclude.h and o/cmpinclude.h were not the same.
ln h/cmpinclude.h o/cmpinclude.h
(cd bin; make all)
make[4]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/bin'
gcc  -I../h  -o append  append.c
gcc -I../h  -o file-sub file-sub.c
make[4]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/bin'
make mpfiles
make[4]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2'
cd gmp3 && make 
make[5]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3'
make  all-recursive
make[6]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3'
Making all in tests
make[7]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests'
Making all in .
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests'
make[8]: Nothing to be done for `all-am'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests'
Making all in devel
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/devel'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/devel'
Making all in mpn
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpn'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpn'
Making all in mpz
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpz'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpz'
Making all in mpq
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpq'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpq'
Making all in mpf
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpf'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpf'
Making all in rand
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/rand'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/rand'
Making all in misc
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/misc'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/misc'
Making all in cxx
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/cxx'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/cxx'
Making all in mpbsd
make[8]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpbsd'
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests/mpbsd'
make[7]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/tests'
Making all in mpn
make[7]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/mpn'
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mp_bases | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o mp_bases.lo `test -f mp_bases.c || echo './'`mp_bases.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mp_bases -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mp_bases.c  -fPIC -DPIC -o .libs/mp_bases.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mp_bases -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mp_bases.c -o mp_bases.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo udiv | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f udiv.asm || echo './'`udiv.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_udiv -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 udiv.asm  -fPIC -DPIC -o .libs/udiv.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_udiv -DPIC udiv.asm >tmp-udiv.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_udiv -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-udiv.s -fPIC -DPIC -o .libs/udiv.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_udiv -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 udiv.asm -o udiv.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo umul | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f umul.asm || echo './'`umul.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_umul -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 umul.asm  -fPIC -DPIC -o .libs/umul.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_umul -DPIC umul.asm >tmp-umul.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_umul -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-umul.s -fPIC -DPIC -o .libs/umul.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_umul -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 umul.asm -o umul.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o add.lo `test -f add.c || echo './'`add.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add.c  -fPIC -DPIC -o .libs/add.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add.c -o add.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o add_1.lo `test -f add_1.c || echo './'`add_1.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add_1.c  -fPIC -DPIC -o .libs/add_1.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add_1.c -o add_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add_n | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f add_n.asm || echo './'`add_n.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 add_n.asm  -fPIC -DPIC -o .libs/add_n.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DPIC add_n.asm >tmp-add_n.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-add_n.s -fPIC -DPIC -o .libs/add_n.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 add_n.asm -o add_n.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sub | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o sub.lo `test -f sub.c || echo './'`sub.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sub.c  -fPIC -DPIC -o .libs/sub.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sub.c -o sub.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sub_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o sub_1.lo `test -f sub_1.c || echo './'`sub_1.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sub_1.c  -fPIC -DPIC -o .libs/sub_1.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sub_1.c -o sub_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sub_n | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f sub_n.asm || echo './'`sub_n.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 sub_n.asm  -fPIC -DPIC -o .libs/sub_n.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sub_n -DPIC sub_n.asm >tmp-sub_n.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-sub_n.s -fPIC -DPIC -o .libs/sub_n.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sub_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 sub_n.asm -o sub_n.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mul_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f mul_1.asm || echo './'`mul_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mul_1.asm  -fPIC -DPIC -o .libs/mul_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_mul_1 -DPIC mul_1.asm >tmp-mul_1.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-mul_1.s -fPIC -DPIC -o .libs/mul_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mul_1.asm -o mul_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo addmul_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f addmul_1.asm || echo './'`addmul_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 addmul_1.asm  -fPIC -DPIC -o .libs/addmul_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_addmul_1 -DPIC addmul_1.asm >tmp-addmul_1.s
addmul_1.asm: 220: warning, simulating cmov with jump, use for testing only
addmul_1.asm: 221: warning, simulating cmov with jump, use for testing only
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-addmul_1.s -fPIC -DPIC -o .libs/addmul_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_addmul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 addmul_1.asm -o addmul_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo submul_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f submul_1.asm || echo './'`submul_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_submul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 submul_1.asm  -fPIC -DPIC -o .libs/submul_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_submul_1 -DPIC submul_1.asm >tmp-submul_1.s
submul_1.asm: 220: warning, simulating cmov with jump, use for testing only
submul_1.asm: 221: warning, simulating cmov with jump, use for testing only
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_submul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-submul_1.s -fPIC -DPIC -o .libs/submul_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_submul_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 submul_1.asm -o submul_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo lshift | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f lshift.asm || echo './'`lshift.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_lshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 lshift.asm  -fPIC -DPIC -o .libs/lshift.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_lshift -DPIC lshift.asm >tmp-lshift.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_lshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-lshift.s -fPIC -DPIC -o .libs/lshift.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_lshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 lshift.asm -o lshift.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo rshift | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f rshift.asm || echo './'`rshift.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 rshift.asm  -fPIC -DPIC -o .libs/rshift.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_rshift -DPIC rshift.asm >tmp-rshift.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-rshift.s -fPIC -DPIC -o .libs/rshift.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 rshift.asm -o rshift.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dive_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f dive_1.asm || echo './'`dive_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 dive_1.asm  -fPIC -DPIC -o .libs/dive_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_dive_1 -DPIC dive_1.asm >tmp-dive_1.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-dive_1.s -fPIC -DPIC -o .libs/dive_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 dive_1.asm -o dive_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo diveby3 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f diveby3.asm || echo './'`diveby3.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_diveby3 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 diveby3.asm  -fPIC -DPIC -o .libs/diveby3.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_diveby3 -DPIC diveby3.asm >tmp-diveby3.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_diveby3 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-diveby3.s -fPIC -DPIC -o .libs/diveby3.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_diveby3 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 diveby3.asm -o diveby3.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divis | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o divis.lo `test -f divis.c || echo './'`divis.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divis -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divis.c  -fPIC -DPIC -o .libs/divis.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divis -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divis.c -o divis.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divrem | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o divrem.lo `test -f divrem.c || echo './'`divrem.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divrem.c  -fPIC -DPIC -o .libs/divrem.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divrem.c -o divrem.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divrem_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f divrem_1.asm || echo './'`divrem_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 divrem_1.asm  -fPIC -DPIC -o .libs/divrem_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divrem_1 -DPIC divrem_1.asm >tmp-divrem_1.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-divrem_1.s -fPIC -DPIC -o .libs/divrem_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 divrem_1.asm -o divrem_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divrem_2 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o divrem_2.lo `test -f divrem_2.c || echo './'`divrem_2.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_2 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divrem_2.c  -fPIC -DPIC -o .libs/divrem_2.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_2 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c divrem_2.c -o divrem_2.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fib2_ui | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o fib2_ui.lo `test -f fib2_ui.c || echo './'`fib2_ui.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fib2_ui -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c fib2_ui.c  -fPIC -DPIC -o .libs/fib2_ui.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fib2_ui -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c fib2_ui.c -o fib2_ui.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mod_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f mod_1.asm || echo './'`mod_1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mod_1.asm  -fPIC -DPIC -o .libs/mod_1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_mod_1 -DPIC mod_1.asm >tmp-mod_1.s
mod_1.asm: 142: warning, simulating cmov with jump, use for testing only
mod_1.asm: 217: warning, simulating cmov with jump, use for testing only
mod_1.asm: 282: warning, simulating cmov with jump, use for testing only
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-mod_1.s -fPIC -DPIC -o .libs/mod_1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mod_1.asm -o mod_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mod_34lsub1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f mod_34lsub1.asm || echo './'`mod_34lsub1.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_34lsub1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mod_34lsub1.asm  -fPIC -DPIC -o .libs/mod_34lsub1.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_mod_34lsub1 -DPIC mod_34lsub1.asm >tmp-mod_34lsub1.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_34lsub1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-mod_34lsub1.s -fPIC -DPIC -o .libs/mod_34lsub1.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_34lsub1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mod_34lsub1.asm -o mod_34lsub1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mode1o | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f mode1o.asm || echo './'`mode1o.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mode1o -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mode1o.asm  -fPIC -DPIC -o .libs/mode1o.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_mode1o -DPIC mode1o.asm >tmp-mode1o.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mode1o -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-mode1o.s -fPIC -DPIC -o .libs/mode1o.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mode1o -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mode1o.asm -o mode1o.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dump | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o dump.lo `test -f dump.c || echo './'`dump.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dump -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c dump.c  -fPIC -DPIC -o .libs/dump.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dump -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c dump.c -o dump.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mul | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o mul.lo `test -f mul.c || echo './'`mul.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul.c  -fPIC -DPIC -o .libs/mul.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul.c -o mul.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mul_fft | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o mul_fft.lo `test -f mul_fft.c || echo './'`mul_fft.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul_fft.c  -fPIC -DPIC -o .libs/mul_fft.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul_fft.c -o mul_fft.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mul_n | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o mul_n.lo `test -f mul_n.c || echo './'`mul_n.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul_n.c  -fPIC -DPIC -o .libs/mul_n.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c mul_n.c -o mul_n.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo mul_basecase | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f mul_basecase.asm || echo './'`mul_basecase.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mul_basecase.asm  -fPIC -DPIC -o .libs/mul_basecase.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_mul_basecase -DPIC mul_basecase.asm >tmp-mul_basecase.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-mul_basecase.s -fPIC -DPIC -o .libs/mul_basecase.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 mul_basecase.asm -o mul_basecase.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sqr_basecase | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f sqr_basecase.asm || echo './'`sqr_basecase.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sqr_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 sqr_basecase.asm  -fPIC -DPIC -o .libs/sqr_basecase.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sqr_basecase -DPIC sqr_basecase.asm >tmp-sqr_basecase.s
sqr_basecase.asm: 439: warning, simulating cmov with jump, use for testing only
sqr_basecase.asm: 440: warning, simulating cmov with jump, use for testing only
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sqr_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-sqr_basecase.s -fPIC -DPIC -o .libs/sqr_basecase.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sqr_basecase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 sqr_basecase.asm -o sqr_basecase.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo random | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o random.lo `test -f random.c || echo './'`random.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_random -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c random.c  -fPIC -DPIC -o .libs/random.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_random -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c random.c -o random.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo random2 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o random2.lo `test -f random2.c || echo './'`random2.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_random2 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c random2.c  -fPIC -DPIC -o .libs/random2.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_random2 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c random2.c -o random2.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sqrtrem | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o sqrtrem.lo `test -f sqrtrem.c || echo './'`sqrtrem.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sqrtrem -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sqrtrem.c  -fPIC -DPIC -o .libs/sqrtrem.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sqrtrem -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sqrtrem.c -o sqrtrem.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo get_str | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o get_str.lo `test -f get_str.c || echo './'`get_str.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_get_str -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c get_str.c  -fPIC -DPIC -o .libs/get_str.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_get_str -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c get_str.c -o get_str.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo set_str | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o set_str.lo `test -f set_str.c || echo './'`set_str.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_set_str -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c set_str.c  -fPIC -DPIC -o .libs/set_str.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_set_str -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c set_str.c -o set_str.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo scan0 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o scan0.lo `test -f scan0.c || echo './'`scan0.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_scan0 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c scan0.c  -fPIC -DPIC -o .libs/scan0.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_scan0 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c scan0.c -o scan0.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo scan1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o scan1.lo `test -f scan1.c || echo './'`scan1.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_scan1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c scan1.c  -fPIC -DPIC -o .libs/scan1.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_scan1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c scan1.c -o scan1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo popcount | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o popcount.lo `test -f popcount.c || echo './'`popcount.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_popcount -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c popcount.c  -fPIC -DPIC -o .libs/popcount.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_popcount -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c popcount.c -o popcount.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo hamdist | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o hamdist.lo `test -f hamdist.c || echo './'`hamdist.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_hamdist -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c hamdist.c  -fPIC -DPIC -o .libs/hamdist.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_hamdist -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c hamdist.c -o hamdist.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo cmp | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o cmp.lo `test -f cmp.c || echo './'`cmp.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_cmp -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c cmp.c  -fPIC -DPIC -o .libs/cmp.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_cmp -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c cmp.c -o cmp.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo perfsqr | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o perfsqr.lo `test -f perfsqr.c || echo './'`perfsqr.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_perfsqr -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c perfsqr.c  -fPIC -DPIC -o .libs/perfsqr.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_perfsqr -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c perfsqr.c -o perfsqr.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo bdivmod | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o bdivmod.lo `test -f bdivmod.c || echo './'`bdivmod.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_bdivmod -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c bdivmod.c  -fPIC -DPIC -o .libs/bdivmod.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_bdivmod -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c bdivmod.c -o bdivmod.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo gcd_1 | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o gcd_1.lo `test -f gcd_1.c || echo './'`gcd_1.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcd_1.c  -fPIC -DPIC -o .libs/gcd_1.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcd_1.c -o gcd_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo gcd | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o gcd.lo `test -f gcd.c || echo './'`gcd.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcd.c  -fPIC -DPIC -o .libs/gcd.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcd.c -o gcd.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo gcdext | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o gcdext.lo `test -f gcdext.c || echo './'`gcdext.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcdext -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcdext.c  -fPIC -DPIC -o .libs/gcdext.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_gcdext -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c gcdext.c -o gcdext.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo tdiv_qr | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o tdiv_qr.lo `test -f tdiv_qr.c || echo './'`tdiv_qr.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_tdiv_qr -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c tdiv_qr.c  -fPIC -DPIC -o .libs/tdiv_qr.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_tdiv_qr -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c tdiv_qr.c -o tdiv_qr.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dc_divrem_n | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o dc_divrem_n.lo `test -f dc_divrem_n.c || echo './'`dc_divrem_n.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dc_divrem_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c dc_divrem_n.c  -fPIC -DPIC -o .libs/dc_divrem_n.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dc_divrem_n -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c dc_divrem_n.c -o dc_divrem_n.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo sb_divrem_mn | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o sb_divrem_mn.lo `test -f sb_divrem_mn.c || echo './'`sb_divrem_mn.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sb_divrem_mn -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sb_divrem_mn.c  -fPIC -DPIC -o .libs/sb_divrem_mn.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sb_divrem_mn -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c sb_divrem_mn.c -o sb_divrem_mn.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo jacbase | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o jacbase.lo `test -f jacbase.c || echo './'`jacbase.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_jacbase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c jacbase.c  -fPIC -DPIC -o .libs/jacbase.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_jacbase -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c jacbase.c -o jacbase.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo copyi | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f copyi.asm || echo './'`copyi.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyi -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 copyi.asm  -fPIC -DPIC -o .libs/copyi.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_copyi -DPIC copyi.asm >tmp-copyi.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyi -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-copyi.s -fPIC -DPIC -o .libs/copyi.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyi -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 copyi.asm -o copyi.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo copyd | sed 's/_$//'`    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 `test -f copyd.asm || echo './'`copyd.asm
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyd -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 copyd.asm  -fPIC -DPIC -o .libs/copyd.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_copyd -DPIC copyd.asm >tmp-copyd.s
 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyd -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 tmp-copyd.s -fPIC -DPIC -o .libs/copyd.o
../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_copyd -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 copyd.asm -o copyd.o >/dev/null 2>&1
/bin/sh ../libtool --mode=link gcc  -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486   -o libmpn.la   mp_bases.lo udiv.lo umul.lo add.lo add_1.lo add_n.lo sub.lo sub_1.lo sub_n.lo mul_1.lo addmul_1.lo submul_1.lo lshift.lo rshift.lo dive_1.lo diveby3.lo divis.lo divrem.lo divrem_1.lo divrem_2.lo fib2_ui.lo mod_1.lo mod_34lsub1.lo mode1o.lo dump.lo mul.lo mul_fft.lo mul_n.lo mul_basecase.lo sqr_basecase.lo random.lo random2.lo sqrtrem.lo get_str.lo set_str.lo scan0.lo scan1.lo popcount.lo hamdist.lo cmp.lo perfsqr.lo bdivmod.lo gcd_1.lo gcd.lo gcdext.lo tdiv_qr.lo dc_divrem_n.lo sb_divrem_mn.lo jacbase.lo copyi.lo copyd.lo 
ar cq .libs/libmpn.a .libs/mp_bases.o .libs/udiv.o .libs/umul.o .libs/add.o .libs/add_1.o .libs/add_n.o .libs/sub.o .libs/sub_1.o .libs/sub_n.o .libs/mul_1.o .libs/addmul_1.o .libs/submul_1.o .libs/lshift.o .libs/rshift.o .libs/dive_1.o .libs/diveby3.o .libs/divis.o .libs/divrem.o .libs/divrem_1.o .libs/divrem_2.o .libs/fib2_ui.o .libs/mod_1.o .libs/mod_34lsub1.o .libs/mode1o.o .libs/dump.o .libs/mul.o .libs/mul_fft.o .libs/mul_n.o .libs/mul_basecase.o .libs/sqr_basecase.o .libs/random.o .libs/random2.o .libs/sqrtrem.o .libs/get_str.o .libs/set_str.o .libs/scan0.o .libs/scan1.o .libs/popcount.o .libs/hamdist.o .libs/cmp.o .libs/perfsqr.o .libs/bdivmod.o .libs/gcd_1.o .libs/gcd.o .libs/gcdext.o .libs/tdiv_qr.o .libs/dc_divrem_n.o .libs/sb_divrem_mn.o .libs/jacbase.o .libs/copyi.o .libs/copyd.o
ranlib .libs/libmpn.a
creating libmpn.la
(cd .libs && rm -f libmpn.la && ln -s ../libmpn.la libmpn.la)
make[7]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/mpn'
Making all in mpz
make[7]: Entering directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/mpz'
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o add.lo `test -f add.c || echo './'`add.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add.c  -fPIC -DPIC -o .libs/add.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add.c -o add.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o add_ui.lo `test -f add_ui.c || echo './'`add_ui.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add_ui.c  -fPIC -DPIC -o .libs/add_ui.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c add_ui.c -o add_ui.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o abs.lo `test -f abs.c || echo './'`abs.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c abs.c  -fPIC -DPIC -o .libs/abs.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c abs.c -o abs.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..    -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c -o aorsmul.lo `test -f aorsmul.c || echo './'`aorsmul.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=i486 -c aorsmul.c  -fPIC -DPIC -o .libs/aorsmul.o
aorsmul.c:44: error: conflicting types for `__gmpz_aorsmul'
aorsmul.c:39: error: previous declaration of `__gmpz_aorsmul'
make[7]: *** [aorsmul.lo] Error 1
make[7]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3/mpz'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2/gmp3'
make[4]: *** [gmp_all] Error 2
make[4]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp/gcl-2.6.2'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/home/magnus/usr/source/axiom/axiom/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/axiom'
make: *** [all] Error 2


\start
Date: 30 Jun 2004 10:23:17 -0400
From: Camm Maguire
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

Greetings, and thanks again for your report!

1) The problem first appears after loading tkl.o in the gcl subbuild.
   No sense looking past this point.  It would be helpful to follow
   the instructions I posted separately to examine this.

2) If you can provide remote ssh access, I'll try to look into it.
   The 2.15 binutils are not yet deemed stable enough to be in Debian
   unstable, but I doubt this is the problem in any case.  The other
   poster using gentoo was using 2.14, and the problem persists with
   different loading options.  So we either need the gdb backtrace, or
   ssh access to a sample machine to go further.

\start
Date: Wed, 30 Jun 2004 20:57:23 +0200
From: David Mentre
To: Magnus Larsson
Subject: Re: Axiom cvs 040624 build error

Magnus Larsson writes:

> The Makefile resides in:
> /usr/source/axiom/cvs-040624/axiom
>
> echo $AXIOM gives
> /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux

Aren't you sure you haven't made a copy/paste error?

In your case, if the sources are in 
/usr/source/axiom/cvs-040624/axiom
then $AXIOM should be
/usr/source/axiom/cvs-040624/axiom/mnt/linux

\start
Date: Wed, 30 Jun 2004 21:15:07 +0200
From: David Mentre
To: Martin Rubey
Subject: Re: Complex exponentiation and 0

Martin Rubey writes:

> If all of this is correct, could somebody who is entitled to do so 
>
> * add a comment to [bugs #9313] 0^0 handled inconsistently that it is not a
>   bug, (maybe simply include a pointer to this mail) but there are related bugs
>   described in [bugs #9424] Bug in handling 0^0 in Axiom
>
> * close it.

Done.

In fact, I created bug #9424 before seeing bug #9313.

Martin, if you want to take care of bugs, just create an account on
Savannah and I'm pretty sure Tim will aggree to give you admin accesses.

\start
Date: Wed, 30 Jun 2004 21:27:49 +0200
From: Magnus Larsson
To: David Mentre
Subject: Re: Axiom cvs 040624 build error

Hello David,

On Wednesday 30 June 2004 20.57, David Mentre wrote:
> Magnus Larsson writes:
> > The Makefile resides in:
> > /usr/source/axiom/cvs-040624/axiom
> >
> > echo $AXIOM gives
> > /home/magnus/usr/source/axiom/cvs-040624/axiom/mnt/linux
>
> Aren't you sure you haven't made a copy/paste error?
>
> In your case, if the sources are in
> /usr/source/axiom/cvs-040624/axiom
> then $AXIOM should be
> /usr/source/axiom/cvs-040624/axiom/mnt/linux
>

I am sorry, that was a typo in my post. I have $AXIOM set correctly in the 
build system.

> Yours,
> d.

\start
Date: Thu, 1 Jul 2004 00:42:33 -0400
From: Tim Daly
To: Camm Maguire
Subject: NX and exec-shield kernel summary

Camm,

I follow the Linux Kernel mailing list and this was a summary
posting of the NX (no execute) and exec-shield status:
 

4. 'NX' Security Features Coming To 2.6

2 Jun - 8 Jun (66 posts) Archive Link: "[announce] [patch] NX (No
eXecute) support for x86, 2.6.7-rc2-bk2"

Topics: Executable File Format, Microsoft, Security, Spam, Virtual
Memory People: Ingo Molnar, Linus Torvalds, Doug McNaught, Jakub
Jelinek, Brian Gerst, Christoph Hellwig, William Lee Irwin III, Andi
Kleen, Andy Lutomirski, Arjan van de Ven, Gerhard Mack, Jun Nakajima,
Rusty Russell

Ingo Molnar said on behalf of Red Hat:

we'd like to announce the availability of the following kernel patch:

http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

which makes use of the 'NX' x86 feature pioneered in AMD64 CPUs and
for which support has also been announced by Intel. (other x86 CPU
vendors, Transmeta and VIA announced support as well. Windows support
for NX has also been announced by Microsoft, for their next service
pack.) The NX feature is also being marketed as 'Enhanced Virus
Protection'. This patch makes sure Linux has full support for this
hardware feature on x86 too.

What does this patch do? The pagetable format of current x86 CPUs does
not have an 'execute' bit. This means that even if an application maps
a memory area without PROT_EXEC, the CPU will still allow code to be
executed in this memory. This property is often abused by exploits
when they manage to inject hostile code into this memory, for example
via a buffer overflow.

The NX feature changes this and adds a 'dont execute' bit to the PAE
pagetable format. But since the flag defaults to zero (for
compatibility reasons), all pages are executable by default and the
kernel has to be taught to make use of this bit.

If the NX feature is supported by the CPU then the patched kernel
turns on NX and it will enforce userspace executability constraints
such as a no-exec stack and no-exec mmap and data areas. This means
less chance for stack overflows and buffer-overflows to cause
exploits.

furthermore, the patch also implements 'NX protection' for kernelspace
code: only the kernel code and modules are executable - so even
kernel-space overflows are harder (in some cases, impossible) to
exploit. Here is how kernel code that tries to execute off the stack
is stopped:

 kernel tried to access NX-protected page - exploit attempt? (uid: 500)
 Unable to handle kernel paging request at virtual address f78d0f40
  printing eip:
 ...

The patch is based on a prototype NX patch written for 2.4 by Intel -
special thanks go to Suresh Siddha and Jun Nakajima @ Intel. The
existing NX support in the 64-bit x86_64 kernels has been written by
Andi Kleen and this patch is modeled after his code.

Arjan van de Ven has also provided lots of feedback and he has
integrated the patch into the Fedora Core 2 kernel. Test rpms are
available for download at:

http://redhat.com/~arjanv/2.6/RPMS.kernel/

the kernel-2.6.6-1.411 rpms have the NX patch applied.

here's a quickstart to recompile the vanilla kernel from source with
the NX patch:

http://redhat.com/~mingo/nx-patches/QuickStart-NX.txt

There were a lot of technical suggestions and comments from folks like
Christoph Hellwig, Andi Kleen, Rusty Russell, and Gerhard Mack. Also,
Linus Torvalds asked:

Just out of interest - how many legacy apps are broken by this? I
assume it's a non-zero number, but wouldn't mind to be happily
surprised.

And do we have some way of on a per-process basis say "avoid NX
because this old version of Oracle/flash/whatever-binary-thing doesn't
run with it"?

In answer to the first question, Ingo and Arjan van de Ven (also from
Red Hat) confirmed that the amount of legacy breakage was in fact
zero. Ingo also explained that just in case, any breakage from this
would be less than other breakage already introduced by Red Hat. He
put it, "in the full install of FC1 and FC2 the number is zero - and
Fedora has exec-shield which does a couple of things more: it makes
the heap non-executable as well [this broke X], it randomizes the
address-space layout and has a 4:4 VM [which broke the Sun JVM]." Doug
McNaught added, close by, "Lisp systems like CMUCL and SBCL (plus
commercial Lisps) had problems with FC1 due to execshield. They tend
to do things like compile code on the fly to heap memory and expect to
be able to run it." And Jakub Jelinek (also from Red Hat) replied,
"They will still work, as long as you don't recompile them with recent
toolchain. When you recompile them, they either needs to be taught to
DTRT (i.e. use mmap with PROT_EXEC for executable stuff), or can be
linked with -Wl,-z,execstack to mark them as needing executable
stack. prelink package also contains execstack(8) utility which can be
used on already linked binaries/shared libraries."

To Linus' second question, about the possibility of per-process
avoidance of NX for compatibility reasons, Ingo explained:

we have three mechanisms for this in Fedora:

   1.

      the PT_GNU_STACK flag itself - you can turn executability on/off
      compile-time or even after the fact via the execstack(8) utility
      Jakub wrote. This only affects the stack's executability - if an
      application assumes a non-PROT_EXEC mmap() can be executed it
      might still break with NX - but based on experience with Fedora
      Core i'd say there's almost no such application.

      this method works in 2.6 too, since it supports
      PT_GNU_STACK. gcc's PT_GNU_STACK mechanism is very conservative
      - e.g. if an application does an asm() then gcc assumes that it
      might rely on stack executability and emits the X
      flag. [applications can then turn this off in the source if
      stack executability is not required.] Likewise, if gcc emits
      trampolines then the X flag is emitted too. (glibc knows about
      PT_GNU_STACK all across - so e.g. if a nonexec stack application
      dlopen()s a library that needs stack executability then glibc
      makes the stack executable on the fly via
      PROT_GROWSDOWN/GROWSUP.)
   2.

      via a runtime method: via the i386 personality. So an
      application can trigger the 'legacy' Linux VM layout by e.g
      doing 'i386 java ./test.class'.

      this is a hack in Fedora - we wanted to have a finegrained
      runtime mechanism just in case. But it would be nice to have
      this upstream too - e.g. via a PERSONALITY_3G?

   3.

      via a kernel boot parameter (exec-shield=0)

      with the NX patch this becomes noexec=off [the same flag works
      on x86_64 too]. This method is the most inflexible one, and is a
      last-resort thing. (Fedora also has a runtime global switch to
      turn off the VM layout changes.)

here's a list of applications that we had to fix/work around in Fedora
when the VM layout changed:

    * emacs _rebuild_. (it coredumps itself during build ... xemacs is OK.)

    * some JDKs. Since they generate code and try to be as fast as
      possible they tend to rely more on VM details than normal
      applications.

    * X's module loader assumed that brk was executable. (fixed)

    * Wine. (it implements another OS so it's by definition very
      sensitive to layout changes.)

most of the breakages were unclean x86-only code that would have
broken if ported over to 64-bit anyway.

old, legacy applications dont have the PT_GNU_STACK flag so they all
work fine.

Regarding Wine's breakage when the Virtual Memory Subsystem changed,
Brian Gerst disagreed with Ingo's explanation, and remarked, "Wine
breaks because of the part of exec-shield that relocates shared libs
to low addresses, where the (stripped) Windows binaries expect to be
loaded at. NX stack doesn't affect it." Ingo accepted this, adding, "I
think Wine could get around this by creating a dummy ELF section in
the Wine binary that covers the first 1GB or so. Wine could still use
ordinary dynamic libraries - those would go above that 1GB. Then once
Wine has loaded up it can munmap() that first 1GB. (this would not
work if Wine has to dlopen() new libraries after this phase - does
that happen?)" But Christoph Hellwig suggested, "Why can't wine just
implement it's own binfmt_pecoff? Sounds like the much simpler
solutuion." And William Lee Irwin III said, "I'd be in favor of this
also. An executable format with wide enough usage is worth adding
kernel support for loading it."

Ingo replied also to his own long post, dealing with his item 2 above,
the runtime method of triggering the legacy Linux VM subsystem. He
said:

i've attached a patch that provides a cleaner solution. It does 3 changes:

    * it adds a ADDR_SPACE_EXECUTABLE bit to the personality 'bug
      bits' section. This bit if set will make the stack
      executable. (if in the future we decide to make the malloc()
      heap non-exec [which i definitely think we should], that
      property will also listen to this bit.)

    * in elf.h, it changes the x86 personality inheritance code to
      match that of x86_64 - which is a much saner method. This means
      if a complex app that does exec()s will all run with the
      personality of the parent(s).

    * in exec.c, since address-space executability is a
      security-relevant item, we must clear the personality when we
      exec a setuid binary. I believe this is also a (small) security
      robustness fix for current 64-bit architectures.

(the patch also adds a break to the elf_ex.e_phnum loop - there can
only be one STACK header in the binary and once we found it we should
not iterate through the remaining program headers (if any).)

we didnt want to add a non-standard personality flag to Fedora so we
abused PER_LINUX32 as the compatibility flag - but this only works on
x86. With the ADDR_SPACE_EXECUTABLE flag there would be a standard
method to fall back to 'legacy' executability assumptions Linux
applications might make.

Andi replied to the third item in the list above, regarding clearing
the 'personality' when executing a setuid binary. He said, "This means
I cannot easily force an i386 uname or 3GB address space on suid
programs anymore on x86-64. While in theory it could be a small
security problem I think the utility is much greater. It's hard to see
how setting NX could cause a security hole. The program may crash, but
it is unlikely to be exploitable." Andy Lutomirski replied:

The whole point of NX, though, is that it prevents certain classes of
exploits. If a setuid binary is vulnerable to one of these, then
Ingo's patch "fixes" it. Your approach breaks that.

I don't like Ingo's fix either, though. At least it should check
CAP_PTRACE or some such. A better fix would be for LSM to pass down a
flag indicating a change of security context. I'll throw that in to my
caps/apply_creds cleanup, in case that ever gets applied.

Andi thought it would be overkill to require an LSM module, but he
agreed that Andy had a good point, although Andi also objected, "that
only applies to the NX personality bit. For the uname emulation it is
not an issue. So maybe the dropping on exec should only zero a few
selected personality bits, but not all." This made sense to Andy; and
close by, Ingo said, "ok, how about the attached patch then? There's a
PERS_DROP_ON_SUID mask that we drop upon setuid - all the other
personality bits get inherited." Andy replied, "This is wrong on
SELinux (and presumably with other LSMs). It also does unexpected
things if you fail to exec a setuid executable." He posted his own
patch, and Linus Torvalds came in with:

Let's not do this at all.

Anything that changes subtle behaviour at suid-execute time is just
wrong. Imagine an app that has been tested in normal use, and then has
a subtle bug when executed set-uid, simply because the address space
layout changes. Or something that mysteriously works when you're root,
but not when you're anything else. Ouch.

I think we should just look at the executable itself, not whether it
is suid. If the executable says it is "NX-approved", then it's
NX-approved. End of story - just try to make sure that as many
executables as possible get compiled with the newer compiler suite
that enables it.

Add a tool to let people turn on/off the NX bit on an executable if it
turns out the executable can't work with it (let's say it was compiled
and tested on a CPU without NX support), and everybody should be
happy. You can have a trivial script that turns on the NX bit on all
the legacy apps too, and then if testing shows iot wasn't a good idea,
you can turn it off again on a per-executable basis.

Ingo did a bunch more work, posting patches; and Arjan also remarked,
"the prelink rpm on Fedora has such a tool" [to flip the NX bit on an
executable] "already fwiw. (it's part of prelink because the elf
manipulations needed are quite similar to the ones prelink does so
infrastructure is shared)" Linus replied:

Just for fun, can somebody that has the required hardware just test
old apps with NX turned on?

I know we used to put the signal handler trampoline on the stack, but
these days that should all be handled with the magic executable
syscall page, so _normally_ I don't think an old application should
even really care.

In fact, it would be interesting to just hear somebody running an
older distribution with a new CPU and a new kernel, and see just how
many programs need to be marked non-NX in "normal running".

Arjan replied, "I know that in a FC1 full install there are less than
5 binaries that don't run with NX. (one uses nested functions in C and
passes function pointers to the inner function around which causes gcc
to emit a stack trampoline, and gcc then marks the binary as non-NX,
the others have asm in them that we didn't fix in time to be properly
marked)." And Linus said:

If things are really that good, why are we even worrying about this?

It sounds like we should just have NX on by default even for
executables that don't have any NX info records, and have some way of
marking the (very few) executables that don't want it. Maybe have the
NX fault print a warning when it happens for an executable that
defaulted to NX on.

I think most people have seen the security disaster that causes most
of the emails on the net to be spam. So this should be _trivial_ to
explain to people when they complain about default behaviour breaking
their strange legacy app. Especially if there's a trivial tool to add
an elf section to make it work again.

So instead of having complex things to try to turn NX on for suid, we
should aim to turn ot on as widely as possible, _even_if_ that means
that people who upgrade hardware might have to do some trivial MIS
stuff.

Make a kernel bootup option to default to legacy mode if somebody
literally has trouble booting and fixing their thing due to "init" or
similar being one of the problematic cases. Together with a printk()
that says which executable triggered, it should be trivial to clean up
a system.

 

5. exec-shield Patch Updated For 2.6.7-rc2-bk2

2 Jun - 4 Jun (4 posts) Archive Link: "[patch] exec-shield patch for
2.6.7-rc2-bk2, integrated with NX" Topics: Big Memory Support People:
Ingo Molnar, Christoph Hellwig, Joe Korty

Ingo Molnar said:

Here's the latest exec-shield patch for 2.6.7-rc2-bk2, integrated with
the 'NX' feature (see the announcement from earlier today):

http://redhat.com/~mingo/exec-shield/exec-shield-on-nx-2.6.7-rc2-bk2-A7

you first have to apply the NX patch, which can be found at:

http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

prebuild kernel RPMs for Fedora Core 2, with this latest version of
exec-shield, are available at:

http://redhat.com/~arjanv/2.6/RPMS.kernel/

(kernel-2.6.6-1.411 has this latest, NX-aware exec-shield.)

if the CPU supports NX (and the kernel has been compiled with
CONFIG_HIGHMEM64G) then exec-shield will use NX to provide page-level
finegrained control over execution. On legacy CPUs that dont support
NX the segment-limit method is used to control execution (in a coarser
way). In the NX case the segment-limit is turned off altogether.

e.g. on an Athlon64 box the boot message looks:

NX (Execute Disable) protection: active

on a CPU without NX the boot message is:

NX (Execute Disable) protection: not present!
Using x86 segment limits to approximate NX protection

note: the NX patch will also protect against kernel-space code injection.

all the other components of exec-shield are identical between NX and
non-NX: the brk area is non-executable, libraries and PIE binaries are
moved into the ascii-shield as much as possible, and all aspects of
the address space are randomized.

Christoph Hellwig thought the patch was too big and included more
stuff than some folks would want. He asked, "Any chance to split this
up a bit? Having the pure non-exec stack (and maybe heap) would be
really nice while the randomization feature are a litte bit too much
security by obscurity for my taste." Joe Korty disagreed, "It's no
more security by obscurity than keeping your key secret is security by
obscurity. (One can think of the randomization as a white-noise key)."
Nevertheless, Ingo posted a new patch with the randomization code
removed. But he added, "but i still think randomization is useful as a
last-resort barrier, against worm-alike mass attacks. There's a huge
difference between a 1-packet infection and a 2-hour brute-force
search over broadband, in terms of the 'economy' of worms."





