\start
Date: Wed, 1 Sep 2004 11:35:29 -0400
From: Tim Daly
To: Martin Rubey
Subject: how to simplify exponents

                a 2a
2^a*2^(2*a) -> 2 2

               3a
simplify % -> 2

\start
Date: Fri, 3 Sep 2004 11:23:44 +0000
From: Martin Rubey
To: list
Subject: Re: how to simplify exponents

I wrote:
 >  > How can I make axiom to do 2^a*2^(2*a) -> 2^(3*a) ?
 > 
 > Ok, simplifyExp does that. But how about 
 > 
 > 2^a*4^a ?

Furthermore, I cannot convince Axiom to do

2^(5*a)/2^(4*a) -> 2^a

I'm rather disappointed, in fact, although it might as well be that I'm missing
something.

I'd be very grateful, if somebody could tell my how to make Axiom do the
following correctly. PLEASE start up Axiom and plug in the following:


--- the first 5 statements are just for setup, don't worry to much about them

x n == 2^(a*n);
k := 2;
p n == A-(k+3)*a1+a1*n;
q:=interpolate('n,[i for i in 1..k],[x(i)*p(i)^(-i) for i in 1..k])$PINTERP('n, EXPR INT)::EXPR INT;
eqs:=[(p(i)^i*eval(numerator(q),n=i)-x(i)*eval(denominator(q),n=i))::MPOLY([a1,A],EXPR INT) for i in k+1..k+3];

--- so far, everything works out just great. eqs is a List of three polynomials
--- in a1 and A with coefficients being expressions.

--- now I want to see, whether they have a common root. In fact, I know they
--- have: A=2^(a*n) and a1=0.

r1:=map(simplifyExp, resultant(eqs.1, eqs.3, a1)::UP(A, EXPR INT));

--- now we have eliminated a1. Since we know that A=2^(a*n) and a1=0 is a
--- common root of all three polynomials, evaluating r1 at A=2^(a*n) should
--- give 0. This does not work out as smooth as I'd hoped, but with a little
--- tweaking we get at least an answer that we can see to be zero:

simplifyExp(eval(r1 ,A=2^a))

--- similarly:

r2:=map(simplifyExp,resultant(eqs.2, eqs.3, a1)::UP(A, EXPR INT));

--- this even works out:

simplifyExp(eval(r2, A=2^a))

--- However, this is simply the wrong answer, it should contain A-2^a as a
--- factor:

gcd(r1, r2)

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

maybe the reason for that is, that Axiom cannot properly do

divide(r1,A-2^a)

HELP!

\start
Date: Fri, 03 Sep 2004 13:49:45 +0100
From: Nic Doye Nic Doye
To: list
Subject: Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined

Must be doing something stupid here.

(Desktop/dev is a symlink to dev in /home/nic).

I've tried with both yesterday's CVS and the 20040418 sources.

nic
---

[njd@e082 axiom]$ ./configure
 
You must set your AXIOM and PATH variables. Type:
 
export AXIOM=/home/nic/dev/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
 
To build the rest of the system type:
 
make
 
configure finished.
[njd@e082 axiom]$ make
0 SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom SYS=axiom SPD=/home/nic/Desktop/dev/axiom LSP=/home/nic/Desktop/dev/axiom/lsp GCLDIR=/home/nic/Desktop/dev/axiom/lsp/gcl-2.6.5 SRC=/home/nic/Desktop/dev/axiom/src INT=/home/nic/Desktop/dev/axiom/int OBJ=/home/nic/Desktop/dev/axiom/obj MNT=/home/nic/Desktop/dev/axiom/mnt ZIPS=/home/nic/Desktop/dev/axiom/zips TMP=/home/nic/Desktop/dev/axiom/obj/tmp SPADBIN=/home/nic/Desktop/dev/axiom/mnt/axiom/bin INC=/home/nic/Desktop/dev/axiom/src/include CCLBASE=/home/nic/Desktop/dev/axiom/obj/axiom/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/nic/Desktop/dev/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/nic/Desktop/dev/axiom/mnt/axiom/bin/lib/notangle
10 copying /home/nic/Desktop/dev/axiom/src/scripts to /home/nic/Desktop/dev/axiom/mnt/axiom/bin
1 making a axiom system, PART=cprogs SUBPART=everything
2 Environment SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom SYS=axiom SPD=/home/nic/Desktop/dev/axiom LSP=/home/nic/Desktop/dev/axiom/lsp GCLDIR=/home/nic/Desktop/dev/axiom/lsp/gcl-2.6.5 SRC=/home/nic/Desktop/dev/axiom/src INT=/home/nic/Desktop/dev/axiom/int OBJ=/home/nic/Desktop/dev/axiom/obj MNT=/home/nic/Desktop/dev/axiom/mnt ZIPS=/home/nic/Desktop/dev/axiom/zips TMP=/home/nic/Desktop/dev/axiom/obj/tmp SPADBIN=/home/nic/Desktop/dev/axiom/mnt/axiom/bin INC=/home/nic/Desktop/dev/axiom/src/include CCLBASE=/home/nic/Desktop/dev/axiom/obj/axiom/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/nic/Desktop/dev/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/nic/Desktop/dev/axiom/mnt/axiom/bin/lib/notangle
The root module <<Makefile.axiom>> was not defined.
make: *** [all] Error 3

\start
Date: Sat, 4 Sep 2004 02:39:57 -0400
From: Bill Page
To: Martin Rubey
Subject: re: how to simplify exponents

Martin,

I have found some ways to deal with the problems you mentioned
below. See

  http://page.axiom-developer.org/zope/mathaction/HowTo

I haven't had a chance to look closely at the more detailed
problems mentioned in the 2nd half of your message but I
have set it up here

  http://page.axiom-developer.org/zope/mathaction/AxiomProblem

on the MathAction wiki just as you presented in your email.
I hope to take a closer look at it in the next few days.

Cheers,
Bill Page.

> -----Original Message-----
> From: 
> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org 
> .org] On Behalf Of Martin Rubey
> Sent: Friday, September 03, 2004 7:24 AM
> To: list
> Subject: Re: how to simplify exponents
> 
> 
> I wrote:
>  >  > How can I make axiom to do 2^a*2^(2*a) -> 2^(3*a) ?
>  > 
>  > Ok, simplifyExp does that. But how about 
>  > 
>  > 2^a*4^a ?
> 
> Furthermore, I cannot convince Axiom to do
> 
> 2^(5*a)/2^(4*a) -> 2^a
> 
> I'm rather disappointed, in fact, although it might as well 
> be that I'm missing something.
> 
> ...

\start
Date: Sat, 04 Sep 2004 12:23:24 +0200
From: David Mentre
To: Nic Doye Nic Doye
Subject: Re: Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined

Hello Nic,

Nic Doye Nic Doye writes:

> export AXIOM=/home/nic/dev/axiom/mnt/linux
> export PATH=$AXIOM/bin:$PATH

Have you put those variables in your .bashrc or entered them in the
shell before doing make?

> [njd@e082 axiom]$ make
> 0 SPAD=/home/nic/Desktop/dev/axiom/mnt/axiom 
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> SYS=axiom
       ^^^^

I have on my own build:

SPAD=/home/david/pub/axiom-libre/i386-axiom/axiom/mnt/linux 
SYS=linux 

Be aware that the ./configure script of axiom is just a dummy script and
that you should set AXIOM and PATH variables manually.

I'm using following axiom_init shell alias that I call in my axiom
source directory:

    alias axiom_init='export AXIOM=`pwd`/mnt/linux;PATH=`pwd`/mnt/linux/bin:$PATH'


\start
Date: Mon, 6 Sep 2004 13:51:57 -0400
From: Tim Daly
To: list, axiom-math@nongnu.org
Subject: A3L 2005 in Honor of Volker Weispfenning]

FYI...

Date: Mon, 6 Sep 2004 16:45:51 +0200
From: "Dr. Andreas Dolzmann" <dolzmann@algebra.fmi.uni-passau.de>
Subject: A3L 2005 in Honor of Volker Weispfenning

Dear Friends and Collegues,

we would like to point you at a conference to be held in Passau,
Germany, in April 2005:

                  Algorithmic Algebra and Logic 2005
   Conference in Honor of the 60th Birthday of Volker Weispfenning

Please, find all relevant information at http://www.a3l.org/

Andreas Dolzmann
Andreas Seidl
Thomas Sturm

\start
Date: Tue, 07 Sep 2004 09:32:51 +0100
From: Nic Doye Nic Doye
To: list
Subject: Re: Attempt to build axiom on Fedora Core 2 fails: Makefile.axiom not defined

On Fri, 2004-09-03 at 13:49 +0100, Nic Doye wrote:
> Must be doing something stupid here.
> 
> (Desktop/dev is a symlink to dev in /home/nic).
> 
> I've tried with both yesterday's CVS and the 20040418 sources.

Hmm. Worked fine at home. PBKAC. Probably setting AXIOM to /usr/local/
axiom didn't help.

\start
Date: Tue, 07 Sep 2004 20:32:53 +0200
From: David Mentre
To: list
Subject: Axiom web site (was: Re: [Axiom-mail] Symbolic calculation with symbols)

Hello Bill,

Bill Page writes:

> Perhaps the following pages on MathAction will be of some use
> to you
>
> http://page.axiom-developer.org/zope/mathaction/UseProductAndSum
> http://page.axiom-developer.org/zope/mathaction/CreateIndexedVariables

As you are doing a very good job at maintaining an active web site, what
do you think of making your web site the reference web site for the
savannah Home Page link?

If yes, what link should we put? http://page.axiom-developer.org/ ?

\start
Date: Tue, 7 Sep 2004 14:49:48 -0400 
From: Bill Page
To: 'David MENTRE' David Mentre
Subject: RE: Axiom web site

David,

On Tuesday, September 07, 2004 2:33 PM you wrote:
> ... 
> As you are doing a very good job at maintaining an active web 
> site,

Thanks, I think... but I keep hoping that it becomes a shared
activity the way the designers of these through-the-web content
management systems intended it to be. :) Maybe that is beginning
to happen, but it is too soon to tell.

> what do you think of making your web site the reference web site
> for the savannah Home Page link?

First, the web site is really Tim Daly's web site. In fact so far
he is funding the hosting of this site entirely out of his own
pocket. This is a situation that I think should be resolved in a
more equitable and "official" manner - perhaps through donations?

Second, I am not sure what being a "reference web site" entails.

> 
> If yes, what link should we put? http://page.axiom-developer.org/ ?
> 

A few weeks ago I did add links to this site from the following
page:

  http://www.nongnu.org/axiom/community.html

by updating the webcvs at Savannah.

\start
Date: Tue, 07 Sep 2004 21:04:04 +0200
From: David Mentre
To: Bill Page
Subject: Re: Axiom web site
Cc: 'David MENTRE' David Mentre

Bill Page writes:

> Thanks, I think... but I keep hoping that it becomes a shared
> activity the way the designers of these through-the-web content
> management systems intended it to be. :) Maybe that is beginning
> to happen, but it is too soon to tell.

You probably noticed that I wasn't very active on Axiom recently and
that won't change in following months. But I do remember that at one
point in time, I'll have to contribute more concrete things than just a
few email comments. ;)

> First, the web site is really Tim Daly's web site. In fact so far
> he is funding the hosting of this site entirely out of his own
> pocket. This is a situation that I think should be resolved in a
> more equitable and "official" manner - perhaps through donations?

Perhaps Tim should have made more publicity on it. I wasn't aware of the
effort. Tim is probably more benevolent than dictator. :) And probably
adding a donation web page would be useful?

> Second, I am not sure what being a "reference web site" entails.

The first URL you should give is somebody is interested in Axiom.

> A few weeks ago I did add links to this site from the following
> page:
>
>   http://www.nongnu.org/axiom/community.html
>
> by updating the webcvs at Savannah.

Ok, very good idea.

\start
Date: Tue, 7 Sep 2004 15:16:11 -0400 
From: Bill Page
To: 'David MENTRE' David Mentre
Subject: RE: Axiom web site

David,

> > First, the web site is really Tim Daly's web site. In fact so far
> > he is funding the hosting of this site entirely out of his own
> > pocket. This is a situation that I think should be resolved in a
> > more equitable and "official" manner - perhaps through donations?
> 
> Perhaps Tim should have made more publicity on it. I wasn't aware
> of the effort. Tim is probably more benevolent than dictator. :)

{I am trying hard to think of an "American joke" to add here that
wouldn't offend anyone, but I've failed ... ;} But I think you are
right!

> And probably adding a donation web page would be useful?

I have mentioned this a couple of times to Tim, but we have
not yet reached any conclusion. Do you know what would be
involved in setting up an "official" donation web page? (I am
programmed to expect some bureaucracy - even on the web...)

> 
> > Second, I am not sure what being a "reference web site" entails.
> 
> The first URL you should give is somebody is interested in Axiom.
> 

Do you mean just the "homepage" link at

  http://savannah.nongnu.org/projects/axiom

or somewhere else?

\start
Date: Tue, 07 Sep 2004 21:32:23 +0200
From: David Mentre
To: Bill Page
Subject: Re: Axiom web site
Cc: 'David MENTRE' David Mentre

Bill,

Bill Page writes:

> not yet reached any conclusion. Do you know what would be
> involved in setting up an "official" donation web page? (I am
> programmed to expect some bureaucracy - even on the web...)

Sorry no.

Maybe as a first start: "send a check to Tim at address....". BTW, is it
difficult for american people to receive checks in euros?

> Do you mean just the "homepage" link at
>
>   http://savannah.nongnu.org/projects/axiom

Yep.

\start
Date: Fri, 10 Sep 2004 15:30:53 -0400
From: Tim Daly
To: axiom-math@nongnu.org, list
Subject: solving polynomial equations

General Solution for Polynomial Equations

http://arxiv.org/pdf/math.CA/0408264

the report is that a Dutch student found a formula to determine the
roots of any polynomial equation. Although an exact solution has been
proven impossible for higher orders, this is not the case for numerical
solutions.

\start
Date: Fri, 10 Sep 2004 23:19:23 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: mathaction
Cc: David Mentre

Martin,

I think the new content of

  http://page.axiom-developer.org/zope/MathAction

is "lookin' good". Thanks for all your work.

On Friday, September 10, 2004 1:47 PM you wrote:

> ...
> One new request: please remove all subpages of SandBox.
> It seems that I do not have permission to do so.
>

I looked at some of these pages and I think some of these are
still needed. Any page that contains

  RemoteWikiURL:

is involved in the weird way in which links outside the local
wiki are handled by ZWiki. If I recall correctly, some of these
(lib, cat, dom, etc.) I set up specifically to deal with the links
automatically generated when Axiom library code is compiled.
I will have to take another look at this and see which of these
are still necessary.

For now, I left the "delete page" permission dependent on first
being logged in at the Zope level of the system - something that
only I can do at the moment. Although my intention was to make
MathAction as open as possible, I thought that allowing simple
page deletions would be too much ... But depending just how
active you want to become (and how much responsibility you want
to take :), I would certainly be willing to give you these same
access rights. But let's take it slowly conservatively for now
until more than one of us knows where everything fits.

Continuing to exchange emails such as this is a good way for me
to write some of this down and I will do my best to move these
sort of design and documentation issues on to MathAction itself.
Which brings up another issue that concerns me a little - the
use of email and the email lists versus the "subscribe" option
on MathAction and Plone. Greater integration is possible but is
it really desirable?
 
Ok, back the issues at hand...

> I think we should now ask for permission to let
> 
> http://page.axiom-developer.org/zope/mathaction/FrontPage
>
> replace
>
> http://www.nongnu.org/axiom/
>

Do you mean the "homepage" link on Savannah? Since I have admin
rights for Axiom there, perhaps I can make this change? But
I don't know much (yet) about configuring things on Savannah...
Looking at several different projects on Savannah though, I see
that some of these do not use the http://www.nongnu.org/... link
for there homepages, so I guess what you suggest is possible.

> Most of the content is already in MathAction, I think that only
> obsolete things are missing, like the tutorial, which can be
> accessed only every second day, if at all.

I don't understand what you mean. Which tutorial? What problems
do you have accessing it?

> Also, I did not move the screenshots. I think that the only one
> which is still interesting is the one with TeXmacs, which would
> fit well into a section "Axiom IDE's". I'm using (Gnu) Emacs...
>

I like the idea of including some helpful information for stand
alone "Axiom Integrated Development Environments" like TeXmacs
users and Gnu Emacs, and I suppose also just the old native
interface. 

Tim and I (see 'doyen' on MathAction) have also been talking
about the possibility of setting up a single-user MathAction-
like environment for Axiom. The idea would be to allow an easy
transition from a private stand alone environment to and online
collaborative one like MathAction. For example, moving from TeXmacs
to MathAction could be quite traumatic for a user. In principle
making MathAction into a stripped down stand alone single user
environment is quite easy to do, but I just haven't had enough
time yet to do any serious work on this.

> I think it should really *replace* the old homepage. I think we
> should concentrate on *one* page, and I think that the MathAction
> wiki is the perfect tool for it.

The pages on http://www.nongnu.org/axiom/ were originally
developed by David Mentre (and/or a colleague of his). I think they
established a "nice look" for Axiom - one that I wasn't really
able to reproduce in the wiki environment. (It is possible to do
more under Plone, but I didn't spend much time at that either.)
The source for these pages is managed by CVS on Savannah as part
of the standard Savannah package. David (more or less) suggested
a few days ago that we do the same thing that you are suggesting
now - consolidate what we have now into a single "reference site"
for Axiom. But I would be happy if he first had a chance to review
the contents of your new pages to make sure that nothing of the
original intent gets lost before we complete this.

--------

I am also a little concerned about how we can (or if we should)
separate the purpose of MathAction itself, as a particular type
of interface to Axiom and Reduce and possibly others in the
future, versus it's role as the "home for Axiom". Do we really
want this "mix" of systems to be so prominent? Are there really
two *separate* goals here: 1) support Axiom, 2) promote the
"Rosetta" ideal of many different systems co-existing and growing
and working together?

The connection with Reduce through Tony Hearn is still very
tentative, although he does have a link to the Plone/ReduceWiki
page on the Reduce web site.

  http://reduce-algebra.com/projects.htm

I setup the http://page.axiom-developer.org/zope/Plone/reducewiki
page after a few brief emails with Tony. He wanted to put a
link to the work that I was doing with Reduce on his web site,
so I setup that page on Plone since it was more permanent that
anything I was doing on MathAction itself. Originally it only
pointed to the stuff on test.axiom-developer.org. But notice that
I changed it a couple of weeks ago when I moved the support for
Reduce to MathAction. Currently it contains links back to MathAction
and also to the test.axiom-developer.org site (for GNUplot).

The support for the GNUplot/Reduce interface is still a little
incomplete because it requires the user to invent a file name
and choose some device options that really should be fixed and
transparent in the ReduceWiki environment. Since this is still
under development, I didn't move the GNUplot stuff to MathAction
yet.

Anyway, perhaps making the distinction between Axiom support
and the broader Rosetta goals and support for Reduce, etc. is
just a matter of the right web site design for MathAction and/or
Plone? But MathAction is a wiki and kind of "fluid" by nature...

What do you think?

I am thinking (out loud) that maybe there is still a role for
http://www.nongnu.org/axiom/ ??

\start
Date: Fri, 10 Sep 2004 23:22:53 -0400
From: Bill Page
To: Martin Rubey
Subject: re: mathaction
Cc: David Mentre

Sorry. Corrected url:

> 
> I think the new content of
> 
>   http://page.axiom-developer.org/zope/mathaction
> 
> is "lookin' good". Thanks for all your work.
>
> ...

\start
Date: Sat, 11 Sep 2004 00:10:24 -0400
From: Tim Daly
To: Bill Page
Subject: Re: mathaction
Cc: David Mentre

Bill,

>For now, I left the "delete page" permission dependent on first
>being logged in at the Zope level of the system - something that
>only I can do at the moment. Although my intention was to make
>MathAction as open as possible, I thought that allowing simple
>page deletions would be too much ... But depending just how
>active you want to become (and how much responsibility you want
>to take :), I would certainly be willing to give you these same
>access rights. But let's take it slowly conservatively for now
>until more than one of us knows where everything fits.

It would be "oh-so-convenient" if the pages were backed into a CVS.
Of course, I realize that involves yet another level of work but I've
been meaning to express the idea. I've been watching your posts but
I'm hip-deep in things-to-do as school started this past week and the
world has returned from vacation.

\start
Date: Sat, 11 Sep 2004 12:23:32 +0000
From: Martin Rubey
To: Bill Page
Subject: RE: mathaction
Cc: David Mentre

Bill Page writes:
 > Martin,
 > 
 > I think the new content of
 > 
 >   http://page.axiom-developer.org/zope/MathAction
 > 
 > is "lookin' good". Thanks for all your work.

I'm flattered :-) 


 > On Friday, September 10, 2004 1:47 PM you wrote:
 > 
 > > ...
 > > One new request: please remove all subpages of SandBox.
 > > It seems that I do not have permission to do so.

To make it short: it's OK, leave permissions that way. The only reason to
delete a page is that the navigator doesn't look too good with all the old
links around. I simply removed the content of the "disturbing" pages. I believe
that I moved all the "good" content to the new pages, if something is lost, we
can dig it up from the diffs anyway.

 > Continuing to exchange emails such as this is a good way for me
 > to write some of this down and I will do my best to move these
 > sort of design and documentation issues on to MathAction itself.
 > Which brings up another issue that concerns me a little - the
 > use of email and the email lists versus the "subscribe" option
 > on MathAction and Plone. Greater integration is possible but is
 > it really desirable?

I like it the way it is. It might happen anyway that parts of the discussions
on axiom-developer, axiom-mail and axiom-math move to mathaction. I wouldn't
force that. First priority should be the integration of pamphlets, I believe.
  
 > Ok, back the issues at hand...
 > 
 > > I think we should now ask for permission to let
 > > 
 > > http://page.axiom-developer.org/zope/mathaction/FrontPage
 > >
 > > replace
 > >
 > > http://www.nongnu.org/axiom/
 > >
 > 
 > Do you mean the "homepage" link on Savannah? Since I have admin
 > rights for Axiom there, perhaps I can make this change? 

Yes.

 > > Most of the content is already in MathAction, I think that only
 > > obsolete things are missing, like the tutorial, which can be
 > > accessed only every second day, if at all.
 > 
 > I don't understand what you mean. Which tutorial? What problems
 > do you have accessing it?

The tutorial of Martin N. Dunstan. I had a bad link, I'll add it just below the
book.

 > > Also, I did not move the screenshots. I think that the only one
 > > which is still interesting is the one with TeXmacs, which would
 > > fit well into a section "Axiom IDE's". I'm using (Gnu) Emacs...
 > >
 > I like the idea of including some helpful information for stand
 > alone "Axiom Integrated Development Environments" like TeXmacs
 > users and Gnu Emacs, and I suppose also just the old native
 > interface. 

Well, maybe somebody reading this will volunteer... It's priority level "2" for
me. 

 > Tim and I (see 'doyen' on MathAction) have also been talking
 > about the possibility of setting up a single-user MathAction-
 > like environment for Axiom. The idea would be to allow an easy
 > transition from a private stand alone environment to and online
 > collaborative one like MathAction. For example, moving from TeXmacs
 > to MathAction could be quite traumatic for a user. In principle
 > making MathAction into a stripped down stand alone single user
 > environment is quite easy to do, but I just haven't had enough
 > time yet to do any serious work on this.

Low priority for me.

 > > I think it should really *replace* the old homepage. I think we
 > > should concentrate on *one* page, and I think that the MathAction
 > > wiki is the perfect tool for it.
 > 
 > The pages on http://www.nongnu.org/axiom/ were originally
 > developed by David Mentre (and/or a colleague of his). I think they
 > established a "nice look" for Axiom - one that I wasn't really
 > able to reproduce in the wiki environment. 

This is very true, they are *very* beautiful! In fact, I tried to imitate a
little bit, but I failed. However, I have such a strong affection to the
underlying system of mathaction, that I propose to make this move. Furthermore,
I hope that beauty will evolve, given some time. In fact, I think that the new
FrontPage is still too crowded, but I didn't want to spend more time on it
right now. http://www.nongnu.org/axiom/ is very concise (in the sense of
"uebersichtlich"), I hope FrontPage will become more like this when the layout
of the wiki becomes clearer.

 > David (more or less) suggested
 > a few days ago that we do the same thing that you are suggesting
 > now - consolidate what we have now into a single "reference site"
 > for Axiom. But I would be happy if he first had a chance to review
 > the contents of your new pages to make sure that nothing of the
 > original intent gets lost before we complete this.

Yes. No need to hurry. I think a great point to switch would be when the
pamphlets are integrated. 

 > I am also a little concerned about how we can (or if we should)
 > separate the purpose of MathAction itself, as a particular type
 > of interface to Axiom and Reduce and possibly others in the
 > future, versus it's role as the "home for Axiom". Do we really
 > want this "mix" of systems to be so prominent? 

I thought about this too. No conclusion yet, sorry.

 > Are there really
 > two *separate* goals here: 1) support Axiom, 2) promote the
 > "Rosetta" ideal of many different systems co-existing and growing
 > and working together?

We might be very welcome in mupad-combinat circles.


 > ... (big part skipped) ...
 > 
 > Anyway, perhaps making the distinction between Axiom support
 > and the broader Rosetta goals and support for Reduce, etc. is
 > just a matter of the right web site design for MathAction and/or
 > Plone? But MathAction is a wiki and kind of "fluid" by nature...

 > What do you think?
 
I thinking that you are a little to afraid of this sort of freedom. I think
that axiom is too small to be a worthy target of vandalism, if we become one,
we can take measures then. I don't see any other possible problems with
fluidity. Time will tell.

 > I am thinking (out loud) that maybe there is still a role for
 > http://www.nongnu.org/axiom/ ??

I'd suggest that we don't decide this right now.

Thanks a lot for your work, and for your thoughts,

\start
Date: Sat, 11 Sep 2004 14:31:29 +0000
From: Martin Rubey
To: list
Subject: bug? in integrate and question about rf

Isn't this a bug?

integrate(x^n,x)

            n log(x)
        x %e
   (1)  ------------
            n + 1
       

I think that axiom should conditionalize here on n being zero or not. (Though
I'm not aware whether this is possible currently)

Second thing: I tried to "fix" (experimentally)

(1/x)::UP(x, FRAC POLY INT) not giving an error.

I intended to change the coercion in UP(x, R) from R to % (which is not
instantiated currently) to test whether x occurs as a variable in r, and, if
so, spit out an error. (footnote1)

In fact, taylor does something similar:

    if Coef has Algebra Fraction Integer then
      coerce(r:RN) == r :: Coef :: %

      integrate x == integrate(0,stream x)$STT
      integrate(x:%,v:Variable(var)) == integrate x

      if Coef has integrate: (Coef,Symbol) -> Coef and _
         Coef has variables: Coef -> List Symbol then
        integrate(x:%,s:Symbol) ==
          (s = variable(x)) => integrate x
          not entry?(s,variables center x) => map(integrate(#1,s),x)
          error "integrate: center is a function of variable of integration"

However, there is a tiny inaccuracy here, since

FRAC POLY INT does not have variables: Coef -> List Symbol.

Hence:

integrate((1/y)::UTS(FRAC POLY INT, x, 0),z)

does not work, although it should.

For fractions, the function variables is in the packages POLYCATQ and RF, who
need to know over which domain the ring of fractions is build. As we know, the
compiler is not able to find out which domain this is. For example, suppose F
is a Field, although it is possible to define

Test(F:Field, R: IntegralDomain): Exports == Implementation where

  Exports ==> with
    if F has QFCAT R then
      variables   : F -> List Symbol


but you cannot use this function, if you are given only the Field, but not the
Integraldoman. 

An obvious solution is to move the function variables into QFCAT. Does anybody
know whether there is a (profound) reason not to do so?

Martin

(footnote1) This is not quite correct, but nearly. The right thing would be to
make the coercion only possible, if r is free of x. I don't know whether this
would be possible.

\start
Date: Sat, 11 Sep 2004 07:32:07 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey,
Subject: re: mathaction
Cc: David Mentre

For whatever it's worth, I think the nice look of
http://www.nongnu.org/axiom/ should remain the homepage for now. 
Remember, new users of Axiom will be the ones the webpage will be
trying to reach - experienced folk will migrate to the more interesting
and dynamic MathAction environment.  I'd say the homepage isn't the
time to hit them with a lot of extra new concepts - the "default"
newbie starting point should always be as straight forward as possible.
 Again, just my own opinion.

Congrats on the really impressive work you guys are doing!

\start
Date: Sat, 11 Sep 2004 21:31:26 -0400
From: Bill Page
To: Martin Rubey
Subject: re: mathaction
Cc: David Mentre

Martin,

On Saturday, September 11, 2004 8:24 AM you wrote:
> ...
> [Bill Page wrote:]
>> Are there really two *separate* goals here: 1) support
>> Axiom, 2) promote the "Rosetta" ideal of many different
>> systems co-existing and growing and working together?
> 
> We might be very welcome in mupad-combinat circles.
>

What the mupad-combinat people are doing sounds interesting.

  http://mupad-combinat.sourceforge.net/

They even have a wiki!

  http://mupad-combinat.sourceforge.net/Wiki/HomePage.html

The last time I looked at MuPad I was very impressed

  http://research.mupad.de/

And they seem to have continued to develop as a potentially
serious competitor to Maple while moving to a more "Axiom-like"
approach to mathematical content.

But I was rather turned off by their apparent move towards
commercialization rather than an open source philosophy.

Does anyone here have a direct contact with the MuPad Research
Group at Paderborn? If so, I would very much like to seek their
opinion on the possibility of being included in MathAction. I
would be quite willing to invest some time in implementing
the wiki interface for MuPad.

For that matter I am also strongly motivated to implement an
interface for Maple, but currently poorly conceived (in my
opinion) licensing restrictions prevent me from doing this.
Perhaps the situation with MuPad is different?

  http://research.mupad.de/licenses.html

However as far as I can tell from the above, their current
license would not allow us to setup open access over-the-web
to MuPad the way we have now for Axiom and Reduce.

> 
>> ... (big part skipped) ...
>> 
>> Anyway, perhaps making the distinction between Axiom support
>> and the broader Rosetta goals and support for Reduce, etc.
>> is just a matter of the right web site design for MathAction
>> and/or Plone? But MathAction is a wiki and kind of "fluid" by
>> nature...
> 
>  > What do you think?
>  
> I thinking that you are a little to afraid of this sort of 
> freedom. I think that axiom is too small to be a worthy target
> of vandalism, if we become one, we can take measures then.
> I don't see any other possible problems with fluidity. Time
> will tell.

I agree with your views. I wasn't worried about vandalism but
rather about maintaining a productive collaborative spirit
between all of the potential contributors. To me, the content
of this sort of web site is secondary to the main goal of
fostering collaboration. Perhaps there is some (small) risk
of loosing significant content or of malicious use etc.  But
if at least three people are willing to run with this open
door policy (you, me and Tim) then that's ok with me.

\start
Date: Sun, 12 Sep 2004 18:45:04 +0000
From: Martin Rubey
To: Bill Page
Subject: re: mathaction
Cc: David Mentre

Bill Page writes:
 > Martin,
 > 
 > On Saturday, September 11, 2004 8:24 AM you wrote:
 > > ...
 > > [Bill Page wrote:]
 > >> Are there really two *separate* goals here: 1) support
 > >> Axiom, 2) promote the "Rosetta" ideal of many different
 > >> systems co-existing and growing and working together?
 > > 
 > > We might be very welcome in mupad-combinat circles.
 > >
 > 
 > What the mupad-combinat people are doing sounds interesting.
 > 
 >   http://mupad-combinat.sourceforge.net/
 > 
 > They even have a wiki!
 > 
 >   http://mupad-combinat.sourceforge.net/Wiki/HomePage.html
 > 
 > The last time I looked at MuPad I was very impressed
 > 
 >   http://research.mupad.de/
 > 
 > And they seem to have continued to develop as a potentially
 > serious competitor to Maple while moving to a more "Axiom-like"
 > approach to mathematical content.

Yes, they are *very* strong. One reason for this is that MuPad is free for
scientists in France, as far as I know. In fact, if MuPad became free, I think
there would be little to no space left for axiom.

 > Does anyone here have a direct contact with the MuPad Research
 > Group at Paderborn? If so, I would very much like to seek their
 > opinion on the possibility of being included in MathAction. I
 > would be quite willing to invest some time in implementing
 > the wiki interface for MuPad.

I know Nicolas Thiery. I'm pretty sure he would love to help you.

 > For that matter I am also strongly motivated to implement an
 > interface for Maple, but currently poorly conceived (in my
 > opinion) licensing restrictions prevent me from doing this.
 > Perhaps the situation with MuPad is different?
 > 
 >   http://research.mupad.de/licenses.html
 > 
 > However as far as I can tell from the above, their current
 > license would not allow us to setup open access over-the-web
 > to MuPad the way we have now for Axiom and Reduce.

It might well be, that Nicolas can negotiate this for you.

\start
Date: Fri, 17 Sep 2004 11:30:01 +0000
From: Martin Rubey
To: Manuel Bronstein, Ralf@Hemmecke.de, William Sit
Subject: Re: conditionally defined functions

Dear Manuel, Ralf, Tim, William, *,

I'm struggling with something, maybe you are able to help. If not please tell
me so. 

As you might know, I'm experimenting with fixes of the following, superficially
strange behaviour: 


(1) -> (1/x)::UP(x, FRAC POLY INT)

        1
   (1)  -
        x
                    Type: UnivariatePolynomial(x,Fraction Polynomial Integer)


Well, I think that this is calling for trouble. So, one way to fix this is to
make coerce(coef:R)-> % of UP, MPOLY and the like (in fact, are there others?)
check whether or not coef contains one of the variables -- in this case x. In
fact, I believe this is the "right" approach.

In principle, this is not too difficult. However, there is a slight subtlety:
Currently not all domains that contain variables provide such a function, in
particular, FRAC does not. Instead, there is a package RF that provides this
functionality. Well, no problem:

* move the operation variables from RF and POLYCATQ to QFCAT : 

    if S has variables: S -> List Symbol then
      variables: % -> List Symbol
      variables f ==
         mymerge(variables(numer(f)), variables(denom(f)))

and add the following to UP and MPOLY : 

    if R has variables: R -> List Symbol then
      coerce(r:R):% ==
        if member?(x, variables(r)) then
          error "coefficient contains variable"
        else coerce(r)$Rep

This works, it seems. However, there are two things I don't like about this
"fix":

* the function "variables" thus (conditionally) provided in QFCAT is only one
  of many. I don't know of an example, but POLYCAT (which defines variables
  originally) defines variables : % -> VarSet (which is a member of the
  Category OrderedSet). So, for example, since SUP specialises VarSet to be
  SingletonAsOrderedSet, FRAC UP won't have a function variables.
 
* philosophically, this is not very beautiful. But I don't see another way to
  overcome the problem. 

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

However, I don't really see how this could be used. I modified POLYCAT to
contain a function

varset: () -> OrderedSet
varset () == VarSet

but I was not able to do anything useful with this. Of course, what I'd like to
say in QFCAT would be 

I'd like to be able to say in QFCAT something like:

    if S has varset: () -> OrderedSet then
      variables: % -> List varset()
      variables f ==
         mymerge(variables(numer(f)), variables(denom(f)))

But this looks fishy.

So, in more general terms, here's my question:

Suppose you have a category A, taking as parameter a domain P and providing an
operation f: % -> P. Furthermore, you have a category (or a domain, a package)
B, taking as parameter a domain Q. Now you want to achieve the following:

If Q is a domain in A, provide a function g: % -> P, using f.

Of course, it is not possible to provide P as a parameter of B, since B should
also be defined for Q's that are not domains in A...

I suspect that this is the reason for making RationalFunction a
package. However, this does not provide the full functionality, as you can see
from the problem above. 

Did I get something backwards, is there another solution?

\start
Date: Fri, 17 Sep 2004 12:52:42 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: conditionally defined functions

Hi Martin,

> Suppose you have a category A, taking as parameter a domain P and providing an
> operation f: % -> P. Furthermore, you have a category (or a domain, a package)
> B, taking as parameter a domain Q. Now you want to achieve the following:
> 
> If Q is a domain in A, provide a function g: % -> P, using f.

Let me translate this into some code...

define A(P: Cat1): Category == with {
   f: % -> P;
}

-- Assume B should be a domain.
B(Q: Cat2): Cat3 with {
   if Q has A(???) then {g: % -> ???}
}

To me it seems that in order to state that "Q is a domain in A" one 
would have to know the parameter of A. Note that A is a function 
returning a category. The ??? should be something of type Cat1. And I 
don't see this information somewhere available inside the definition of B.

I guess that is not your point. Can you be more precise here?

\start
Date: Fri, 17 Sep 2004 15:14:49 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: conditionally defined functions

Ralf HEMMECKE writes:
 > Hi Martin,
 > 
 > > Suppose you have a category A, taking as parameter a domain P and providing an
 > > operation f: % -> P. Furthermore, you have a category (or a domain, a package)
 > > B, taking as parameter a domain Q. Now you want to achieve the following:
 > > 
 > > If Q is a domain in A, provide a function g: % -> P, using f.
 > 
 > Let me translate this into some code...
 > 
 > define A(P: Cat1): Category == with {
 >    f: % -> P;
 > }
 > 
 > -- Assume B should be a domain.
 > B(Q: Cat2): Cat3 with {
 >    if Q has A(???) then {g: % -> ???}
 > }
 > 
 > To me it seems that in order to state that "Q is a domain in A" one 
 > would have to know the parameter of A. Note that A is a function 
 > returning a category. The ??? should be something of type Cat1. And I 
 > don't see this information somewhere available inside the definition of B.
 > 
 > I guess that is not your point. Can you be more precise here?

Hmm, I think it is my point indeed. I don't know Aldor syntax, but my idea was
roughly

 define A(P: Cat1): Category == with {
    arg: () -> Cat1
    f: % -> P;
 -- the operation arg returns a domain...
    arg () == P
 }



 -- Assume B should be a domain.
 B(Q: Cat2): Cat3 with {
    if Q has arg: () -> Cat1 then {g: % -> arg()}
 }

Thanks for replying that fast,

\start
Date: Fri, 17 Sep 2004 15:38:06 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: conditionally defined functions

Hi Martin,

> As you might know, I'm experimenting with fixes of the following, superficially
> strange behaviour: 
> 
> 
> (1) -> (1/x)::UP(x, FRAC POLY INT)
> 
>         1
>    (1)  -
>         x
>                     Type: UnivariatePolynomial(x,Fraction Polynomial Integer)

Hmm, when I simply type 1/x, I get:

         1
    (4)  -
         x
                              Type: Fraction Polynomial Integer

So coercing this into UP(x, FRAC POLY INT) is OK. It only looks a bit 
strange, because you might want to get an error message telling you that 
you cannot have x in the denominator.

I made the following experiment:

(5) -> X := monomial(1,1)$UP(x, FRAC POLY INT)
    (5)  x
           Type: UnivariatePolynomial(x,Fraction Polynomial Integer)
(8) -> inv X

         1
    (8)  -
         x
      Type: Fraction UnivariatePolynomial(x,Fraction Polynomial Integer)
(9) -> 1/X

         1
    (9)  -
         x
        Type: UnivariatePolynomial(x,Fraction Polynomial Integer)

That the types are different is really a bit strange.


If I posed the question:

Is UP(x, FRAC POLY INT) = FRAC POLY INT ?

What would you answer? I am not asking for equality of the domains in 
AXIOM, but rather what FRAC POLY INT is mathematically.

\start
Date: Fri, 17 Sep 2004 15:56:55 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: conditionally defined functions

Hi Martin,

> Hmm, I think it is my point indeed. I don't know Aldor syntax, but my idea was
> roughly
> 
>  define A(P: Cat1): Category == with {
>     arg: () -> Cat1
>     f: % -> P;
>  -- the operation arg returns a domain...
>     arg () == P
>  }
> 
> 
> 
>  -- Assume B should be a domain.
>  B(Q: Cat2): Cat3 with {
>     if Q has arg: () -> Cat1 then {g: % -> arg()}
>  }

Oje, I guess that is too much to hope for. I am not one of the language 
designers, but since everything in Aldor/Axiom is first class in 
principle it should work.

There is, however, a little problem which is not so obvious in your 
"argument code arg()". What if I say the following?

DomA(P1: Cat1, P2: Cat1): A(P1) == add {
   b: Boolean := false;
   arg(): Cat1 := {
	free b;
	b := not b;
	if b then P1 else P2;
   }
   ...
}

Now, what is the type of B(DomA(P1,P2))? Does
   B(DomA(P1,P2))
have the same type as
   B(DomA(P1,P2))?

\start
Date: 17 Sep 2004 10:43:02 -0400
From: Camm Maguire
To: Bill Page
Subject: re: mathaction
Cc: David Mentre

Greetings, all!  The site looks great!  I just have one request -- it
should be made clear early on that reduce is not open source software.
It appears from their site that they are selling the source under some
circumstances however (cannot see where though).  It would be helpful
if someone could report on whether their conditions would allow
inspection of the source for use in spotting bugs in axiom.  Am also
wondering if standard lisp, as a 'subset', will run on gcl much as the
'applicative common lisp' subset does in acl2.

\start
Date: Fri, 17 Sep 2004 16:12:05 +0100 (GMT Daylight Time)
From: Arthur Norman
To: Camm Maguire
Subject: re: mathaction
Cc: David Mentre, Bill Page

On Fri, 17 Sep 2004, Camm Maguire wrote:
> Greetings, all!  The site looks great!  I just have one request -- it
> should be made clear early on that reduce is not open source software.
> It appears from their site that they are selling the source under some
> circumstances however (cannot see where though).  It would be helpful
> if someone could report on whether their conditions would allow
> inspection of the source for use in spotting bugs in axiom.  Am also
> wondering if standard lisp, as a 'subset', will run on gcl much as the
> 'applicative common lisp' subset does in acl2.
>
> Take care,
> --
If you follow www.reduce-algebra.com you will find that a "personal" 
version of Reduce is available (for perhaps a limited range of platforms) 
and that comes without source, and there is a "professional" version that 
comes with source (and in some cases  full source of the Lisp use dto 
build it). And of course multiple-installation and site licenses are also 
available.
Reduce has two distributors who use different Lisp systems, both 
conforming to "standard lisp". At one stage a mapping of that onto Common 
Lisp was available but that is no longer supported or available. One of 
the versions of Reduce is built on and comes with my "CSL" Lisp system and 
when NAG distributed Axiom I had adjustments to that that supported enough 
of the common lisp-isms that Axiom built on it. To my mind the key 
featuures of what was done there were that (a) one compiled image file 
could then be run on almost any platform (windows, linux, lots of sorts of 
Unix) so the need for per-platform compilation of all that Lisp was 
removed. And platform-specific glitches and incompatibilities would be 
minimised. (b) at the time Axiom was notably a resource hog by the 
standard of workstations available and "CCL" (thing S=standard, C=common, 
L=lisp, c=Codemist) allowed it to run with a relatively modest footprint.

Note that some in the new Axiom world have declared use of CCL to be one 
of the worst mistakes anybody ever made wrt Axiom and that my Lisp is thus 
to be abhored.. so do not get too enthusiastic.

\start
Date: 17 Sep 2004 11:17:57 -0400
From: Camm Maguire
To: Martin Rubey
Subject: re: mathaction
Cc: David Mentre, Bill Page

Greetings!

Martin Rubey writes:

> Bill Page writes:
>  > The last time I looked at MuPad I was very impressed
>  > 
>  >   http://research.mupad.de/
>  > 
>  > And they seem to have continued to develop as a potentially
>  > serious competitor to Maple while moving to a more "Axiom-like"
>  > approach to mathematical content.
> 
> Yes, they are *very* strong. One reason for this is that MuPad is free for
> scientists in France, as far as I know. In fact, if MuPad became free, I think
> there would be little to no space left for axiom.
> 

This is our challenge.  Do the mathematicians of the world have enough
spare brain cycles to move beyond the position of a mere consumer
choosing among whatever best black box happens to be available for the
task at hand, to the position of a part-time contributor to a system
permanently owned by the public, and in which the knowledge of *how*
something is done is available at any time to anyone who desires to
read?  To look at the immense complexity of the Linux kernel, gcc,
etc., the challenge is not impossible.  But it is critical that we
prioritize, organize, and gain a community of minds *very* familiar
with the details of the system.  I am the worst offender as the only
thing in which I'm any kind of expert at present is gcl.

If someone can suggest a good, high priority, somewhat manageable
task, I'm willing to do my part.

\start
Date: Fri, 17 Sep 2004 18:03:24 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: conditionally defined functions

Hi Ralf,

Ralf HEMMECKE writes:
 > Hi Martin,
 > 
 > > As you might know, I'm experimenting with fixes of the following, superficially
 > > strange behaviour: 
 > > 
 > > 
 > > (1) -> (1/x)::UP(x, FRAC POLY INT)
 > > 
 > >         1
 > >    (1)  -
 > >         x
 > >                     Type: UnivariatePolynomial(x,Fraction Polynomial Integer)
 > 
 > Hmm, when I simply type 1/x, I get:
 > 
 >          1
 >     (4)  -
 >          x
 >                               Type: Fraction Polynomial Integer
 > 
 > So coercing this into UP(x, FRAC POLY INT) is OK. 

Well, I think it shouldn't. But maybe I'm wrong. But in the latter case, I'd
argue that UP(x, FRAC POLY INT) should be a forbidden type.

 > It only looks a bit strange, because you might want to get an error message
 > telling you that you cannot have x in the denominator.
 > 
 > I made the following experiment:
 > 
 > (5) -> X := monomial(1,1)$UP(x, FRAC POLY INT)
 >     (5)  x
 >            Type: UnivariatePolynomial(x,Fraction Polynomial Integer)
 > (8) -> inv X
 > 
 >          1
 >     (8)  -
 >          x
 >       Type: Fraction UnivariatePolynomial(x,Fraction Polynomial Integer)
 > (9) -> 1/X
 > 
 >          1
 >     (9)  -
 >          x
 >         Type: UnivariatePolynomial(x,Fraction Polynomial Integer)
 > 

that's interesting. I like (8), but I dislike (9).

 > That the types are different is really a bit strange.
 > 
 > 
 > If I posed the question:
 > 
 > Is UP(x, FRAC POLY INT) = FRAC POLY INT ?
 > 
 > What would you answer? I am not asking for equality of the domains in 
 > AXIOM, but rather what FRAC POLY INT is mathematically.


I'd answer: well...no

FRAC POLY INT is the domain of fractions of polynomials with integer coeffs.

UP(x, FRAC POLY INT) is the domain of univariate polynomials in x, having
fractions of polynomials with integer coeffs as coeffs.

But the latter type makes sense only if you don't allow x to "appear" in the
coefficients.

Note that 

(1) -> x::UP(x, FRAC MPOLY([x], INT))
 
   UnivariatePolynomial(x,Fraction MultivariatePolynomial([x],Integer))
      is not a valid type.

(1) -> x::UP(x, FRAC MPOLY([y], INT))
   (1)  x
   Type: UnivariatePolynomial(x,Fraction MultivariatePolynomial([y],Integer))

\start
Date: Fri, 17 Sep 2004 12:33:52 -0400
From: Bill Page
To: "'Arthur Norman'" Arthur Norman
Subject: re: mathaction
Cc: Camm Maguire, David Mentre

On Friday, September 17, 2004 11:12 AM Arthur Norman
Arthur Norman
> ... 
> Note that some in the new Axiom world have declared use of 
> CCL to be one of the worst mistakes anybody ever made wrt
> Axiom and that my Lisp is thus to be abhored.. so do not
> get too enthusiastic.
> 

I may not hear everything that get said about "the new
Axiom world" but I have certainly never heard anyone make
such a statement about CCL and axiom! In fact the full source
of CCL including the Axiom specific parts is still included
in the Axiom CVS with the expectation that someone somewhere
would go to the trouble of re-integrating CCL and Axiom as
a buildable platform. I tried this myself almost two years
ago in the hopes of getting quickly to a running Windows
version of open source Axiom but my lack of experience and
lack of sufficient time got in the way.

It seems to me that the current emphasis on GCL and Axiom
is only a result of personal choices and limited resources.

We are apparently close to having a running version of
Axiom using GCL on Windows but still some problems well
beyond my skill level in GCL and Windows remains.

\start
Date: Fri, 17 Sep 2004 13:27:58 -0400
From: Bill Page
To: "'Camm Maguire'" Camm Maguire
Subject: re: mathaction
Cc: David Mentre

On Friday, September 17, 2004 11:18 AM Camm Maguire
Camm Maguire
> 
> Martin Rubey writes:
> ...
> > Yes, they [Mupad] are *very* strong. One reason for this is
> > that MuPad is free for scientists in France, as far as I know.
> > In fact, if MuPad became free, I think there would be little
> > to no space left for axiom.
> 
> This is our challenge.  Do the mathematicians of the world have
> enough spare brain cycles to move beyond the position of a mere
> consumer choosing among whatever best black box happens to be
> available for the task at hand, to the position of a part-time
> contributor to a system permanently owned by the public, and in
> which the knowledge of *how* something is done is available at
> any time to anyone who desires to read?

Well, one of the goals of MathAction could be to make this
possible with a minimum of concern about programming and
configuring operating systems etc. Certainly in the past
mathematicians have been major contributors to Axiom and Reduce
but the learning curve and the investment in appropriate
infrastructure (including local guru's etc.) is rather
prohibitive. I doubt though, that most people who have used
either of these two systems successfully have really taken
a "black box" view. In general, I don't think computer algebra
is anywhere near mature enough to take such a view - even
among the most developed and commercially funded such as Maple
and Mathematica. In almost all cases I would be quite sure
that sooner or later there was a need to look at the actual
code and often to make improvements in the underlying code
in order to address other specific end results.

The idea to extend this beyond Axiom to include Reduce, Maxima,
Mupad, etc. is a separate but related goal. It seems to me that
because of the very large time and intellectual investments
involved, it has been difficult for many people to take a wider
view and thereby make it possible to better share the critically
limited resources. Maybe having at least a common user interface
(e.g. the collaborative wiki environment such as MathAction)
between the diverse systems will remove one of the barriers to
the pooling of expertise. For example web browser based user
interfaces seem to be quickly growing in popularity among new
Linux users (e.g. Gnome and KDE) and also among large computer
systems administrators (e.g. Webmin for system administration).

> To look at the immense complexity of the Linux kernel, gcc,
> etc., the challenge is not impossible.  But it is critical
> that we prioritize, organize, and gain a community of minds
> *very* familiar with the details of the system.

I hope that becoming a contributor to Axiom (or any other
computer algebra system) does not really require the same
kind of effort as the Linux kernel! If so, then I think the
project is doomed from the start. There just aren't enough
people available to make such a commitment.

>From my point of view, the most promising approach is to
attempt to reduce the *apparent complexity" of these systems
through the use of much improved user interface tools (such
as in the current MathAction experiment ... :) If we assume
that one of the reasons work on these systems has (more or
less) stalled is because they have reached some sort of
human limit in the ability to deal with the complexity, then
it seems reasonable to expect that even a modest reduction
in the apparently complexity would enable many of the
potential contributors to continue the job. Though this is
probably a "too optimistic" scenario.

> I am the worst offender as the only thing in which I'm any
> kind of expert at present is gcl.
>

I don't consider that an "offence"... at least we have you
as an expert! :)
 
> If someone can suggest a good, high priority, somewhat
> manageable task, I'm willing to do my part.
> 

I am not sure what you have in mind but just to get started,
since you did raise the issue of Reduce licensing in a
previous message, may be you would like to try making a
modification to one or more pages on MathAction to reflect
this situation with Reduce? If you have questions about how
to proceed with using the MathAction wiki interface, then
I would be very glad to help - or perhaps Martin also.

\start
Date: Fri, 17 Sep 2004 23:56:12 -0400
From: William Sit
To: Martin Rubey
Subject: Re: conditionally defined functions
Cc: Ralf@Hemmecke.de, list, Manuel Bronstein

Martin Rubey wrote:
> 
> Dear Manuel, Ralf, Tim, William, *,
> 
> I'm struggling with something, maybe you are able to help. If not please tell
> me so.
Ok, can't help :-).
 
> As you might know, I'm experimenting with fixes of the following, superficially
> strange behaviour:
> 
> (1) -> (1/x)::UP(x, FRAC POLY INT)
> 
>         1
>    (1)  -
>         x
>                     Type: UnivariatePolynomial(x,Fraction Polynomial Integer)
> 
> Well, I think that this is calling for trouble. So, one way to fix this is to
> make coerce(coef:R)-> % of UP, MPOLY and the like (in fact, are there others?)
> check whether or not coef contains one of the variables -- in this case x. In
> fact, I believe this is the "right" approach.

Axiom was designed to accommodate this, that is, some polynomial domains (like
POLY, ODPOLY) are constructed with Symbol as the set of indeterminates while
others like UP, MPOLY, DMP, HDMP, GDMP, SMP, DSMP, etc specify a particular set
of named indeterminates. If you want to construct towers of polynomial rings,
then you should be using the second kind. Any time you mix one kind with the
other in a tower, you are calling for trouble (your words). If indeed a domain
of the first kind has to mixed with one of the other kind in a tower, it is
imperative that the first kind domain be converted (coerced, lifted, whatever)
to the second kind by finding the set of indeterminates involved IN THE
COMPUTATION (that is, "locally" for a finite set of polynomials involved only,
not the entire domain)  using the spad function [variables] ([ ] just to say
this is a spad function, not used as an English mathematical word). This is
routinely done in radical ideal membership testing using grobner basis, where
the user supplies polynomials from POLY INT and an auxilliary indeterminate is
needed. The computation is done in for example a tower of DMP's. The auxilliary
indeterminate can be generated by the compiler which does not conflict of any
existing names. The result is then converted back to POLY, if needed.

Note that the suggestion you made above, when carried out locally, amounts to
the same thing. The "local" solution works, though it is not very efficient
because of all the coercions. For example, see source for qalgsetp.spad (see
construction of newPoly. The "global" solution, on the other hand, does not make
sense because Symbol includes everything.

In previous messages, we already discussed and agreed that the x in UP(x, FRAC
POLY INT) will be internally different than the x in FRAC POLY INT. The compiler
keeps track of them as different. However, to use the same output symbol for two
different indeterminates is simply wrong from the user interface viewpoint.

> 
> In principle, this is not too difficult. However, there is a slight subtlety:
> Currently not all domains that contain variables provide such a function, in
> particular, FRAC does not. Instead, there is a package RF that provides this
> functionality. Well, no problem:
> 
> * move the operation variables from RF and POLYCATQ to QFCAT :
> 
>     if S has variables: S -> List Symbol then
>       variables: % -> List Symbol
>       variables f ==
>          mymerge(variables(numer(f)), variables(denom(f)))
> 
> and add the following to UP and MPOLY :
> 
>     if R has variables: R -> List Symbol then
>       coerce(r:R):% ==
>         if member?(x, variables(r)) then
>           error "coefficient contains variable"
>         else coerce(r)$Rep
> 
> This works, it seems. However, there are two things I don't like about this
> "fix":

If this works, it works wrongly, because this confuses the x in the inner domain
of a tower with the x in the outer domain of the tower. Remember that the
compiler distinguishes these already. So the condition
         member?(x, variables(r))
would always return false. The identifier x (NOT a symbol) is bound to an
internal symbol, which would NOT appear in variables(r) (a "local"
construct).Unless you change UP fundamentally to consider the parameter x in its
call to bind to an existing identifier x. But this would probably break a lot of
code and defeat the r'aison d'ete of UP.


> * the function "variables" thus (conditionally) provided in QFCAT is only one
>   of many. I don't know of an example, but POLYCAT (which defines variables
>   originally) defines variables : % -> VarSet (which is a member of the
>   Category OrderedSet). So, for example, since SUP specialises VarSet to be
>   SingletonAsOrderedSet, FRAC UP won't have a function variables.
> 
> * philosophically, this is not very beautiful. But I don't see another way to
>   overcome the problem.

If you are only dealing with a finite set of polynomials or fraction of these
and want to find its variables, you can always write such a routine even if the
domain does not have one (as in FRAC).

> Now a mail of William comes in. He wrote, quite some time ago:
>  > Actually, there is a more general request for ages: that is, each
>  > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. This
>  > would have to be built like OutputForm form the bottom up because of nesting.
>  > Lots of editing and a total rebuilt. Currently, when writing a constructor,
>  > there is no way one can "descend" inside its parameters other than finding their
>  > categorical property or attributes.
> 
> However, I don't really see how this could be used. I modified POLYCAT to
> contain a function
> 
> varset: () -> OrderedSet
> varset () == VarSet
> 
> but I was not able to do anything useful with this. Of course, what I'd like to
> say in QFCAT would be
> 
> I'd like to be able to say in QFCAT something like:
> 
>     if S has varset: () -> OrderedSet then
>       variables: % -> List varset()
>       variables f ==
>          mymerge(variables(numer(f)), variables(denom(f)))
> 
> But this looks fishy.

I don't know what you meant by "fishy". The code would not work at present
because I don't think you can consider a function as an attribute. You have to
register it in the AttributeRegistry first. However, since the signature is not
"constant", I wonder if this can be done at all.  Note also you must package
call varset(), which thus requires you to know the parameters, a catch-22
situation.

The problem you raised is one of what might be called dynamic signature, that is
the codomain depends on the input value. The Axiom compiler can handle this
partly, in a category/domain constructor's signature, but not on the function
level. For an example, see the signature of domain constructor DMP, where #vl is
used in the codomain.
> 
> So, in more general terms, here's my question:
> 
> Suppose you have a category A, taking as parameter a domain P and providing an
> operation f: % -> P. Furthermore, you have a category (or a domain, a package)
> B, taking as parameter a domain Q. Now you want to achieve the following:
> 
> If Q is a domain in A, provide a function g: % -> P, using f.
> 
> Of course, it is not possible to provide P as a parameter of B, since B should
> also be defined for Q's that are not domains in A...

The way to handle this is to create a special version of B, which takes a domain
in A as parameter, together with parameters needed for A and construct the
special version using the general one. This is ok because the compiler can
handle dynamic signature on the category/domain constructor level.

BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P }

You can then add the function g without a problem. The moral is: Don't Ask, Just
Tell.

\start
Date: Sun, 19 Sep 2004 21:09:12 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Build on AMD64

I have build Axiom (CVS from 17.09.2004) on AMD64 (Mandrake) and
on i386 (Debian Woody). Some remarks:

- on AMD64 64-bit X libraries are in '/usr/X11R6/lib64' ('/usr/X11R6/lib'
  contains 32-bit versions). Such approach seem to be standard for
  having both 64-bit and 32-bit binaries on Linux. So I had to change
  'Makefile.pamphlet' accordingly

- to complile with Debian gcc-2.95.4 I had to apply the following 
  patch to gcl (otherwise gcc-2.95.4 choked on semicolon before
  declarations):

--- gmp_wrappers.h.bb	Fri Sep 17 13:38:59 2004
+++ gmp_wrappers.h	Fri Sep 17 13:39:35 2004
@@ -96,8 +96,8 @@
 
 #define MEM_GMP_CALL(n_,rt_,a_,s_,b_...) \
    GMP_EXTERN_INLINE Join(RF_,rt_) Join(m,a_)(Join(P,n_)(b_)) { \
-           Join(RD_,rt_);\
            int j;\
+	   Join(RD_,rt_);\
 	   jmp_gmp=0;\
            if ((j=setjmp(gmp_jmp)))\
               GBC(j);\

- many files (especially in 'zips' subdirectory) have executable
  permissions for no good reason. This is a problem when viewing
  them using Midnight Commander as mc tries to run them

- I suggest to '\usepackage[hypertex]{hyperref}' (or just plain
  hyperref if generating pdf-s) in Latex files. It makes the
  Axiom book much nicer for navigation in xdvi. For on-screen
  viewing it wold be nice to reduce margins.

- CVS seem to contain many 'junk' files. I understand that it
  will take some work to automatically generate databases and
  other files may contain some usefull info. But for example 
  'gcl-2.6.3.tgz' just is pure bloat (since 2.6.5 is used for
  build)

\start
Date: Mon, 20 Sep 2004 13:38:09 +0000
From: Martin Rubey
To: William Sit
Subject: Re: conditionally defined functions
Cc: Ralf@Hemmecke.de, Manuel Bronstein

William Sit writes:
 > > In principle, this is not too difficult. However, there is a slight subtlety:
 > > Currently not all domains that contain variables provide such a function, in
 > > particular, FRAC does not. Instead, there is a package RF that provides this
 > > functionality. Well, no problem:
 > > 
 > > * move the operation variables from RF and POLYCATQ to QFCAT :
 > > 
 > >     if S has variables: S -> List Symbol then
 > >       variables: % -> List Symbol
 > >       variables f ==
 > >          mymerge(variables(numer(f)), variables(denom(f)))
 > > 
 > > and add the following to UP and MPOLY :
 > > 
 > >     if R has variables: R -> List Symbol then
 > >       coerce(r:R):% ==
 > >         if member?(x, variables(r)) then
 > >           error "coefficient contains variable"
 > >         else coerce(r)$Rep
 > > 
 > 
 > If this works, it works wrongly, because this confuses the x in the inner
 > domain of a tower with the x in the outer domain of the tower. 

I don't understand what you mean with "wrongly". I'm aiming at the following: I
want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function
(or expression) that is a polynomial in x. I tested the code above and it does
indeed "work" (in this sense).

 > Remember that the compiler distinguishes these already. So the condition

 >          member?(x, variables(r))

 > would always return false. 

No, it does not. (at least not in the tests I ran)

 > I don't know what you meant by "fishy". The code would not work at present
 > because I don't think you can consider a function as an attribute. 

Hmm, I think you can. The code above does so.

 > The problem you raised is one of what might be called dynamic signature, that is
 > the codomain depends on the input value. The Axiom compiler can handle this
 > partly, in a category/domain constructor's signature, but not on the function
 > level. 

Yes, that's what I think, too.

 > > So, in more general terms, here's my question:
 > > 
 > > Suppose you have a category A, taking as parameter a domain P and providing an
 > > operation f: % -> P. Furthermore, you have a category (or a domain, a package)
 > > B, taking as parameter a domain Q. Now you want to achieve the following:
 > > 
 > > If Q is a domain in A, provide a function g: % -> P, using f.
 > > 
 > > Of course, it is not possible to provide P as a parameter of B, since B should
 > > also be defined for Q's that are not domains in A...
 > 
 > The way to handle this is to create a special version of B, which takes a domain
 > in A as parameter, together with parameters needed for A and construct the
 > special version using the general one. This is ok because the compiler can
 > handle dynamic signature on the category/domain constructor level.
 > 
 > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P }
 > 
 > You can then add the function g without a problem. The moral is: Don't Ask, Just
 > Tell.

\start
Date: Mon, 20 Sep 2004 10:08:53 -0400
From: William Sit
To: Martin Rubey
Subject: Re: conditionally defined functions
Cc: Ralf@Hemmecke.de, list, Manuel Bronstein

Martin Rubey wrote:
> 
> William Sit writes:
>  > > In principle, this is not too difficult. However, there is a slight subtlety:
>  > > Currently not all domains that contain variables provide such a function, in
>  > > particular, FRAC does not. Instead, there is a package RF that provides this
>  > > functionality. Well, no problem:
>  > >
>  > > * move the operation variables from RF and POLYCATQ to QFCAT :
>  > >
>  > >     if S has variables: S -> List Symbol then
>  > >       variables: % -> List Symbol
>  > >       variables f ==
>  > >          mymerge(variables(numer(f)), variables(denom(f)))
>  > >
>  > > and add the following to UP and MPOLY :
>  > >
>  > >     if R has variables: R -> List Symbol then
>  > >       coerce(r:R):% ==
>  > >         if member?(x, variables(r)) then
>  > >           error "coefficient contains variable"
>  > >         else coerce(r)$Rep
>  > >
>  >
>  > If this works, it works wrongly, because this confuses the x in the inner
>  > domain of a tower with the x in the outer domain of the tower.
> 
> I don't understand what you mean with "wrongly". I'm aiming at the following: I
> want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function
> (or expression) that is a polynomial in x. I tested the code above and it does
> indeed "work" (in this sense).
> 
>  > Remember that the compiler distinguishes these already. So the condition
> 
>  >          member?(x, variables(r))
> 
>  > would always return false.
> 
> No, it does not. (at least not in the tests I ran)
> 
>  > I don't know what you meant by "fishy". The code would not work at present
>  > because I don't think you can consider a function as an attribute.
> 
> Hmm, I think you can. The code above does so.

One can never argue with code that works! I am surprised that a function can be
treated as an attribute -- I tried that in the interpreter:

INT has min: (INT, INT)->Boolean
   false

Of course, it has. I think the reason why the answer is false is because this
property is not in the AttributeRegistry. Another difference between interpreter
and compiler?

Martin, I did not test your code (lack of time, but probably also I do not have
the setup as well. I might even have misunderstood your question: Perhaps you
are just trying to "lift" a polynomial (or rational function) with integer
coefficient that may or may not involve x (and if it does, only polynomially)
and just want to separate the variable x and rewrite it as a polynomial in x
with all the rest as coefficients? In other words, there is never two different
x's and you just want to rewrite something like Q[a,b,...w,x] as
Q[a,b,...,w][x]? Have you tried using POLYLIFT?

As to why I think if it works, it works wrongly:
Try this:

(1) -> )clear all
(1) -> y:=3*x + 1
    (1) 3x+1                Type: Polynomial Integer
(2) -> z: UP(x, POLY INT)
                            Type: Void
(3) -> z:=3*x + 1
    (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
(4) -> t:=variables(y)
    (4) [x]                 Type: List Symbol
(5) -> s:=variables(z)
    (5) ["?"]               Type: List SingletonAsOrderedSet
(6) sx:=s.1
    (6) "?"                 Type: SingletonAsOrderedSet
(7) member?(sx,t)
    (7) true                Type: Boolean

Is this correct? How?

(8) sxx:=convert(sx)
    (8) ?                   Type: Symbol
(9) tx := t.1
    (9) x                   Type: Symbol
(10) g:Boolean:= sxx=tx
    (10) false               Type: Boolean
(11) g:= sx = tx
    (11) true               Type: Boolean

How do you explain (11) that two items of different type can be equal, and (10),
after conversion to the same type, are not?
   
William
---

PS:
>  > Remember that the compiler distinguishes these already. So the condition
> 
>  >          member?(x, variables(r))
> 
>  > would always return false.
> 
> No, it does not. (at least not in the tests I ran)

I was writing based on a similar situation we discussed on June 12:

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

)abb package TEST  Test

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

Note that if you check the signature of /, the compiler "knows" it is legally
used and the answer for f4() is c/b, not 1 (which should be the case
mathematically).
---end of quote

I have not tried to replace EXPR by UP(x, ...) in Test(). Perhaps they behave
differently

\start
Date: 22 Sep 2004 10:20:35 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: Build on AMD64

Greetings!

Waldek Hebisch writes:

> - to complile with Debian gcc-2.95.4 I had to apply the following 
>   patch to gcl (otherwise gcc-2.95.4 choked on semicolon before
>   declarations):
> 
> --- gmp_wrappers.h.bb	Fri Sep 17 13:38:59 2004
> +++ gmp_wrappers.h	Fri Sep 17 13:39:35 2004
> @@ -96,8 +96,8 @@
>  
>  #define MEM_GMP_CALL(n_,rt_,a_,s_,b_...) \
>     GMP_EXTERN_INLINE Join(RF_,rt_) Join(m,a_)(Join(P,n_)(b_)) { \
> -           Join(RD_,rt_);\
>             int j;\
> +	   Join(RD_,rt_);\
>  	   jmp_gmp=0;\
>             if ((j=setjmp(gmp_jmp)))\
>                GBC(j);\
> 

Just a note -- this is in CVS head.  It is only required for gcc-2.95
and below (presumably).

Take care,


> - many files (especially in 'zips' subdirectory) have executable
>   permissions for no good reason. This is a problem when viewing
>   them using Midnight Commander as mc tries to run them
> 
> - I suggest to '\usepackage[hypertex]{hyperref}' (or just plain
>   hyperref if generating pdf-s) in Latex files. It makes the
>   Axiom book much nicer for navigation in xdvi. For on-screen
>   viewing it wold be nice to reduce margins.
> 
> - CVS seem to contain many 'junk' files. I understand that it
>   will take some work to automatically generate databases and
>   other files may contain some usefull info. But for example 
>   'gcl-2.6.3.tgz' just is pure bloat (since 2.6.5 is used for
>   build)

\start
Date: 22 Sep 2004 10:31:09 -0400
From: Camm Maguire
To: Arthur Norman
Subject: re: mathaction
Cc: David Mentre, Bill Page

Greetings!

Arthur Norman writes:

> On Fri, 17 Sep 2004, Camm Maguire wrote:
> > Greetings, all!  The site looks great!  I just have one request -- it
> > should be made clear early on that reduce is not open source software.
> > It appears from their site that they are selling the source under some
> > circumstances however (cannot see where though).  It would be helpful
> > if someone could report on whether their conditions would allow
> > inspection of the source for use in spotting bugs in axiom.  Am also
> > wondering if standard lisp, as a 'subset', will run on gcl much as the
> > 'applicative common lisp' subset does in acl2.
> >
> > Take care,
> > --
> If you follow www.reduce-algebra.com you will find that a "personal"
> version of Reduce is available (for perhaps a limited range of
> platforms) and that comes without source, and there is a
> "professional" version that comes with source (and in some cases  full
> source of the Lisp use dto build it). And of course
> multiple-installation and site licenses are also available.
> Reduce has two distributors who use different Lisp systems, both
> conforming to "standard lisp". At one stage a mapping of that onto
> Common Lisp was available but that is no longer supported or
> available. One of the versions of Reduce is built on and comes with my

Thanks for the information!  Reduce does look nice and I wish it well
in the marketplace.  If and when it is ever judged that Reduce's
lifecycle as a commercial product has come to an end, I do hope that
the authors will consider following the example NAG has set with
axiom, and that hopefully sufficient advance notice will be given to
allow people to organize open support as seemlessly as possible.

> "CSL" Lisp system and when NAG distributed Axiom I had adjustments to
> that that supported enough of the common lisp-isms that Axiom built on
> it. To my mind the key featuures of what was done there were that (a)
> one compiled image file could then be run on almost any platform
> (windows, linux, lots of sorts of Unix) so the need for per-platform
> compilation of all that Lisp was removed. And platform-specific
> glitches and incompatibilities would be minimised. (b) at the time
> Axiom was notably a resource hog by the standard of workstations
> available and "CCL" (thing S=standard, C=common, L=lisp, c=Codemist)
> allowed it to run with a relatively modest footprint.
> 
> Note that some in the new Axiom world have declared use of CCL to be
> one of the worst mistakes anybody ever made wrt Axiom and that my Lisp
> is thus to be abhored.. so do not get too enthusiastic.
> 

Your lisp is great, and even more, your helpfulness and support.
IMHO, there are too many lisps for the good of the language -- I wish
I knew of a way we could all combine forces.

\start
Date: 22 Sep 2004 10:44:53 -0400
From: Camm Maguire
To: Bill Page
Subject: re: mathaction
Cc: David Mentre

Greetings!

Bill Page writes:

> On Friday, September 17, 2004 11:18 AM Camm Maguire
> Camm Maguire
> > 
> > Martin Rubey writes:
> > ...
> > > Yes, they [Mupad] are *very* strong. One reason for this is
> > > that MuPad is free for scientists in France, as far as I know.
> > > In fact, if MuPad became free, I think there would be little
> > > to no space left for axiom.
> > 
> > This is our challenge.  Do the mathematicians of the world have
> > enough spare brain cycles to move beyond the position of a mere
> > consumer choosing among whatever best black box happens to be
> > available for the task at hand, to the position of a part-time
> > contributor to a system permanently owned by the public, and in
> > which the knowledge of *how* something is done is available at
> > any time to anyone who desires to read?
> 
> Well, one of the goals of MathAction could be to make this
> possible with a minimum of concern about programming and
> configuring operating systems etc. Certainly in the past

Great!  Hopefully a robust packaging system containing axiom, a la
Debian/FreeBSD/... can achieve a similar goal.

...

> The idea to extend this beyond Axiom to include Reduce, Maxima,
> Mupad, etc. is a separate but related goal. It seems to me that
> because of the very large time and intellectual investments
> involved, it has been difficult for many people to take a wider
> view and thereby make it possible to better share the critically
> limited resources. Maybe having at least a common user interface
> (e.g. the collaborative wiki environment such as MathAction)
> between the diverse systems will remove one of the barriers to
> the pooling of expertise. For example web browser based user
> interfaces seem to be quickly growing in popularity among new
> Linux users (e.g. Gnome and KDE) and also among large computer
> systems administrators (e.g. Webmin for system administration).
> 

A great initiative -- go Bill go!

> > To look at the immense complexity of the Linux kernel, gcc,
> > etc., the challenge is not impossible.  But it is critical
> > that we prioritize, organize, and gain a community of minds
> > *very* familiar with the details of the system.
> 
> I hope that becoming a contributor to Axiom (or any other
> computer algebra system) does not really require the same
> kind of effort as the Linux kernel! If so, then I think the
> project is doomed from the start. There just aren't enough
> people available to make such a commitment.
> 

I have a somewhat different opinion here.  There are no magic bullets.
If we supply something of great value to people, it is bound to to
reflect the acquisition of a relatively rare expertise, which will in
turn require the investment of time.  Quick items performed at the
surface level can be done by anybody, and hence are of a lesser value.
I agree with you of course correct in your statement that it will be a
challenge to find people to make this commitment.  I think we
nonetheless have to keep this goal in our sights if we hope anyone to
take open axiom seriously.  And once they do, finding the people will
be a lot easier.

> > If someone can suggest a good, high priority, somewhat
> > manageable task, I'm willing to do my part.
> > 
> 
> I am not sure what you have in mind but just to get started,
> since you did raise the issue of Reduce licensing in a
> previous message, may be you would like to try making a
> modification to one or more pages on MathAction to reflect
> this situation with Reduce? If you have questions about how
> to proceed with using the MathAction wiki interface, then
> I would be very glad to help - or perhaps Martin also.
> 

Thanks!  I'm going to try to fix the symbol issue first if that is
ok.  I would like to help with the site time permitting thereafter.

\start
Date: Wed, 22 Sep 2004 09:47:33 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: mathaction
Cc: Bill Page, David Mentre

Camm,

You should check out the Doyen effort. We've been discussing the 
problem of building a scientific (more than math) platform based 
on a collection of technologies (open source science, live CDs,
mathaction, etc). The initial discussion is at:

http://page.axiom-developer.org/zope/mathaction/doyen

\start
Date: Wed, 22 Sep 2004 17:08:07 +0000
From: Martin Rubey
To: William Sit
Subject: Re: conditionally defined functions

Dear William, 

(I stopped copying to Bronstein and Hemmecke, since I suspect that the
following is too Axiom specific)

 > As to why I think if it works, it works wrongly:
 > Try this:
 > 
 > (1) -> )clear all
 > (1) -> y:=3*x + 1
 >     (1) 3x+1                Type: Polynomial Integer
 > (2) -> z: UP(x, POLY INT)
 >                             Type: Void
 > (3) -> z:=3*x + 1
 >     (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
 > (4) -> t:=variables(y)
 >     (4) [x]                 Type: List Symbol
 > (5) -> s:=variables(z)
 >     (5) ["?"]               Type: List SingletonAsOrderedSet
 > (6) sx:=s.1
 >     (6) "?"                 Type: SingletonAsOrderedSet
 > (7) member?(sx,t)
 >     (7) true                Type: Boolean
 > 
 > Is this correct? How?
 > 
 > (8) sxx:=convert(sx)
 >     (8) ?                   Type: Symbol
 > (9) tx := t.1
 >     (9) x                   Type: Symbol
 > (10) g:Boolean:= sxx=tx
 >     (10) false               Type: Boolean
 > (11) g:= sx = tx
 >     (11) true               Type: Boolean
 > 
 > How do you explain (11) that two items of different type can be equal, and (10),
 > after conversion to the same type, are not?

(6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1

   (6)  x= x
                               Type: Equation UnivariatePolynomial(x,Integer)

The reason is that the interpreter thinks (quite rightly) that 

sx = tx has Type: Equation UnivariatePolynomial(x,Integer)

and (create()$SAOS)::UP(x,INT) returns x.

Thus the only thing which I'd object to is the output of (6) and (8).

I started a discussion of (6) in 

http://page.axiom-developer.org/zope/mathaction/DesignIssues

 > William
 > ---
 > 
 > PS:
 > >  > Remember that the compiler distinguishes these already. So the condition
 > > 
 > >  >          member?(x, variables(r))
 > > 
 > >  > would always return false.
 > > 
 > > No, it does not. (at least not in the tests I ran)
 > 
 > I was writing based on a similar situation we discussed on June 12:
 > 
 > ---quote from June 12
 > So is this a bug? I am not sure, it may be good that the interpreter caught the
 > ambiguity and it may be bad that the compiler does not. The compiler actually
 > knows how to distinguish POLY INT from EXPR POLY INT even if the SAME symbol is
 > used, but we (human) will get all confused. Try:
 > 
 > )abb package TEST  Test
 > 
 > Test():Target==Implementation where
 >   EXPR ==> Expression
 >   POLY ==> Polynomial
 >   INT  ==> Integer
 >   Target ==> with
 >     f1: () -> EXPR POLY INT
 >     f2: () -> POLY INT
 >     f3: () -> EXPR POLY INT
 >     f4: () -> EXPR POLY INT
 >   Implementation ==> add
 >     a:=new()$Symbol
 >     b:=a ::EXPR POLY INT
 >     c:=a :: POLY INT
 >     f1()==b
 >     f2()==c
 >     f3()== (c*b)/b
 >     f4()== f3()/b                      
 > 
 > Note that if you check the signature of /, the compiler "knows" it is legally
 > used and the answer for f4() is c/b, not 1 (which should be the case
 > mathematically).
 > ---end of quote
 > 
 > I have not tried to replace EXPR by UP(x, ...) in Test(). Perhaps they behave
 > differently

Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
forbidden, since it is not clear where the variables belong.

On the other hand, it is easy to clarify the semantics of types like 
UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
domain. I don't think that there is another way to make sense of such a
domain. That's the reason for the question I started with, in fact.

So, let's return there:

> > > So, in more general terms, here's my question:
> > > 
> > > Suppose you have a category A, taking as parameter a domain P and providing an
> > > operation f: % -> P. Furthermore, you have a category (or a domain, a package)
> > > B, taking as parameter a domain Q. Now you want to achieve the following:
> > > 
> > > If Q is a domain in A, provide a function g: % -> P, using f.
> > > 
> > > Of course, it is not possible to provide P as a parameter of B, since B should
> > > also be defined for Q's that are not domains in A...
> > 
> > The way to handle this is to create a special version of B, which takes a domain
> > in A as parameter, together with parameters needed for A and construct the
> > special version using the general one. This is ok because the compiler can
> > handle dynamic signature on the category/domain constructor level.
> > 
> > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P }
> > 
> > You can then add the function g without a problem. The moral is: Don't Ask, Just
> > Tell.
>
> Great! gonna try this!

Well, I thought a little about this, but it seems that I cannot apply it to the
problem at hand. 

I'll note my thoughts on mathaction.

\start
Date: Wed, 22 Sep 2004 15:20:14 -0400
From: William Sit
To: Martin Rubey
Subject: Re: conditionally defined functions

Martin Rubey wrote:
> 
> Dear William,
>  > As to why I think if it works, it works wrongly:
>  > Try this:
>  >
>  > (1) -> )clear all
>  > (1) -> y:=3*x + 1
>  >     (1) 3x+1                Type: Polynomial Integer
>  > (2) -> z: UP(x, POLY INT)
>  >                             Type: Void
>  > (3) -> z:=3*x + 1
>  >     (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
>  > (4) -> t:=variables(y)
>  >     (4) [x]                 Type: List Symbol
>  > (5) -> s:=variables(z)
>  >     (5) ["?"]               Type: List SingletonAsOrderedSet
>  > (6) sx:=s.1
>  >     (6) "?"                 Type: SingletonAsOrderedSet
>  > (7) member?(sx,t)
>  >     (7) true                Type: Boolean
>  >
>  > Is this correct? How?
>  >
>  > (8) sxx:=convert(sx)
>  >     (8) ?                   Type: Symbol
>  > (9) tx := t.1
>  >     (9) x                   Type: Symbol
>  > (10) g:Boolean:= sxx=tx
>  >     (10) false               Type: Boolean
>  > (11) g:= sx = tx
>  >     (11) true               Type: Boolean
>  >
>  > How do you explain (11) that two items of different type can be equal, and (10),
>  > after conversion to the same type, are not?
> 
> (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1
> 
>    (6)  x= x
>                                Type: Equation UnivariatePolynomial(x,Integer)
> 
> The reason is that the interpreter thinks (quite rightly) that

??

> sx = tx has Type: Equation UnivariatePolynomial(x,Integer)
> 
> and (create()$SAOS)::UP(x,INT) returns x.

I know that! You should note in (10) I had declared g to be Boolean! In your
(6), yes, that is an Equation. Unfortunately, a Boolean MUST be declared before
assigning it a value. So your (6) should begin with test:Boolean = (variables
...). If what you think is that Axiom coerced (sx = tx) from Equation to
Boolean, then there is something very wrong since no one will know how to test
equality of two expressions. Perhaps the "=" operator should not be overloaded
this way.

Moreover, Equation (and equality) should only be formed (called) if both sides
come from the same domain. ANY needed coercion should be done by the user. The
interpreter should NEVER automatically coerce the two sides to a common domain
-- I know this is difficult to fix, but an automatic coercion means mistakes on
types will not be caught. I realize that this automatic coercion is done for
common arithmetic operators like + in the interpreter but somehow I think
equality testing should be handled differently.

Although I have not yet tried the above in the compiler, I believe that (10)
should give false, and (11) should be flagged because of type error. 

In (11), sx has type SingletonAsOrderedSet and tx has type Symbol. If sx=tx is
to be considered as an Equation, then an intuitive common domain should be
Symbol (using [convert] as in (8). To use [create] and not [convert] to lift an
SAOS to UP(x,INT) AND do the same for tx is way too imaginative for my intuition
if indeed that is what the interpreter does.

> 
> Thus the only thing which I'd object to is the output of (6) and (8).

I have no objection to either (6) or (8). They are what I expected (from the
compiler viewpoint). I don't think UP was designed for the kind of rearrangement
you have in mind.

> 
> I started a discussion of (6) in
> 
> http://page.axiom-developer.org/zope/mathaction/DesignIssues

Will take a look later. Pressed for time to prepare class (I do have to teach!)

> Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
> forbidden, since it is not clear where the variables belong.

AGREED!

> On the other hand, it is easy to clarify the semantics of types like 
> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
> domain. I don't think that there is another way to make sense of such a
> domain. That's the reason for the question I started with, in fact.

But so should UP(x, EXPR INT). You are inconsistent in the application of your
logic: according to the above, POLY EXPR INT is equally fine (just that there
may be more variables). But back to UP. EXPR INT can also contain polynomials in
x in addition to 1/x, 2^x, sin x. In fact:

(15) sin(x)*x + sin(x)*x^2
     (x^2 + x)sin(x)            Type Expression Integer

This regrouping is automatic. If you rather prefer the input form, which
separates the powers of x, I think you should use a package to provide the
conversion WITHIN EXPR INT and where you also change the outputform. In Axiom,
the domains correspond to mathematical objects, and to have x in BOTH EXPR INT
and UP(x, EXPR INT) is not right since mathematically, the two are the same, as
underlying set and all operations on it. Indeed, any operation in UP(x, EXPR
INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need
to reconvert UP(x, EXPR INT) back to EXPR INT --- a difficult dilemma because
you now have to consider UP(x,EXPR INT) elements as ground elements (ground? may
fail, in general, though not here), perform the operation, and reformating back
to UP(x, EXPR INT). This really shows that the only thing you can achieve is
reformatting output and so it should be done that way.

If you are not mixing x in both places, then something like UP(y,
EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is
constructed.

There is a general philosophy, I think, in developing Axiom algebra code: if
some previously established domain lacks certain functionality, you create a new
domain or package to add them, not modify the original (except for bugs). I
think this is a well-thought out strategy to let Axiom grow without breaking old
code.

\start
Date: Thu, 23 Sep 2004 03:34:03 -0400
From: William Sit
To: Martin Rubey
Subject: Mixing up variables: (was Re: conditionally defined functions)

Hi Martin:

You wrote (referring to my axiom code (10) to (11) below):
> > As to why I think if it works, it works wrongly:
>  > Try this:
>  > 
>  > (1) -> )clear all
>  > (1) -> y:=3*x + 1
>  >     (1) 3x+1                Type: Polynomial Integer
>  > (2) -> z: UP(x, POLY INT)
>  >                             Type: Void
>  > (3) -> z:=3*x + 1
>  >     (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
>  > (4) -> t:=variables(y)
>  >     (4) [x]                 Type: List Symbol
>  > (5) -> s:=variables(z)
>  >     (5) ["?"]               Type: List SingletonAsOrderedSet
>  > (6) sx:=s.1
>  >     (6) "?"                 Type: SingletonAsOrderedSet
>  > (7) member?(sx,t)
>  >     (7) true                Type: Boolean
>  > 
>  > Is this correct? How?
>  > 
>  > (8) sxx:=convert(sx)
>  >     (8) ?                   Type: Symbol
>  > (9) tx := t.1
>  >     (9) x                   Type: Symbol
>  > (10) g:Boolean:= sxx=tx
>  >     (10) false               Type: Boolean
>  > (11) g:= sx = tx
>  >     (11) true               Type: Boolean
>  > 
>  > How do you explain (11) that two items of different type can be equal, and (10),
>  > after conversion to the same type, are not?
> 
> (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1
> 
>    (6)  x= x
>                                Type: Equation UnivariatePolynomial(x,Integer)
> 

> The reason is that the interpreter thinks (quite rightly) that 
> 
> sx = tx has Type: Equation UnivariatePolynomial(x,Integer)
> 
> and (create()$SAOS)::UP(x,INT) returns x.
> 

Unfortunately, this does not correspond to what I find. I set )set mess bot on
and found that this is not how the interpreter works. Rather it goes this way:

sx which is in SAOS, is first coerced into POLY INT then to UP(x, POLY INT),
then "lifted" to UP(x, INT). tx (in Symbol) is also lifted to UP(x, INT) and
then the two are equality tested, returning true. At no time is Equation
involved.

I then tested this (see attachment at end) and as you can see, it gives a
contradiction to transitivity! (Unfortunately, the contradiction is the only
correct answer!)

So I think this is a bug in the interpreter. Instead of trying to be helpful to
search for an "=" that returns Boolean for the types given on the lhs and rhs,
it should simply first check whether the two sides have the same type and then
whether equality testing "=" exist for that type. No automatic coercion should
be done.

> I started a discussion of (6) in 
> 
> http://page.axiom-developer.org/zope/mathaction/DesignIssues

I am not familiar with using this resource, so I have not posted my reply there.
Please feel free to post this if you like.

On that page, you wrote:
> Maybe it would be possible to somehow query functions provided by packages: after all there is a function
> variables:FRAC POLY INT->LIST SYMBOL, only, it is not provided by FRAC POLY INT but by RF INT...

This is correct. As you have pointed out, the reason is very simple. FRAC is a
general constructor for quotient field of an integral domain, which need not
have [variables]. Perhaps ideally, this should be included with something like:

  if R has POLYCAT(...) or any other similar categories then
    variables: FRAC R -> List Symbol

but unfortunately, this is not easy since the ... in POLYCAT varies with the way
R is constructed. This is the reason why it is put in RF. This may fall under
the "Don't ask, just tell" policy :-). Note that indeed, FRAC UP(x, INT) also
has no [variables] because no one has implemented a UnivariateRationalFunction
package or domain. Similarly for FRAC DMP(...) and others. Because of the
generality that Axiom constructors have, it is very difficult to ask about the
constructors --- unless, for each domain constructor, we provide the functions
that return the parameters and the constructor --- but even that is no simple
thing to do ... lots of catch-22 situations. The safest way is to implement this
in an auxilliary package where one has more control over the parameters of the
polynomial domain. I believe this is the correct design.

You suggested:

> to move the
> operation variables from RF and POLYCATQ to QFCAT : 
> 
>     if S has variables: S -> List Symbol then
>       variables: % -> List Symbol
>       variables f ==
>          mymerge(variables(numer(f)), variables(denom(f)))

As you pointed out, this is not general enough, because there are other domains
with [variables] with the more general codomain LV: List OrderedSet. Ideally,
perhaps we can try:

     if S has variables: S -> List V where V:OrderedSet then
       variables: % -> List V
       variables f ==
          mymerge(variables(numer(f)), variables(denom(f)))

However, I am a bit worried with other integral domains that satisfy the
condition but has nothing to do with indeterminates. Fortunately, there are no
such domains in Axiom at present. So this may be better than the 

    if R has POLYCAT(...) then

construct, testing for existence of a function is ok.

> and add the following to UP and MPOLY : 
> 
>     if R has variables: R -> List Symbol then
>       coerce(r:R):% ==
>         if member?(x, variables(r)) then
>           error "coefficient contains variable"
>         else coerce(r)$Rep

If this coercion is done for UP, MPOLY, then it should also be done for any of
the domains in POLYCAT, since there is now no reason not to have say DMP([x,y],
POLY INT). Any tower construction would be allowed.

There is one problem with the 

    member?(x, variables(r))

condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I
would think that variables(r) would have x as a member, and so you would receive
the error message when coerce is called. But according to your intention, you
may still want to coerce r (that is, in my terminology, reformat r) to look like
UP(x, EXPR INT).

BTW, I also just found that you can simply [pun intended] coerce without any new
code to do what you want:

)clear all
q:EXPR INT:=x*sin(x)
p:=q::UP(x, EXPR INT)
degree p
coefficient(p,1)

However, this is not fullproof:
q:=q^2+q+cos(x)
p:=q::UP(x, EXPR INT) -- works fine degree p is 2
q:= p/x
p:=q::UP(x, EXPR INT)
degree p  -- no good degree p is 0

This suggests that the success to such reformatting depends very much on the
data representation.

pn:=numer p
pd:=denom p
p:= (pn::UP(x,EXPR INT))/(pd::UP(x,EXPR INT))
degree p -- no good, degree is 2

More trouble. This is all because the x wears two hats and Axiom does not know
how to simplify them or identify them. Here they were wrongly distinguished. In
the session below, they were wrongly identified.


William
--- Transcript from Axiom session
Starts dribbling to martin2 (Fri Sept 22 22:24:28 2004)

G82322 (4) -> )clear all
   All user variables and function definitions have been cleared.
G82322 (1) -> z:UP(x, POLY INT):=3*x+1

   (1)  3x + 1
                             Type: UnivariatePolynomial(x,Polynomial Integer)
G82322 (2) -> y:POLY INT:=3*x+1

   (2)  3x + 1
                                                     Type: Polynomial Integer
G82322 (3) -> upx:=variables(z).1

   (3)  "?"
                                                  Type: SingletonAsOrderedSet
G82322 (4) -> px:=variables(y).1

   (4)  x
                                                                 Type: Symbol
G82322 (5) -> )set mess bot on
G82322 (5) -> g:Boolean:=(upx = px)

 Function Selection for =
      Arguments: (SAOS,SYMBOL) 
      Target type: BOOLEAN 
   -> no function = found for arguments (SAOS,SYMBOL) 

 Function Selection for =
      Arguments: (SAOS,OVAR [x]) 
      Target type: BOOLEAN 
   -> no function = found for arguments (SAOS,OVAR [x]) 

 Function Selection for =
      Arguments: (SAOS,POLY INT) 
      Target type: BOOLEAN 
   -> no function = found for arguments (SAOS,POLY INT) 

 Function Selection for map by coercion facility (map) 
      Arguments: ((POLY INT -> INT),UP(x,POLY INT)) 
      Target type: UP(x,INT) 
 
 [1]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (

Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from 

UPOLYC2(POLY INT,UP(x,POLY INT),INT,UP(x,INT))
 [2]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (

Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UP2(

x,POLY INT,x,INT)
 

 Function Selection for =
      Arguments: (SAOS,UP(x,INT)) 
      Target type: BOOLEAN 
 
 [1]  signature:   (UP(x,INT),UP(x,INT)) -> BOOLEAN
      implemented: slot (Boolean)$$ from UP(x,INT)
 

   (5)  true
                                                                Type: Boolean

G82322 (6) -> --So Symbol was coerced first to POLY INT then to UP(x, POLY INT),
then polylifted to UP(x, INT), and SAOS was also lifted to UP(x, INT) and then
the equality test from UP(x,INT) is used. Never in here ever was Equation
involved. This result is wrong since I can change x to another symbol and the
result would be the same:

G82322 (6) -> )set mess bot off
G82322 (6) -> w:POLY INT:= 3*t+1

   (6)  3t + 1
                                                     Type: Polynomial Integer

G82322 (7) -> pt:=variables(w).1

   (7)  t
                                                    Type: Symbol
G82322 (8) -> )set mess bot on                                                   

              
G82322 (8) -> g:=upx = pt

 Function Selection for =
      Arguments: (SAOS,SYMBOL) 
      Target type: BOOLEAN 
   -> no function = found for arguments (SAOS,SYMBOL) 

 Function Selection for =
      Arguments: (SAOS,OVAR [t]) 
      Target type: BOOLEAN 
   -> no appropriate = found in SingletonAsOrderedSet 
   -> no appropriate = found in OrderedVariableList [t] 
   -> no appropriate = found in Symbol 
   -> no appropriate = found in Boolean 
   -> no appropriate = found in SingletonAsOrderedSet 
   -> no appropriate = found in OrderedVariableList [t] 
   -> no appropriate = found in Symbol 
   -> no appropriate = found in Boolean 

 Modemaps from Associated Packages 
   no modemaps

 Remaining General Modemaps 
   [1] (FortranScalarType,FortranScalarType) -> Boolean from 
            FortranScalarType
   [2] (D1,D1) -> Equation D1 from Equation D1 if D1 has TYPE
   [3] (D,D) -> Boolean from D if D has BASTYPE
   -> no function = found for arguments (SAOS,OVAR [t]) 

 Function Selection for =
      Arguments: (SAOS,POLY INT) 
      Target type: BOOLEAN 
   -> no function = found for arguments (SAOS,POLY INT) 

 Function Selection for map by coercion facility (map) 
      Arguments: ((POLY INT -> INT),UP(t,POLY INT)) 
      Target type: UP(t,INT) 
   -> no appropriate map found in UnivariatePolynomial(t,Polynomial Integer) 
   -> no appropriate map found in UnivariatePolynomial(t,Integer) 
   -> no appropriate map found in Integer 
   -> no appropriate map found in Polynomial Integer 
   -> no appropriate map found in Integer 

 Modemaps from Associated Packages 
   [1] ((D4 -> D5),D3) -> D1
            from UnivariatePolynomialCategoryFunctions2(D4,D3,D5,D1)
            if D4 has RING and D5 has RING and D1 has UPOLYC D5 and D3 
            has UPOLYC D4
   [2] ((D5 -> D7),UnivariatePolynomial(D4,D5)) -> UnivariatePolynomial
            (D6,D7)
            from UnivariatePolynomialFunctions2(D4,D5,D6,D7)
            if D4: SYMBOL and D5 has RING and D7 has RING and D6: 
            SYMBOL
   [3] ((D4 -> D5),SparseUnivariatePolynomial D4) -> 
            SparseUnivariatePolynomial D5
            from SparseUnivariatePolynomialFunctions2(D4,D5)
            if D4 has RING and D5 has RING
 
 [1]  signature:   ((POLY INT -> INT),UP(t,POLY INT)) -> UP(t,INT)
      implemented: slot (UnivariatePolynomial t (Integer))(Mapping (Integer)
(Polynomial (Integer)))(UnivariatePolynomial t (Polynomial (Integer))) from
UPOLYC2(POLY INT,UP(t,POLY INT,INT,UP(t,INT))
 [2]  signature:   ((POLY INT -> INT),UP(t,POLY INT)) -> UP(t,INT)
      implemented: slot (UnivariatePolynomial t (Integer))(Mapping (Integer)
(Polynomial (Integer)))(UnivariatePolynomial t (Polynomial (Integer))) from
UP2(t,POLY INT,t,INT)
 

 Function Selection for =
      Arguments: (SAOS,UP(t,INT)) 
      Target type: BOOLEAN 
   -> no appropriate = found in SingletonAsOrderedSet 
   -> no appropriate = found in UnivariatePolynomial(t,Integer) 
   -> no appropriate = found in Boolean 
   -> no appropriate = found in SingletonAsOrderedSet 
   -> no appropriate = found in Boolean 
 
 [1]  signature:   (UP(t,INT),UP(t,INT)) -> BOOLEAN
      implemented: slot (Boolean)$$ from UP(t,INT)
 

   (8)  true
                                                 Type: Boolean

G82322 (9) -> -- this is also wrong.

G82322 (9) -> )set mess bot off

G82322 (9) -> g:= (px = pt)

   (9)  false
                                                  Type: Boolean

G82322 (10) -> -- This is correct. If (5) and (8) were correct, it should follow
that (9) returns true by transivity: upx = px, upx = pt, hence px = pt.

G82322 (10) -> g:= (px::UP(x,INT) = pt::UP(t, INT))

   (10)  false
                                                  Type: Boolean
G82322 (11) -> -- This is correct; the interpreter puts everything into UP(x,
UP(t, INT)).

G82322 (11) -> )spool

Finished dribbling to martin2.

\start
Date: Thu, 23 Sep 2004 10:59:17 +0000
From: Martin Rubey
To: William Sit
Subject: Re: conditionally defined functions

Dear William,

William Sit writes:
 > >  > (1) -> )clear all
 > >  > (1) -> y:=3*x + 1
 > >  >     (1) 3x+1                Type: Polynomial Integer
 > >  > (2) -> z: UP(x, POLY INT)
 > >  >                             Type: Void
 > >  > (3) -> z:=3*x + 1
 > >  >     (3) 3x+1                Type: UnivariatePolynomial(x,Polynomial Integer)
 > >  > (4) -> t:=variables(y)
 > >  >     (4) [x]                 Type: List Symbol
 > >  > (5) -> s:=variables(z)
 > >  >     (5) ["?"]               Type: List SingletonAsOrderedSet
 > >  > (6) sx:=s.1
 > >  >     (6) "?"                 Type: SingletonAsOrderedSet
 > >  > (7) member?(sx,t)
 > >  >     (7) true                Type: Boolean
 > >  >
 > >  > Is this correct? How?
 > >  >
 > >  > (8) sxx:=convert(sx)
 > >  >     (8) ?                   Type: Symbol
 > >  > (9) tx := t.1
 > >  >     (9) x                   Type: Symbol
 > >  > (10) g:Boolean:= sxx=tx
 > >  >     (10) false               Type: Boolean
 > >  > (11) g:= sx = tx
 > >  >     (11) true               Type: Boolean
 > >  >
 > >  > How do you explain (11) that two items of different type can be equal, and (10),
 > >  > after conversion to the same type, are not?
 > > 
 > > (6) -> variables((3*x+1)::UP(x, POLY INT)).1=variables((3*x+1)).1
 > > 
 > >    (6)  x= x
 > >                                Type: Equation UnivariatePolynomial(x,Integer)
 > > 
 > > The reason is that the interpreter thinks (quite rightly) that
 > 
 > ??

What do you mean with ?? ? 

 > > sx = tx has Type: Equation UnivariatePolynomial(x,Integer)
 > > 
 > > and (create()$SAOS)::UP(x,INT) returns x.
 > 
 > I know that! 

Sorry, I didn't know it. I didn't mean to be "belehrend". (don't know the
English equivalent. "instructive" doesn't catch the true meaning. It is
something between "instructive" and "squareheadish")

 > You should note in (10) I had declared g to be Boolean! In your
 > (6), yes, that is an Equation. Unfortunately, a Boolean MUST be declared before
 > assigning it a value. So your (6) should begin with test:Boolean = (variables
 > ...). If what you think is that Axiom coerced (sx = tx) from Equation to
 > Boolean,

I think that Axiom coerced (sx = tx) from EQ UP(x, INT) to Boolean, yes. 

Here is the relevant part where axiom looks for the right types for the equation:

 Function Selection for equation
      Arguments: (SAOS,SYMBOL) 
   -> no function equation found for arguments (SAOS,SYMBOL) 

 Function Selection for equation
      Arguments: (SAOS,OVAR [x]) 
   -> no function equation found for arguments (SAOS,OVAR [x]) 

 Function Selection for equation
      Arguments: (SAOS,POLY INT) 
   -> no function equation found for arguments (SAOS,POLY INT) 

 Function Selection for map by coercion facility (map) 
      Arguments: ((POLY INT -> INT),UP(x,POLY INT)) 
      Target type: UP(x,INT) 
 
 [1]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UPOLYC2(POLY INT,UP(x,POLY INT),INT,UP(x,INT))
 [2]  signature:   ((POLY INT -> INT),UP(x,POLY INT)) -> UP(x,INT)
      implemented: slot (UnivariatePolynomial x (Integer))(Mapping (Integer) (Polynomial (Integer)))(UnivariatePolynomial x (Polynomial (Integer))) from UP2(x,POLY INT,x,INT)
 

 Function Selection for equation
      Arguments: (SAOS,UP(x,INT)) 
 
 [1]  signature:   (UP(x,INT),UP(x,INT)) -> EQ UP(x,INT)
      implemented: slot $(UnivariatePolynomial x (Integer))(UnivariatePolynomial x (Integer)) from EQ UP(x,INT)

 > then there is something very wrong since no one will know how to test
 > equality of two expressions. 

Well, in some cases it can be done, in particular for UP(x, INT). That is,
whenever there is a normalized form. I'm pretty sure I misunderstood you. Do
you mean the following:

(25) -> (2^(2*x)=4^x)::Boolean

   (25)  false
                                                                Type: Boolean

I'm not too sure what to think of it. Probably there should be an attribute
telling whether a particular domain has such a normalized form. On the other
hand, we do want to have (x=x)::(EQ EXPR INT)::Boolean giving true, don't we?
Well, maybe not. I'm mainly thinking from the perspective of packages, and
there we don't.

 > Perhaps the "=" operator should not be overloaded this way.
 > 
 > Moreover, Equation (and equality) should only be formed (called) if both sides
 > come from the same domain. 

But in this case they do, don't they?

 > [...]

 > > Thus the only thing which I'd object to is the output of (6) and (8).
 > 
 > I have no objection to either (6) or (8). They are what I expected (from the
 > compiler viewpoint). I don't think UP was designed for the kind of rearrangement
 > you have in mind.

I think that create()$SAOS should not be coercible to Symbol. Again, this is
calling for trouble. Look:

(1) -> r:=create()$SAOS

   (1)  "?"
                                                  Type: SingletonAsOrderedSet
(2) -> s:=r::Symbol

   (2)  ?
                                                                 Type: Symbol
(3) -> s::SAOS
   Loading /home/rubey/axiom/mnt/linux/algebra/UPMP.o for package 
      UnivariatePolynomialMultiplicationPackage 
   Loading /home/rubey/axiom/mnt/linux/algebra/UP.o for domain 
      UnivariatePolynomial 

   (3)  "?"
                                                  Type: SingletonAsOrderedSet
(4) -> t:=?::Symbol

   (4)  ?
                                                                 Type: Symbol
(5) -> t::SAOS
 
   >> System error:
   Bind stack overflow.

protected-symbol-warn called with (NIL)

This should probably also go on

 > > http://page.axiom-developer.org/zope/mathaction/DesignIssues

don't you think?
 
 > Will take a look later. Pressed for time to prepare class (I do have to teach!)

Me too. Just starting in fact...

 > > Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
 > > forbidden, since it is not clear where the variables belong.
 > 
 > AGREED!
 > 
 > > On the other hand, it is easy to clarify the semantics of types like 
 > > UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
 > > domain. I don't think that there is another way to make sense of such a
 > > domain. That's the reason for the question I started with, in fact.
 > 
 > But so should UP(x, EXPR INT). You are inconsistent in the application of your
 > logic: according to the above, POLY EXPR INT is equally fine (just that there
 > may be more variables). 

In this sense, POLY EXPR INT would be the domain of Polynomials with
coefficients in EXPR INT that do not contain any variables. You are quite
right. In fact, thinking about it, this could be quite useful. At the moment,
there is no other way to accomodate coefficients like sin(2), is there? Also,
some time in the future, it may be possible to say
product(1/n^2,n=1..%infinity), which would also be an EXPR INT, I suspect.

 > [...] and to have x in BOTH EXPR INT and UP(x, EXPR INT) is not right since
 > mathematically, the two are the same, as underlying set and all operations
 > on it.

Whether they are mathematically the same obviously depends on the meaning we
give them. Currently, I think, UP(x, EXPR INT) has no good meaning.

 > Indeed, any operation in UP(x, EXPR
 > INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need
 > to reconvert UP(x, EXPR INT) back to EXPR INT 

I don't follow. If you are talking about the current semantics - I'd say they
are broken. If you are talking about the semantics I propose(d), [past tense
means, that I'm not sure anymore whether the idea is a good one]
then multiplication by sin(x) would be forbidden, division would create a FRAC
UP(x, EXPR INT) and multiplication by x is OK.

 > If you are not mixing x in both places, then something like UP(y,
 > EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is
 > constructed.

Yes. I'm inclined to think that this is the best way to go: create a domain
EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY
?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on...

 > There is a general philosophy, I think, in developing Axiom algebra code: if
 > some previously established domain lacks certain functionality, you create a new
 > domain or package to add them, not modify the original (except for bugs). I
 > think this is a well-thought out strategy to let Axiom grow without breaking old
 > code.

I agree, if there remains a clear design. For example, I find the wealth of
polynomial domains and packages a little confusing:

polycat.spad
poly.spad
newpoly.spad
rf.spad

\start
Date: Thu, 23 Sep 2004 22:58:46 +0000
From: Martin Rubey
To: William Sit
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Dear William,

hope I'm not annoying you...

William Sit writes:

 > I am again pressed for time, but many of your questions were answered in my
 > previous email, which probably crossed with yours.

yes indeed...

 > Unfortunately, this does not correspond to what I find. I set )set mess bot
 > on and found that this is not how the interpreter works. Rather it goes this
 > way:

[...]

 > So Symbol was coerced first to POLY INT then to UP(x, POLY INT), then
 > polylifted to UP(x, INT), and SAOS was also lifted to UP(x, INT) and then
 > the equality test from UP(x,INT) is used. Never in here ever was 
[the domain] 
 > Equation involved.

You are quite right. My fault.

 > This result is wrong since I can change x to another symbol and the result
 > would be the same:

I'm not so sure about "wrong". One (not me...) could argue that the two
univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I (!)
would say that this behaviour should be reserved for SUPs. And indeed, axiom
does say that

((x::UP(x, INT))=(t::UP(t, INT)))::Boolean

is false. 

 > I then tested this (see attachment at end) and as you can see, it gives a
 > contradiction to transitivity! (Unfortunately, the contradiction is the only
 > correct answer!)

 > So I think this is a bug in the interpreter. Instead of trying to be helpful
 > to search for an "=" that returns Boolean for the types given on the lhs and
 > rhs, it should simply first check whether the two sides have the same type
 > and then whether equality testing "=" exist for that type. No automatic
 > coercion should be done.

I'm very unsure about this. Note that when you look at the corresponding EQ
types (if you do not coerce to Boolean), everything looks sane. I do understand
that the domain EQ is not involved when you do ask for a boolean immediately,
but I wouldn't hurry here.

 > > I started a discussion of (6) in 
 > > 
 > > http://page.axiom-developer.org/zope/mathaction/DesignIssues
 > 
 > I am not familiar with using this resource, so I have not posted my reply
 > there.  Please feel free to post this if you like.

I will update the page from time to time. I think that discussing all this via
mathaction would produce to much noise...

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

It seems that there is a fundamental misunderstanding concerning my intention
with regards to the semantics of UP(x, POLY INT). You wrote

 > There is one problem with the 
 > 
 >     member?(x, variables(r))
 > 
 > condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I
 > would think that variables(r) would have x as a member, and so you would receive
 > the error message when coerce is called. But according to your intention, you
 > may still want to coerce r (that is, in my terminology, reformat r) to look like
 > UP(x, EXPR INT).

In fact, an error message is exactly what I'd like to see for 
(1/x)::UP(x, EXPR INT).

I try to get it right now: (It may be that my current position differs from
that I had some months ago, but it was constant in the last few weeks. Save I
made a mistake)

For any polynomial (or series) domain that has a specified list of variables, I
want that axiom ensures that any coefficient of a member does not contain one
of these variables. Examples:

(1/x)::UP(x, EXPR INT) produces an error
x*2^x::UP(x, EXPR INT) produces an error
(1/x)::UP(x, FRAC POLY INT) produces an error
(1/x)::UTS(FRAC POLY INT,x,0) produces an error

however, for example

x*2^y::UP(x, EXPR INT) is ok.

More generally, the "outermost" domain "takes" all the variables:

POLY EXPR INT would be the domain of polynomials with coefficients that do not
contain any variables. For example, 

(x*sin(2))::POLY EXPR INT would be ok
(x*sin(y))::POLY EXPR INT would produce an error.

The domain EXPR POLY INT would be strictly the same as EXPR INT, I think.

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

However, currently this seems unachievable. At least I don't know how to do
it. Your suggestion to extend axiom to allow

 > Ideally, perhaps we can try:
 > 
 >      if S has variables: S -> List V where V:OrderedSet then
 >        variables: % -> List V
 >        variables f ==
 >           mymerge(variables(numer(f)), variables(denom(f)))

seems most appealing to me, although I don't think this could be done in the
near future. I read a bit about the "post-facto" extensions provided by aldor,
maybe they adress this problem too. I'm not sure that I've understood them well
enough, though.

PS: In fact, I can think of a way to do it: provide a function 
variables2: % -> List Any in POLYCAT that simply wraps up the function 
variables:% -> List VarSet.

Then I can provide a function variables2 in QFCAT. The only tricky part is that
I need the operation "<" from VarSet in QFCAT (for mymerge) and I don't know of
a *good* way to get it. I do know an ugly way: provide a function 
(Any, Any)->Boolean in POLYCAT that wraps "<" from VarSet.

Maybe there is a better way, but I'm tired now.

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

On the other hand, there is a completely different solution to the original
problem, i.e., providing a domain like UP(x, EXPR INT) with good semantics:

> > Yes. I'm inclined to think that this is the best way to go: create a domain
> > EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY
> > ?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on...
> 
> Good. I am glad we are beginning to agree. However, your point of creating
> something like sin(2) x somewhere should be considered carefully.

sin(2)*x would be in UP(x, EXPR([], INT)). Did you mean that?

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

just for the record:

> > I agree, if there remains a clear design. For example, I find the wealth of
> > polynomial domains and packages a little confusing:
> > 
> > polycat.spad
> > poly.spad
> > newpoly.spad
> > rf.spad
    gdpoly.spad
    multpoly.spad
    prtition.spad
    xlpoly.spad
    xpoly.spad
    wtpol.spad
    ...

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

> I am more confused than you are. You have taught me to look into things I never
> knew. See what I mean that 70% of time in Axiom is in coercion? If I weren't
> conservative, I'll say 90%. That is the curse of strong typing.

You are flattering me...

\start
Date: Thu, 23 Sep 2004 22:26:45 -0400
From: Bill Page
To: <MathAction>
Subject: re: Mixing up variables: (was Re: conditionallydefined functions)

On Thursday, September 23, 2004 6:59 PM Martin Rubey wrote:
> 
> > > I started a discussion of (6) in 
> > > 
> > > http://page.axiom-developer.org/zope/mathaction/DesignIssues
> > 
> > [William Sit wrote:]
> > I am not familiar with using this resource, so I have not 
> > posted my reply there.  Please feel free to post this if you
> > like.
> 
> I will update the page from time to time. I think that discussing
> all this via mathaction would produce to much noise...
> 

  :(

While I am enjoying reading (and trying to understand) this
exchange between Martin and William, I do think that it would
be useful if some of the examples being discussed were included
in MathAction, linked to the [DesignIssues] page that Martin
created. I don't understand, Martin, when you say that discussing
this via MathAction would "produce too much noise". I think it
would be less "noise". Perhaps the best reason for carrying on
the discussion here by email where a large number of people are
already subscribed is that one can be sure that most people are
actually reading it. If you did this via MathAction - which you
*can* do just as easily as you are doing here, since MathAction
also functions like a mailing list - the only people who would
receive emails are those who specifically subscribed to that
page (or to MathAction as a whole), but a record of the discuss
including your example calculations would be accessible to
everyone via the web. Yes, of course there is the mailing
list archive which is accessible via the web anyway, so perhaps
that is not really an issue.

The volume of discussion here on the Axiom mailing lists is
not really that high, so I wonder if it might not be best to
simply subscribe MathAction (the MathAction
mail-in email address) to axiom-developer mailing list. Then
postings to the axiom-developer mailing list would automatically
be archived on the page on MathAction. As time
permits we could then "weed" and reorganize it for longer term

\start
Date: Fri, 24 Sep 2004 10:13:54 +0000
From: Martin Rubey
To: Bill Page
Subject: re: Mixing up variables: (was Re:

Dear Bill,

although I really (really, really) like mathaction and I'm impatiently awaiting
the point were the documentation effort gets started there, I do believe that
it cannot serve as a replacement for the mailing list. On the other hand, you
do have a point regarding "keeping a record of the discussion". Thus, I promise
to try the following in the future:

As soon as I realize that I can somehow "classify" a discussion, I'll create a
page and continue the discussion there. (The prerequisite is that the
discussion gets its "own" page. I will detail this below.)

On the other hand, I do *not* like the idea of having *all* of axiom-developer
copied to mathaction. I cannot really say why, it is a (probably completely
irrational) feeling. Maybe it does have to do with some sort of privacy.

By the way, there is one big difference in style regarding email exchange and
mathaction exchange: When I reply to an email, I *always* quote the text I
comment on. Since this produces a lot of text, I anticipate that the mathaction
page will rapidly become difficult to read. Thus, it will be necessary, that
the discussion topic has its own page. Then all the replies will be at the
bottom of the page and won't disturb the "expository" part too much.

There is another important detail: I think it is *very* important to summarize
the discussion from time to time, and for a "clean" look, I'd like to remove
the exchange then. So, unless the discussion is copied (CC'd) to one of the
mailing lists, it will be lost.

It remains to say thank you once more for MathAction,

Martin

PS: How're pamphlets going?

\start
Date: Fri, 24 Sep 2004 10:27:43 +0000
From: Martin Rubey
To: Martin Rubey
Subject: speakerscorner
Cc: Bill Page

Hmmm, another detail:

Martin Rubey writes:
 > 
 > There is another important detail: I think it is *very* important to summarize
 > the discussion from time to time, and for a "clean" look, I'd like to remove
 > the exchange then. So, unless the discussion is copied (CC'd) to one of the
 > mailing lists, it will be lost.

If we do this, I'll get each message roughly four times:

once because I regularly forget to erase my name from the CC list,
twice because it goes to axiom-developer or the like
thrice because the page axiom-developer on mathaction is changed
four times because the specific discussion page is changed.

(But I do want to subscribe to mathaction as a whole...)

\start
Date: Fri, 24 Sep 2004 11:51:37 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Mixing up variables: (was Re: conditionallydefined functions)

On Friday, September 24, 2004 6:14 AM Martin Rubey wrote: 
> 
> although I really (really, really) like mathaction and I'm 
> impatiently awaiting the point were the documentation effort
> gets started there,

I hear you.

> I do believe that it cannot serve as a replacement for the
> mailing list.

But it does function (in principle) in exactly the same way,
don't you agree?

In any case, since you and I seem to be the only ones who
really care about this right now and there are some technical
limitations that make it less than ideal, I think I will take
your advice and not link MathAction and the axiom-developer
mailing list at this time. In the mean time, provided that one
is also subscribed to MathAction, then simply including

  MathAction

in the Cc list will send a copy to the page
on MathAction. If the sender is not subscribed, then currently
the ZWiki mailin procedure will ignore the incoming mail. This
is configurable security policy. If we wanted we could relax this
restriction so that any email sent by anyone to the above address
would be automatically archived somewhere on MathAction (attached
to wiki page [xxx] based on [xxx] in the subject line if present).

> On the other hand, you do have a point regarding "keeping a
> record of the discussion". Thus, I promise to try the following
> in the future:
> 
> As soon as I realize that I can somehow "classify" a discussion,
> I'll create a page and continue the discussion there. (The
> prerequisite is that the discussion gets its "own" page.
> I will detail this below.)

I didn't see quite enough details below, but I think this might
be hard to achieve. Right now it is only possible for MathAction
to direct a message to a specific page in the wiki based on the
occurrence of [xxxxx] in the subject line. Messages distributed
via the axiom-developer mailing list automatically have
added to the subject line and so if mathaction
is included in the mailing list (either by subscription or via
Cc, as in the case of this and a few previous messages), it will
only attach the email as a comment to the page [Axiom-developer].
It is only a coincidence that [xxxx] is used in both systems,
albeit for different purposes.

> 
> On the other hand, I do *not* like the idea of having *all* 
> of axiom-developer copied to mathaction. I cannot really say why,
> it is a (probably completely irrational) feeling. Maybe it does
> have to do with some sort of privacy.
>

Well, as a physicist it seems that I am often in the position of
having to remind myself that it is user *perceptions* and not
facts that determine how users behave. :) You realize, of course
that email via the axiom-developer mailing list is also archived
and (quite) easily accessible via the web even for people who are
not subscribed to axiom-developer? In MathAction the situation
does seem to emphasize the web interface first with the ability to
subscribe and act like a mailing list as a secondary feature. But
really they are essential the same.

Lately I seem to be dealing more and more with the fact that
people view interaction via the web (as in the case of a wiki)
quite differently than they view material that is delivered and
distributed via email. This currently seems to be a major
obstacle to implementing active collaboration via the web. :(
 
> By the way, there is one big difference in style regarding 
> email exchange and mathaction exchange: When I reply to an
> email, I *always* quote the text I comment on. Since this
> produces a lot of text, I anticipate that the mathaction
> page will rapidly become difficult to read. Thus, it will be 
> necessary, that the discussion topic has its own page. Then
> all the replies will be at the bottom of the page and won't
> disturb the "expository" part too much.

As I mentioned above I don't yet know how to achieve this
technically. Perhaps a change to the way ZWiki directs incoming
email would be required. In the mean time to achieve what you
want would require the active attention of someone to edit
the wiki page.

> 
> There is another important detail: I think it is *very* 
> important to summarize the discussion from time to time,
> and for a "clean" look, I'd like to remove the exchange then.
> So, unless the discussion is copied (CC'd) to one of the
> mailing lists, it will be lost.
>

Well, the general idea would be that the axiom-developer
mail list *also* be subscribed to the MathAction wiki. But
without some careful changes to the ZWiki mailin procedure,
this would create a disastrous email loop! Right now we can
have mathaction subscribed to axiom-developer *or* axiom-
developer subscribed to MathAction but not both.
 
> It remains to say thank you once more for MathAction,
> 
> Martin
> 
> PS: How're pamphlets going?
> 

Maybe later this weekend on test.axiom-developer.org

Later on Friday, September 24, 2004 6:28 AM Martin Rubey
wrote:
> 
> Hmmm, another detail:
> 
> Martin Rubey writes:
> > 
> > There is another important detail: I think it is *very* 
> > important to summarize the discussion from time to time,
> > and for a "clean" look, I'd like to remove the exchange
> > then. So, unless the discussion is copied (CC'd) to one
> > of the mailing lists, it will be lost.
> 
> If we do this, I'll get each message roughly four times:
> 
> once because I regularly forget to erase my name from the
> CC list, twice because it goes to axiom-developer or the like
> thrice because the page axiom-developer on mathaction is changed
> four times because the specific discussion page is changed.
> 
> (But I do want to subscribe to mathaction as a whole...)
> 

I see this same problem.

I suppose that *if* we did link MathAction directly to
axiom-developer mailing list, then it would make sense to
subscribe to only MathAction, and for most users specifically
the page, since everything would be directed
there. Ideally there would be a way for topics to automatically
branch off to their own wiki pages and some way to manage the
subscriptions.

But my summary would be this: "If it ain't broke, let's try
to avoid fixing it ..."  :) We will leave things as they are
now for the time being.

\start
Date: Fri, 24 Sep 2004 18:30:49 +0000
From: Martin Rubey
To: Bill Page
Subject: re: Mixing up variables: (was Re: conditionallydefined functions)

Bill Page writes:

 > Well, as a physicist it seems that I am often in the position of having to
 > remind myself that it is user *perceptions* and not facts that determine how
 > users behave. :)

Yes indeed. And experience tells me that mathematicians in general and me in
particular are especially irrational beings...

 > Lately I seem to be dealing more and more with the fact that people view
 > interaction via the web (as in the case of a wiki) quite differently than
 > they view material that is delivered and distributed via email. This
 > currently seems to be a major obstacle to implementing active collaboration
 > via the web. :(

I would regard email exchange as part of the web. Email and MathAction however
differ (for me) in one important point: I read email using emacs, and I browse
MathAction using Konqueror. Very different feeling!

It seems that we both think that MathAction should get a little more attention.
Probably it would be good indeed to notify the axiom mailing lists when major
changes have been done to MathAction. I think I'll volonteer.

 > > PS: How're pamphlets going?
 > 
 > Maybe later this weekend on test.axiom-developer.org

Yeah, yeah, yeah! If you weren't that far away physically I'd bring you some
chocolate...

\start
Date: Fri, 24 Sep 2004 10:05:51 -0700
From: Bob McElrath
To: Bill Page
Subject: re: Mixing up variables: (was Re: conditionallydefined functions)

Bill Page [Bill Page] wrote:
> Well, as a physicist it seems that I am often in the position of
> having to remind myself that it is user *perceptions* and not
> facts that determine how users behave. :) You realize, of course
> that email via the axiom-developer mailing list is also archived
> and (quite) easily accessible via the web even for people who are
> not subscribed to axiom-developer? In MathAction the situation
> does seem to emphasize the web interface first with the ability to
> subscribe and act like a mailing list as a secondary feature. But
> really they are essential the same.
> 
> Lately I seem to be dealing more and more with the fact that
> people view interaction via the web (as in the case of a wiki)
> quite differently than they view material that is delivered and
> distributed via email. This currently seems to be a major
> obstacle to implementing active collaboration via the web. :(

There is a second problem here.  Adding latex or axiom commands to your
email is easy and convenient, but generally requires one to then go look
at the web page to see if you made any typos.  It's the whole
edit-compile-test cycle that people don't normally associate with email,
but is inherent in work with both latex and math software axiom/reduce.

I have thought about this quite a bit wrt latexwiki and don't really
have a good solution.  I have thought about bouncing emails back to
users when it contains a latex syntax error, so they can correct and
resubmit.  But this does not help with syntax-correct logic errors that
need to be edited like $x^23$ or unexpected output from axiom commands.

The situation suggests an integrated email/web/axiom interface that does
all this without the intermediate submit-to-webpage step.  But now I'm
getting waaaay beyond the modest goals that this group has collectively
tackled so far.

Ideas welcome here...

Who has played significantly with texmacs?

\start
Date: 24 Sep 2004 13:11:27 -0400
From: Camm Maguire
To: Martin Rubey
Subject: Quick question on the symbol issue:
Cc: Manuel Bronstein

Greetings!  

OK, the issue does not appear to be with the underlying lisp as far as
I can tell.  Please correct me if I am in error (with verifiable
details if possible).  Rather the new() functions in SYMBOL.spad do
not check that the user might have referred previously to a symbol
with the 'special' % prefix.  Alternatively, perhaps it was intended
that % act somewhat like the #: lisp reader macro in designating a
symbol that is to be uninterned.  If this is the case, please point me
to the code that is intended to establish this behavior and I'll look
at it.

Assuming the rather more likely scenario that the design simply did
not intend for users to set by hand symbols beginning with % (as it
does appear to be used as some sort of escape), the following patch
will increment the counter as necessary to step over symbols already
so interned:

(sid)camm@intech66:/fix/g/camm/axiom/axiom-0.20040831/src/algebra$ diff -u symbol.spad.pamphlet.ori symbol.spad.pamphlet
--- symbol.spad.pamphlet.ori	2004-05-24 22:53:45.000000000 +0000
+++ symbol.spad.pamphlet	2004-09-24 16:51:41.000000000 +0000
@@ -252,27 +252,32 @@
         if zero?(n) then return ns
       
     new() ==
-      sym := anyRadix(count()::Integer,ALPHAS)
-      count() := count() + 1
-      concat("%",sym)::%
+      repeat
+        sym := anyRadix(count()::Integer,ALPHAS)
+        count() := count() + 1
+        ns := concat("%",sym)
+        if not FIND_-SYMBOL(ns)$Lisp then return ns::%
 
     new x ==
-      n:Integer :=
-        (u := search(x, xcount)) case "failed" => 0
-        inc(u::Integer)
-      xcount(x) := n
-      xx := 
-        not scripted? x => string x
-        string name x
-      xx := concat("%",xx)
-      xx :=
-        (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
-          concat(xx, anyRadix(n,alphas))
-        concat(xx, anyRadix(n,nums))
-      not scripted? x => xx::%
-      script(xx::%,scripts x)
+      repeat
+        n:Integer :=
+          (u := search(x, xcount)) case "failed" => 0
+          inc(u::Integer)
+        xcount(x) := n
+        xx := 
+          not scripted? x => string x
+          string name x
+        xx := concat("%",xx)
+        xx :=
+          (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
+            concat(xx, anyRadix(n,alphas))
+          concat(xx, anyRadix(n,nums))
+	if not FIND_-SYMBOL(xx)$Lisp then
+          if not scripted? x then return xx::%
+          return script(xx::%,scripts x)
 
     resetNew() ==
+--    Do we want to unintern the symbols previously interned here?
       count() := 0
       for k in keys xcount repeat remove_!(k, xcount)
       void


As noted in the comment, regardless of resetNew(), subsequent
invocations of new() will start where the counter left off, unless one
adds code to unintern the specified symbols, which in this case might
wipe out a symbol explicitly specified by the user.  Don't know what
is best here, though I suspect the latter.

As for gensym, it returns a fresh *uninterned* symbol at all times.
(eq '#:g '#:g) ==> nil.  Axiom is printing the symbol without this
special syntax which might alert one to what is going on.  In short,
G1419::Symbol *is in fact distinct* from the return value of
symbol(GENSYM()$Lisp) even when the print value is the same.  The
former is interned and can be retrieved again by the same user input.
The latter is lost forever unless saved as the value of some other
variable.  You will never be able to write code trying to refer to
gensymmed output by the printed symbol name.  This is also the case in
lisp as the example above shows.  So not sure if any changes are
warranted here.

Please let me know if this is all off base.  And yes, in answer to
your previous question, though not a mathematician, I have a Ph.D. in
theoretical physics, and so could work on math bugs in axiom providing
they are not too specialized.  As time is short, I'd really prefer not
working on things which are not *important*, which I'm defining here
as increasing the utility of as many people as possible by as much as
possible. 

Take care,

> (1) -> %A::Symbol
> 
>    (1)  %A
>                                                                  Type: Symbol
> (2) -> new()$Symbol
> 
>    (2)  %A
>                                                                  Type: Symbol
> (3) -> G1419::SYMBOL
> 
> 
>    (3)  G1419
>                                                                  Type: Symbol
> (4) -> symbol(GENSYM()$Lisp)
>    Loading /home/rubey/axiom/mnt/linux/algebra/SEX.o for domain 
>       SExpression 
>    Loading /home/rubey/axiom/mnt/linux/algebra/DFLOAT.o for domain 
>       DoubleFloat 
>    Loading /home/rubey/axiom/mnt/linux/algebra/SEXOF.o for domain 
>       SExpressionOf 
> 
>    (4)  G1419
>                                                                  Type: Symbol
> 
> (5) -> b:=%B
> 
>    (5)  %B
>                                                             Type: Variable %B
> (6) -> new()$Symbol
> 
>    (6)  %B

\start
Date: Fri, 24 Sep 2004 19:11:22 +0000
From: Martin Rubey
To: Bob McElrath
Subject: Re: speakerscorner
Cc: Bill Page

Bob McElrath writes:
 > The situation suggests an integrated email/web/axiom interface that does
 > all this without the intermediate submit-to-webpage step.  

I'm unwilling to exchange MY (:-) emacs against any such tool. BTW: Bill, could you set
up support for external editor?

http://zwiki.org/HowToSetUpExternalEditor

\start
Date: 24 Sep 2004 13:16:45 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: solving polynomial equations
Cc: James Amundson, Maxima List <maxima@math.utexas.edu>

Greetings!  Just wanted to pass on that popcon is slowly gaining usage
within Debian, which gives an idea of how many people are using axiom,
maxima and other packages via the Debian distribution.  Readers might
be interested in the links below.

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&beenhere=1

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&beenhere=1

\start
Date: Fri, 24 Sep 2004 20:11:20 +0000
From: Martin Rubey
To: Camm Maguire
Subject: Re: Quick question on the symbol issue:

Hi Camm!

Camm Maguire writes:
 > OK, the issue does not appear to be with the underlying lisp as far as I can
 > tell. Please correct me if I am in error (with verifiable details if
 > possible).

This is very strange: in
http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00081.html William
Sit reports that the problem does not occur in the NAG version. He writes:

> I have started verifying your bug on the NAG Axiom 2.3 version, which
> presumably have the same algebra sources. There are some places where I cannot
> duplicate your error messages. (I am also handicapped as far as Linux goes and
> so my Axiom set up is on a separate computer (in fact a virtual computer) that
> makes it clumsy to transfer text. I am using the NAG version because it helps
> to identify whether the bug is from the algebra or the open source "meddling"
> :-)
> 
> On my system, which is not the open source one, I have this (transcribing ;-(
> nonessential things omitted)
> 
> )clear all
> (1) -> %A:SYMBOL
>     %A
> 
> (2) -> new()$SYMBOL
>     %D

On the other hand, your explanations make a lot of sense.

 > Rather the new() functions in SYMBOL.spad do not check that the user might
 > have referred previously to a symbol with the 'special' % prefix.

Yes, that was my first thought too.

 > Alternatively, perhaps it was intended that % act somewhat like the #: lisp
 > reader macro in designating a symbol that is to be uninterned.  If this is
 > the case, please point me to the code that is intended to establish this
 > behavior and I'll look at it.

No idea. However, I'd be interested whether the bug *really* does not occur in
the NAG version. It could well be the case that new()$Symbol always starts with
%D in NAG. Could you check, William?

 > (sid)camm@intech66:/fix/g/camm/axiom/axiom-0.20040831/src/algebra$ diff -u symbol.spad.pamphlet.ori symbol.spad.pamphlet
 > --- symbol.spad.pamphlet.ori	2004-05-24 22:53:45.000000000 +0000
 > +++ symbol.spad.pamphlet	2004-09-24 16:51:41.000000000 +0000
 > @@ -252,27 +252,32 @@
 >          if zero?(n) then return ns
 >        
 >      new() ==
 > -      sym := anyRadix(count()::Integer,ALPHAS)
 > -      count() := count() + 1
 > -      concat("%",sym)::%
 > +      repeat
 > +        sym := anyRadix(count()::Integer,ALPHAS)
 > +        count() := count() + 1
 > +        ns := concat("%",sym)
 > +        if not FIND_-SYMBOL(ns)$Lisp then return ns::%
 >  
 >      new x ==
 > -      n:Integer :=
 > -        (u := search(x, xcount)) case "failed" => 0
 > -        inc(u::Integer)
 > -      xcount(x) := n
 > -      xx := 
 > -        not scripted? x => string x
 > -        string name x
 > -      xx := concat("%",xx)
 > -      xx :=
 > -        (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
 > -          concat(xx, anyRadix(n,alphas))
 > -        concat(xx, anyRadix(n,nums))
 > -      not scripted? x => xx::%
 > -      script(xx::%,scripts x)
 > +      repeat
 > +        n:Integer :=
 > +          (u := search(x, xcount)) case "failed" => 0
 > +          inc(u::Integer)
 > +        xcount(x) := n
 > +        xx := 
 > +          not scripted? x => string x
 > +          string name x
 > +        xx := concat("%",xx)
 > +        xx :=
 > +          (position(xx.maxIndex(xx),nums)>=minIndex(nums)) => 
 > +            concat(xx, anyRadix(n,alphas))
 > +          concat(xx, anyRadix(n,nums))
 > +	if not FIND_-SYMBOL(xx)$Lisp then
 > +          if not scripted? x then return xx::%
 > +          return script(xx::%,scripts x)

great. Even better: it would have been impossible for me to fix that! (don't
know find-symbol...)

 >  
 >      resetNew() ==
 > +--    Do we want to unintern the symbols previously interned here?
 >        count() := 0
 >        for k in keys xcount repeat remove_!(k, xcount)
 >        void
 
 > As noted in the comment, regardless of resetNew(), subsequent invocations of
 > new() will start where the counter left off, unless one adds code to
 > unintern the specified symbols, which in this case might wipe out a symbol
 > explicitly specified by the user.  Don't know what is best here, though I
 > suspect the latter.

I don't understand what you explain here. What symbols do you mean with
"specified symbols"?

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

 > As for gensym, it returns a fresh *uninterned* symbol at all times.  (eq
 > '#:g '#:g) ==> nil.  Axiom is printing the symbol without this special
 > syntax which might alert one to what is going on.  In short, G1419::Symbol
 > *is in fact distinct* from the return value of symbol(GENSYM()$Lisp) even
 > when the print value is the same.

Well observed! I had to try it out :-) :

(1) -> a:=G1418::Symbol

   (1)  G1418
                                                                 Type: Symbol
(2) -> b:=symbol(GENSYM()$Lisp)
   (2)  G1418
                                                                 Type: Symbol
(4) -> (a=b)::Boolean

   (4)  false
                                                                Type: Boolean
(5) -> a:=%A::Symbol

   (5)  %A
                                                                 Type: Symbol
(6) -> b:=new()$Symbol

   (6)  %A
                                                                 Type: Symbol
(8) -> (a=b)::Boolean

   (8)  true

Shame on me...

 > And yes, in answer to your previous question, though not a mathematician, I
 > have a Ph.D. in theoretical physics, and so could work on math bugs in axiom
 > providing they are not too specialized.  

Great!

 > As time is short, I'd really prefer not working on things which are not
 > *important*, which I'm defining here as increasing the utility of as many
 > people as possible by as much as possible.

Yes. BTW, it seems that Bill Page made progress on integrating pamphlets into
MathAction. Very good week! 

If you can spare time I suggest that you look at 

http://page.axiom-developer.org/zope/mathaction/WishList

The TodoList currently seems a bit outdated to me. I will update it when I get
to it. However, I'm not that good at rating what's important and what's not
that urgent. I find that there are not that many severe unfixed bugs known at
the moment (on the other hand: a (mathematical) bug is one bug too many), so
maybe a windows port and more functionality (mathswise) has higher priority.

Maybe you could also add to the WishList what would be a real goody for a
physicist?

\start
Date: Sat, 25 Sep 2004 17:08:12 +0200
From: Hans Peter Wuermli Hans Peter Wuermli
To: list
Subject: Axiom crashing in Zope-Plone

Hi

I wonder if someone with the new Zope-Plone-LatexWiki experience can help me. 

Having been enthusiastic about MathAction I tried to set it up locally on my 
local computer, too, using the ZWiki and LatexWiki files on 
http://page.axiom-developer.org/repository. Strangely enough Axiom is not 
rendered, as the method runCommand() in axiomWrapper.py fails when run from 
inside Zope. Testing the method externally either within a zope.app() or as a 
standalone method, does not produce errors and works as expected. 

I checked with a lot of analoguous situations, first suspecting missing access 
rights, but "wrapping", for example, an executable, a segfaulting executable 
or a psql script run fine, standalone or within zope as external methods.

I can boil down the error to the external method "demo.py" at the end of the 
mail, which is similar to the runCommand() in axiomWrapper.py. 

Zope is version 2.6.4; python used is version 2.2 and it all runs on a Debian 
sarge system.

The exit codes for Popen3 when run from Zope are:

WEXITSTATUS:139 
WIFEXITED: 1

Thank you for any help.

Cheers, H.P.


demo.py:

import os
from popen2 import Popen3


axiomTemplate = r""")set output algebra off
)set output tex on
)set message autoload off
)set quit unprotected
integrate(x**2,x)
)quit
"""

LatexWikiHome = '/usr/lib/zope/lib/python\
/Products/LatexWiki/Extensions/'

axTinput = open ( LatexWikiHome + 'axT.input', 'w' )
axTinput.write(axiomTemplate)
axTinput.close()

cmdLine = r'export AXIOM=/usr/lib/axiom-0.20040831;\
export PATH=$AXIOM/bin:$PATH;\
AXIOMsys < %s ' %(LatexWikiHome + 'axT.input')

def echoWorld():
    """ external method calling Popen3 """
    p = Popen3 (cmdLine, 1, 4096)
    status = p.wait()
    p.tochild.close()
    out = p.fromchild.read()
    p.fromchild.close()
    err = ''
    if p.childerr: err = p.childerr.read(); p.childerr.close()
    error = os.WEXITSTATUS(status) or \
            not os.WIFEXITED(status)
    if not error: return\
           'Output: ' + out +\
           '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\
           '\nWIFEXITED:   ' + str(os.WIFEXITED(status))
    else:  return\
           'Error: ' + err +\
           '\nOut: ' + out +\
           '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\
           '\nWIFEXITED:   ' + str(os.WIFEXITED(status))

# For Zope external testing
print echoWorld()

\start
Date: Sat, 25 Sep 2004 10:33:07 -0700
From: Bob McElrath
To: Hans Peter Wuermli Hans Peter Wuermli
Subject: Re: Axiom crashing in Zope-Plone

The original version of runCommand (and your example below) fails if
your program creates a large amount of output.  I only discovered the
bug recently when re-rendering one of my pages with a lot of latex.

You should grab latexwiki from my repository::

    http://bob.mcelrath.org/darcs/latexwiki

which is the official source for that, then 'darcs pull' from::

    http://page.axiom-developer.org/repository

which has the axiom patches.  These will be integrated to latexwiki
eventually -- right now the axiom patches duplicate a lot of code
(including runCommand).  If someone wants to clean this up, I will
accept patches!  ;)  I've just been busy lately.  Physics comes first...

The fixed runCommand is::

    # Make our file descriptors nonblocking so that reading doesn't hang.
    def makeNonBlocking(f):
        fl = fcntl.fcntl(f.fileno(), FCNTL.F_GETFL)
        fcntl.fcntl(f.fileno(), FCNTL.F_SETFL, fl | os.O_NONBLOCK)
        
    def runCommand(cmdLine):
        program = popen2.Popen3('cd %s; '%(workingDir) + cmdLine, 1)
        program.tochild.close()
        makeNonBlocking(program.fromchild)
        makeNonBlocking(program.childerr)
        stderr = []
        stdout = []
        erreof = False
        outeof = False
        while(not (erreof and outeof)):
            readme, writme, xme = select.select([program.fromchild, program.childerr], [], [])
            for output in readme:
                if(output == program.fromchild):
                    text = program.fromchild.read()
                    if(text == ''): outeof = True
                    else: stdout.append(text)
                elif(output == program.childerr):
                    text = program.childerr.read()
                    if(text == ''): erreof = True
                    else: stderr.append(text)
        status = program.wait()
        error = os.WEXITSTATUS(status) or not os.WIFEXITED(status)
        return error, string.join(stdout, ''), string.join(stderr, '')

Hans Peter Wuermli [Hans Peter Wuermli] wrote:
> 
> Hi
> 
> I wonder if someone with the new Zope-Plone-LatexWiki experience can help me. 
> 
> Having been enthusiastic about MathAction I tried to set it up locally on my 
> local computer, too, using the ZWiki and LatexWiki files on 
> http://page.axiom-developer.org/repository. Strangely enough Axiom is not 
> rendered, as the method runCommand() in axiomWrapper.py fails when run from 
> inside Zope. Testing the method externally either within a zope.app() or as a 
> standalone method, does not produce errors and works as expected. 
> 
> I checked with a lot of analoguous situations, first suspecting missing access 
> rights, but "wrapping", for example, an executable, a segfaulting executable 
> or a psql script run fine, standalone or within zope as external methods.
> 
> I can boil down the error to the external method "demo.py" at the end of the 
> mail, which is similar to the runCommand() in axiomWrapper.py. 
> 
> Zope is version 2.6.4; python used is version 2.2 and it all runs on a Debian 
> sarge system.
> 
> The exit codes for Popen3 when run from Zope are:
> 
> WEXITSTATUS:139 
> WIFEXITED: 1
> 
> Thank you for any help.
> 
> Cheers, H.P.
> 
> 
> demo.py:
> 
> import os
> from popen2 import Popen3
> 
> 
> axiomTemplate = r""")set output algebra off
> )set output tex on
> )set message autoload off
> )set quit unprotected
> integrate(x**2,x)
> )quit
> """
> 
> LatexWikiHome = '/usr/lib/zope/lib/python\
> /Products/LatexWiki/Extensions/'
> 
> axTinput = open ( LatexWikiHome + 'axT.input', 'w' )
> axTinput.write(axiomTemplate)
> axTinput.close()
> 
> cmdLine = r'export AXIOM=/usr/lib/axiom-0.20040831;\
> export PATH=$AXIOM/bin:$PATH;\
> AXIOMsys < %s ' %(LatexWikiHome + 'axT.input')
> 
> def echoWorld():
>     """ external method calling Popen3 """
>     p = Popen3 (cmdLine, 1, 4096)
>     status = p.wait()
>     p.tochild.close()
>     out = p.fromchild.read()
>     p.fromchild.close()
>     err = ''
>     if p.childerr: err = p.childerr.read(); p.childerr.close()
>     error = os.WEXITSTATUS(status) or \
>             not os.WIFEXITED(status)
>     if not error: return\
>            'Output: ' + out +\
>            '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\
>            '\nWIFEXITED:   ' + str(os.WIFEXITED(status))
>     else:  return\
>            'Error: ' + err +\
>            '\nOut: ' + out +\
>            '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\
>            '\nWIFEXITED:   ' + str(os.WIFEXITED(status))
> 
> # For Zope external testing
> print echoWorld()

\start
Date: Sat, 25 Sep 2004 16:22:45 -0400
From: Bill Page
To: "'Hans Peter Wuermli'" Hans Peter Wuermli
Subject: RE: Axiom crashing in Zope-Plone

Hans,

I am VERY HAPPY that you are motivated to do this! I would
like to provide you with as much help as I can.

I tried your demo.py program on the axiom-developer.org system
and it works fine. The program and outout is attached below.
As you can see, I only made a simple change to accommodate the
default location of AXIOMsys and the input file.

Although Bob McElrath has written separately about the issue of
programs that produce a large output, I don't think that this is
the problem since the MathAction axiom code already uses the
"fixed runCommand" (makeNonBlocking etc.) that Bob mentions.

Therefore I think the best approach would be to find the
meaning of the EXITSTATUS 139. I will let you know if I find
anything.

Regards,
Bill Page.

--------
[page@axiom-developer page]$ cat demo.py
import os
from popen2 import Popen3


axiomTemplate =3D r""")set output algebra off
)set output tex on
)set message autoload off
)set quit unprotected
integrate(x**2,x)
)quit
"""

LatexWikiHome =3D ''

axTinput =3D open ( LatexWikiHome + 'axT.input', 'w' )
axTinput.write(axiomTemplate)
axTinput.close()

cmdLine =3D r'AXIOMsys < %s ' %(LatexWikiHome + 'axT.input')

def echoWorld():
    """ external method calling Popen3 """
    p =3D Popen3 (cmdLine, 1, 4096)
    status =3D p.wait()
    p.tochild.close()
    out =3D p.fromchild.read()
    p.fromchild.close()
    err =3D ''
    if p.childerr: err =3D p.childerr.read(); p.childerr.close()
    error =3D os.WEXITSTATUS(status) or \
            not os.WIFEXITED(status)
    if not error: return\
           'Output: ' + out +\
           '\nWEXITSTATUS: ' + str(os.WEXITSTATUS(status)) +\
           '\nWIFEXITED:   ' + str(os.WIFEXITED(status))
    else:  return\
           'Error: ' + err +\
           '\nOut: ' + out +\
           '\nWEXITSTATUS:' + str(os.WEXITSTATUS(status)) +\
           '\nWIFEXITED:   ' + str(os.WIFEXITED(status))

# For Zope external testing
print echoWorld()

[page@axiom-developer page]$ python demo.py
Output:                         AXIOM Computer Algebra System
                Version of Monday June 21, 2004 at 08:34:09
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> (1) -> (1) -> (1) -> (1) ->
$$
{1 \over 3} \  {x \sp 3}
\leqno(1)
$$

                                            Type: Polynomial Fraction
Integer
(2) ->
WEXITSTATUS: 0
WIFEXITED:   1
[page@axiom-developer page]$

\start
Date: Sat, 25 Sep 2004 13:46:53 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone
Cc: 'Hans Peter Wuermli' Hans Peter Wuermli


--WlEyl6ow+jlIgNUh

Bill Page [Bill Page] wrote:
> Hans,
> 
> I am VERY HAPPY that you are motivated to do this! I would
> like to provide you with as much help as I can.
> 
> I tried your demo.py program on the axiom-developer.org system
> and it works fine. The program and outout is attached below.
> As you can see, I only made a simple change to accommodate the
> default location of AXIOMsys and the input file.

Actually, I did not try to run your program.  Now that I do I find the
same as Bill...it works fine...on my Intel office computer.

> Although Bob McElrath has written separately about the issue of
> programs that produce a large output, I don't think that this is
> the problem since the MathAction axiom code already uses the
> "fixed runCommand" (makeNonBlocking etc.) that Bob mentions.
> 
> Therefore I think the best approach would be to find the
> meaning of the EXITSTATUS 139. I will let you know if I find
> anything.

It is a segmentation fault.  I also see this on my alpha server.  (note
same axiom version in both places -- 0831)

In fact, now I can't run axiom at all on that computer -- it always
segfaults.

Program received signal SIGSEGV, Segmentation fault.
0x0000020000288158 in memmove () from /lib/libc.so.6.1
(gdb) where
#0  0x0000020000288158 in memmove () from /lib/libc.so.6.1
#1  0x000000012046a4b0 in gcl_init_GBC ()
#2  0x0000000120468f3c in memprotect_test_reset ()
#3  0x000000012047d284 in main ()

\start
Date: Sat, 25 Sep 2004 20:45:08 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Hi Martin:

Martin Rubey wrote:
> 
> Dear William,
> 
> hope I'm not annoying you...
Not at all. When I said "I am pressed for time", I simply meant that at that
time, I would not be able to answer or test code as thoroughly as I would like
and it was an apologetic remark. 

>  > This result is wrong since I can change x to another symbol and the result
>  > would be the same:
> 
> I'm not so sure about "wrong". One (not me...) could argue that the two
> univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I (!)
> would say that this behaviour should be reserved for SUPs. 

Yes, when univariate polynomials are interpreted as functions in the
mathematical sense, 3*x+1 and 3*t+1 are the same (x, t are dummy variables or
placeholders for the functions). But this is seldom the interpretation in
symbolic computation.  Here, we are getting closer to a discussion on what
"equality" means, a well-understood problem with many possibilities but no clear
choice that would work for all situations. I am not sure what "this behaviour"
refers to, or why SUPs are more appropriate.

> And indeed, axiom
> does say that
> 
> ((x::UP(x, INT))=(t::UP(t, INT)))::Boolean
> 
> is false.

Again, at the risk of being repetitve, be careful here. Your axiom line above
means first defining an equation x=t (in the domain Equation UP(x, UP(t, INT))
after automatic coercion) and then coercing to Boolean in that same domain,
which then gives false. The action Axiom takes is NOT the same as in the case

   g:Boolean:= ((x::UP(x, INT))=(t::UP(t, INT)))

even though the results are the same. The subtle difference lies in side-effects
while getting to the result. In the first instance, it looks for a domain T:
Type and a signature for [equation:(T,T)->Equation(T)], while in the latter, a
domain S:SetCategory and a signature for ["=": (S,S)-> Boolean].

>  > So I think this is a bug in the interpreter. Instead of trying to be helpful
>  > to search for an "=" that returns Boolean for the types given on the lhs and
>  > rhs, it should simply first check whether the two sides have the same type
>  > and then whether equality testing "=" exist for that type. No automatic
>  > coercion should be done.
> 
> I'm very unsure about this. Note that when you look at the corresponding EQ
> types (if you do not coerce to Boolean), everything looks sane. I do understand
> that the domain EQ is not involved when you do ask for a boolean immediately,
> but I wouldn't hurry here.

Equation(T) only needs T:Type. Equation(T) has CoercibleTo(Boolean) if
T:SetCategory.  I wish Axiom had not overloaded the operator "=" but say used
"=?" for boolean (indeed, I like it to always use an identifier ending with ?
for all functions with codomain Boolean). There is really no good reason to
coerce lhs and rhs to a common S:SetCategory if lhs and rhs are not already in
the same domain, then they are not equal, period, even if a test for equality
has not been implemented. Note that lhs and rhs are always evaluated (and
presumably simplified to $Rep form) before the test. If they do not belong to
the same domain, why should they be equal in a super-domain? Of course, if they
do not belong to the same domain (without coercion), no ["="] will be found and
so no result will be output; but in that case, an error message is the correct
response (and the error should be trapped via a throw/catch mechanism) -- it is
like someone writes an *equality* where the lhs and rhs does not have the same
fundamental dimensions of time, length, mass -- it is an error that should be
caught. Note that to coerce the lhs and rhs to a common domain T to use
[equation] would make sense in some cases, because after all, we could have
written the equation as lhs-rhs=0 if the domain T has AbelianGroup and we may
want to solve the equation. 


> It seems that there is a fundamental misunderstanding concerning my intention
> with regards to the semantics of UP(x, POLY INT). You wrote
> 
>  > There is one problem with the
>  >
>  >     member?(x, variables(r))
>  >
>  > condition. If R is EXPR INT, and if x occurs in r say as 1/x or as sin(x), I
>  > would think that variables(r) would have x as a member, and so you would receive
>  > the error message when coerce is called. But according to your intention, you
>  > may still want to coerce r (that is, in my terminology, reformat r) to look like
>  > UP(x, EXPR INT).
> 
> In fact, an error message is exactly what I'd like to see for
> (1/x)::UP(x, EXPR INT).

Sorry, Martin, I probably misunderstood it when you wrote on
Wed, 22 Sep 2004 17:08:07 +0000:

> On the other hand, it is easy to clarify the semantics of types like 
> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
> domain. 

I took that to mean it is easy to view (reformat) an expression such as
x^2 sin(x) - cos(x)/x as a polynomial in x and so UP(x, EXPR INT) makes sense
even when x wears two hats.

> I try to get it right now: (It may be that my current position differs from
> that I had some months ago, but it was constant in the last few weeks. Save I
> made a mistake)
> 
> For any polynomial (or series) domain that has a specified list of variables, I
> want that axiom ensures that any coefficient of a member does not contain one
> of these variables. Examples:
> 
> (1/x)::UP(x, EXPR INT) produces an error
> x*2^x::UP(x, EXPR INT) produces an error
> (1/x)::UP(x, FRAC POLY INT) produces an error
> (1/x)::UTS(FRAC POLY INT,x,0) produces an error

I am not sure. If UP(x, EXPR INT) is a valid domain (which it is at present),
then all the above can be regarded as in the ground ring EXPR INT.
> 
> however, for example
> 
> x*2^y::UP(x, EXPR INT) is ok.
> 
> More generally, the "outermost" domain "takes" all the variables:

In that case, you would forbid expressions like x^2 sin(x) - cos(x)/x in UP(x,
EXPR INT), where the expression can either be considered as in the ground ring
EXPR INT, or as a polynomial of degree 2. I don't think the second view is
necessarily "wrong," just that Axiom at present does not do this conversion
consistently. I gave some examples where the built-in coercions led to
inconsistencies in [degree]. 
 
> POLY EXPR INT would be the domain of polynomials with coefficients that do not
> contain any variables. For example,
> 
> (x*sin(2))::POLY EXPR INT would be ok
> (x*sin(y))::POLY EXPR INT would produce an error.

Again, I am not sure why the second one should be an error and the first is not,
if POLY EXPR INT is allowed at all. In both cases, the element may be
interpreted either as in EXPR INT, or a linear polynomial with coefficient in
EXPR INT. Neither is mathematically wrong and each is useful. The problem is
each element may have two different data representations, and the[:: POLY EXPR
INT] does not say specifically what data representation should be used. We need
a clearer way to make the choice. Using a hidden and probably unjustified
convention that the "outer domain takes all the variables" is questionable. 

> The domain EXPR POLY INT would be strictly the same as EXPR INT, I think.

No, we are not talking about mathematics, but data structure. I think we agree
that the current semantics allowed is ambiguous and for this reason, any
reformating should be done with specific variables.

> 
> On the other hand, there is a completely different solution to the original
> problem, i.e., providing a domain like UP(x, EXPR INT) with good semantics:
> 
> > > Yes. I'm inclined to think that this is the best way to go: create a domain
> > > EXPR(VarSet, CoeffSet) and forbid all of the above constructions: UP(x, POLY
> > > ?), UP(x, FRAC POLY ?), UP(x, EXPR ?) and so on...
> >
> > Good. I am glad we are beginning to agree. However, your point of creating
> > something like sin(2) x somewhere should be considered carefully.
> 
> sin(2)*x would be in UP(x, EXPR([], INT)). Did you mean that?

Yes. For the sake of completeness, let me quote what I wrote on 
Wed, 22 Sep 2004 15:20:14 -0400:
before further comments.
------- quote
> Well, I think that EXPR POLY INT (and similarly POLY EXPR INT) should be
> forbidden, since it is not clear where the variables belong.

AGREED!

> On the other hand, it is easy to clarify the semantics of types like 
> UP(x, EXPR INT): x belongs to UP, and 1/x, 2^x, sin x are not members of this
> domain. I don't think that there is another way to make sense of such a
> domain. That's the reason for the question I started with, in fact.

But so should UP(x, EXPR INT). You are inconsistent in the application of your
logic: according to the above, POLY EXPR INT is equally fine (just that there
may be more variables). But back to UP. EXPR INT can also contain polynomials in
x in addition to 1/x, 2^x, sin x. In fact:

(15) sin(x)*x + sin(x)*x^2
     (x^2 + x)sin(x)            Type Expression Integer

This regrouping is automatic. If you rather prefer the input form, which
separates the powers of x, I think you should use a package to provide the
conversion WITHIN EXPR INT and where you also change the outputform. In Axiom,
the domains correspond to mathematical objects, and to have x in BOTH EXPR INT
and UP(x, EXPR INT) is not right since mathematically, the two are the same, as
underlying set and all operations on it. Indeed, any operation in UP(x, EXPR
INT), say multiplication by sin(x) or 1/x, or even by x, will immediately need
to reconvert UP(x, EXPR INT) back to EXPR INT --- a difficult dilemma because
you now have to consider UP(x,EXPR INT) elements as ground elements (ground? may
fail, in general, though not here), perform the operation, and reformating back
to UP(x, EXPR INT). This really shows that the only thing you can achieve is
reformatting output and so it should be done that way.

If you are not mixing x in both places, then something like UP(y,
EXPR([a,b],INT)) may make sense where a new EXPR with specified variables is
constructed.
----- end quote

Actually, I think it is possible to implement something like EXPR([a,b], INT).
The current discussion arose all because EXPR (and by dependencies, also FS and
perhaps more like ES) uses Symbol as default variable set (same as POLY).
Whereas POLYCAT is parametrically constructed with good control for the
variables set AND its ordering, EXPR and FS do not provide such control. So we
need to study how to add such control without breaking any established code.

As a preliminary suggestion, I propose to generalize the FS category
constructors analogous to POLYCAT:
    FunctionSpaceCategory(V:OrderedSet, R: OrderedSet):Category
with abbreviation FSCAT.

This will be done by suitably modifying the existing FunctionSpace(R) code. Then
we can "capture" back FunctionSpace(R) by:
    FunctionSpace(R:OrderedSet):Category == FSCAT(Symbol, R)

In a similar way, we can generalize Expression. (I was thinking about a category
constructor ExpressionCategory, but I think this would be the same as
FunctionSpaceCategory).

    MultivariateExpression(V:OrderedSet, R: OrderedSet):FSCAT(V,R)

to be abbreviated as MEXPR, and recapture Expression as:

    Expression(R:OrderedSet):FS(R)== MEXPR(Symbol, R)

We can also have SparseMultivariateExpression if someone can think of a suitable
data structure.

The next thing would be to put in controls to disallow towers to ensure that no
intermediate extensions involve Symbol as the variable set.

> ------------------------------------------------------------------------
> 
> However, currently this seems unachievable. At least I don't know how to do
> it. Your suggestion to extend axiom to allow
> 
>  > Ideally, perhaps we can try:
>  >
>  >      if S has variables: S -> List V where V:OrderedSet then
>  >        variables: % -> List V
>  >        variables f ==
>  >           mymerge(variables(numer(f)), variables(denom(f)))
> 
> seems most appealing to me, although I don't think this could be done in the
> near future. I read a bit about the "post-facto" extensions provided by aldor,
> maybe they adress this problem too. I'm not sure that I've understood them well
> enough, though.
> 
> PS: In fact, I can think of a way to do it: provide a function
> variables2: % -> List Any in POLYCAT that simply wraps up the function
> variables:% -> List VarSet.
> 
> Then I can provide a function variables2 in QFCAT. The only tricky part is that
> I need the operation "<" from VarSet in QFCAT (for mymerge) and I don't know of
> a *good* way to get it. I do know an ugly way: provide a function
> (Any, Any)->Boolean in POLYCAT that wraps "<" from VarSet.
> 
> Maybe there is a better way, but I'm tired now.

Take a rest! Yes, someone who is experienced with Aldor may tell us whether to
move there or it is still possible to patch Axiom.  However, I think using Any
should be a last resort, even though this may be the only way under Axiom to
treat functions as first class. The trouble with this type of construct is that
the interpreter cannot handle dynamic signature as nicely as the compiler, but
the interpreter can step through code whereas the compiler cannot.

> -------------------------------------------------------------------------
> 
> just for the record:
> 
> > > I agree, if there remains a clear design. For example, I find the wealth of
> > > polynomial domains and packages a little confusing:
> > >
> > > polycat.spad
> > > poly.spad
> > > newpoly.spad
> > > rf.spad
>     gdpoly.spad
>     multpoly.spad
>     prtition.spad
>     xlpoly.spad
>     xpoly.spad
>     wtpol.spad
>     ...
> 
Wait till we get all the varieties of EXPR (and dare I mention DPOLYCAT or
DEXPR?)

\start
Date: Sun, 26 Sep 2004 19:55:46 +0200
From: Hans Peter Wuermli Hans Peter Wuermli
To: Bill Page, "'Bob McElrath'" <Bob McElrath>
Subject: Re: Axiom crashing in Zope-Plone

Dear Bob, Bill

Thank you both for the help. Even though most of the times I am rather 
interested in understanding how something works, this time I was just as 
interested in getting it to run. And thanks to your help, it did.

As Bob mentioned that it could be a problem with the build I used, I 
downloaded the source and for the last 6 1/2 hours my computer was compiling 
(it still is but just the documentation). (By the way: the only compile 
problem I had were scripts in scr/scripts without the exe bit set.)

I had looked a long time what a WEXITSTATUS of 139 meant. Even though some 
mail I found expressed 139 as 128 + 11 with 11 the termination signal for a 
segmentation faulting process, I still have not found (or understood) in the 
linux source the line it says so. Some Posix text said: status for signal 
should be higher than 128 (but without a hint for a standard). So I have no 
doubt that the 139 expresses that Axiom had caused a segmentation fault, easy 
to find and to understand documentation seems rare.

\start
Date: Sun, 26 Sep 2004 14:43:14 -0400
From: Bill Page
To: "'Hans Peter Wuermli'" Hans Peter Wuermli
Subject: RE: Axiom crashing in Zope-Plone
Cc: Camm Maguire

Hans,

Do I understand correctly that after re-compiling Axiom that
you now have a fully operational LatexWiki system under debian
that can run Axiom? If so, congratulations! I think there are
a number of other people (including Tim Daly :) who would very
much like to setup a similar stand alone LatexWiki/Axiom system.

I promised Tim that I would set something up for this, but I
have not yet had the time. If you have some time to write up a
short description of how you did it, I think it would be most
appreciated.

Did you download the binary version of Axiom that failed from
debian unstable? If so, we should be sure to let Camm Maguire
know since he is the architect of the debian version. What
version of GCL are you using for the re-compile? What is the
hardware platform that you are using?

Regards,
Bill Page.

> -----Original Message-----
> From: 
> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org 
> .org] On Behalf Of Hans Peter Wuermli
> Sent: Sunday, September 26, 2004 1:56 PM
> To: Bill Page; 'Bob McElrath'
> Cc: list
> Subject: Re: Axiom crashing in Zope-Plone
> 
> 
> 
> Dear Bob, Bill
> 
> Thank you both for the help. Even though most of the times I 
> am rather interested in understanding how something works,
> this time I was just as interested in getting it to run. And
> thanks to your help, it did.
> 
> As Bob mentioned that it could be a problem with the build I
> used, I downloaded the source and for the last 6 1/2 hours my 
> computer was compiling (it still is but just the documentation).
> (By the way: the only compile problem I had were scripts in
> scr/scripts without the exe bit set.)
> 
> I had looked a long time what a WEXITSTATUS of 139 meant. Even
> though some mail I found expressed 139 as 128 + 11 with 11 the 
> termination signal for a segmentation faulting process, I still
> have not found (or understood) in the linux source the line it
> says so. Some Posix text said: status for signal should be higher
> than 128 (but without a hint for a standard). So I have no doubt
> that the 139 expresses that Axiom had caused a segmentation fault,
> easy to find and to understand documentation seems rare.

\start
Date: Sun, 26 Sep 2004 21:27:53 +0200
From: Hans Peter Wuermli Hans Peter Wuermli
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone

Dear Bill

On Sunday 26 September 2004 20.43, you wrote:

> Do I understand correctly that after re-compiling Axiom that
> you now have a fully operational LatexWiki system under debian
> that can run Axiom? 

Yes. There is some small alignment problem (on the axiom bar, 'axiom' is too 
far to the right and 'axiom''s font is too small, i.e. it looks slightly 
different that on your server), but otherwise everything looks nice and seems 
to work just great.

> I think there are 
> a number of other people (including Tim Daly :) who would very
> much like to setup a similar stand alone LatexWiki/Axiom system.
> I promised Tim that I would set something up for this, but I
> have not yet had the time. If you have some time to write up a
> short description of how you did it, I think it would be most
> appreciated.

Promised, I will do that, but it might take one or two weeks. I would like to 
repeat the procedure myself and do it "cleanly". I messed around, because I 
didn't know where the error stemmed from. Unfortunately, my bread job will 
keep me quite busy the next week, so I ask for some patience.

> Did you download the binary version of Axiom that failed from
> debian unstable? 

Yes, but in the meantime it seems to have become "testing".

> If so, we should be sure to let Camm Maguire 
> know since he is the architect of the debian version. What
> version of GCL are you using for the re-compile? 

2.6.3, the one that comes with the sources. The Debian version used 2.6.4 as 
far as I remember.

> What is the 
> hardware platform that you are using?

i386. Debian is based on the Net Installation, which installs Sarge. The 
kernel I run is 2.6.7-1, but there are so many ways to describe the 
particularities of a system that I wait and answer questions about it, when I 
get them.

Thanks again for your great help and interest.

\start
Date: Sun, 26 Sep 2004 12:48:18 -0700
From: Bob McElrath <bob+debian-user@mcelrath.org>
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone
Cc: Camm Maguire, 'Hans Peter Wuermli' Hans Peter Wuermli


Bill Page [Bill Page] wrote:
> Hans,
> 
> Do I understand correctly that after re-compiling Axiom that
> you now have a fully operational LatexWiki system under debian
> that can run Axiom? If so, congratulations! I think there are
> a number of other people (including Tim Daly :) who would very
> much like to setup a similar stand alone LatexWiki/Axiom system.

And me!

But we really need to have people setting this up in a chroot jail.  I
have been reading up on this...we need a script to create the jail.

> I promised Tim that I would set something up for this, but I
> have not yet had the time. If you have some time to write up a
> short description of how you did it, I think it would be most
> appreciated.

I would like to distribute axiom support with LatexWiki.  I have tied my
version numbers to ZWiki, and they will release 0.35 on 10/1.  Do you
think we could add this by then?  (or maybe a bit after to ensure 0.35
compatability)

Bill our darcs repos have diverged, your patches no longer apply cleanly
to latexwiki.  I have moved the functions 'runCommand' and 'log' into
util.py so that they can be used by axiom/reduce.  There are a couple
other conflicts too (I improved plone/stylesheet in latexwiki.css).  Why
do you have a font-size +2 in your latexwiki.css?  Will you have time to
merge this in the next week or two?

FYI, I have gotten MathML/LatexWiki working in Plone::

    http://mcelrath.org/Plone/ITeXTest

You will need my zwiki patches to do that::

    http://bob.mcelrath.org/darcs/zwiki

Hopefully I will get those into ZWiki 0.35 but I haven't been able to
get Simon's attention in the last couple of days.  ;)  As a reminder my
latexwiki repo is here::

    http://bob.mcelrath.org/darcs/latexwiki

> Did you download the binary version of Axiom that failed from
> debian unstable? If so, we should be sure to let Camm Maguire
> know since he is the architect of the debian version. What
> version of GCL are you using for the re-compile? What is the
> hardware platform that you are using?

Mine is a debian binary::

    (0)<mcelrath@moya:~> dpkg -l axiom
    Desired=Unknown/Install/Remove/Purge/Hold
    | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
    |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
    ||/ Name              Version           Description
    +++-=================-=================-==================================================
    ii  axiom             0.20040831-1      A general purpose computer algebra system: main bi
    (0)<mcelrath@moya:~> axiom
    Segmentation fault

This is the alpha architecture.

If I understand correctly, GCL is compiled-in?  I do not have gcl itself
installed on this machine.

\start
Date: Sun, 26 Sep 2004 17:30:15 -0400
From: Tim Daly
To: bob+debian-user@mcelrath.org
Subject: Re: Axiom crashing in Zope-Plone
Cc: Camm Maguire, Bill Page,	Hans Peter Wuermli

Bill,

Yes, I'd like to have instructions to get a stand-alone version working.
I'm planning to put a modified stand-alone version on the Doyen live CD.
Currently I can almost build the Doyen CD except that the instructions
don't quite match so I'm still struggling with it. Once I get it fully
bootable the next task will be to install Axiom followed almost immediately
with installing MathAction.

\start
Date: 26 Sep 2004 21:15:29 -0400
From: Camm Maguire
To: Bob McElrath <bob+debian-user@mcelrath.org>
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, 'Hans Peter Wuermli' Hans Peter Wuermli

Greetings!  My apologies, but I've lost the head of this thread.  I'm
assuming that there is a segfault problem with debian alpha axiom
(unstable).  (GCL is built in btw).  I'm also assuming the problem
shows up on startup.  In this case, I cannot reproduce -- just
downloaded the binaries and installed on escher.debian.org's unstable
dchroot.  Of course you can only run these on Debian testing or
unstable due to the libc et.al dynamic dependencies.  Is that the
problem?  If any of this is close, please fill in a detailed way I can
reproduce the crash, or better yet, send a copy both to me and to the
Debian BTS.  'reportbug' is good for this.

For the package to build, btw, the compiled axiom must successfully
run the full input test suite, so the very existence of the alpha
package means that this was done.  You can find a log on
buildd.debian.org if interested.

Take care,

Bob McElrath <bob+debian-user@mcelrath.org> writes:

> Bill Page [Bill Page] wrote:
> > Hans,
> > 
> > Do I understand correctly that after re-compiling Axiom that
> > you now have a fully operational LatexWiki system under debian
> > that can run Axiom? If so, congratulations! I think there are
> > a number of other people (including Tim Daly :) who would very
> > much like to setup a similar stand alone LatexWiki/Axiom system.
> 
> And me!
> 
> But we really need to have people setting this up in a chroot jail.  I
> have been reading up on this...we need a script to create the jail.
> 
> > I promised Tim that I would set something up for this, but I
> > have not yet had the time. If you have some time to write up a
> > short description of how you did it, I think it would be most
> > appreciated.
> 
> I would like to distribute axiom support with LatexWiki.  I have tied my
> version numbers to ZWiki, and they will release 0.35 on 10/1.  Do you
> think we could add this by then?  (or maybe a bit after to ensure 0.35
> compatability)
> 
> Bill our darcs repos have diverged, your patches no longer apply cleanly
> to latexwiki.  I have moved the functions 'runCommand' and 'log' into
> util.py so that they can be used by axiom/reduce.  There are a couple
> other conflicts too (I improved plone/stylesheet in latexwiki.css).  Why
> do you have a font-size +2 in your latexwiki.css?  Will you have time to
> merge this in the next week or two?
> 
> FYI, I have gotten MathML/LatexWiki working in Plone::
> 
>     http://mcelrath.org/Plone/ITeXTest
> 
> You will need my zwiki patches to do that::
> 
>     http://bob.mcelrath.org/darcs/zwiki
> 
> Hopefully I will get those into ZWiki 0.35 but I haven't been able to
> get Simon's attention in the last couple of days.  ;)  As a reminder my
> latexwiki repo is here::
> 
>     http://bob.mcelrath.org/darcs/latexwiki
> 
> > Did you download the binary version of Axiom that failed from
> > debian unstable? If so, we should be sure to let Camm Maguire
> > know since he is the architect of the debian version. What
> > version of GCL are you using for the re-compile? What is the
> > hardware platform that you are using?
> 
> Mine is a debian binary::
> 
>     (0)<mcelrath@moya:~> dpkg -l axiom
>     Desired=Unknown/Install/Remove/Purge/Hold
>     | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
>     |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
>     ||/ Name              Version           Description
>     +++-=================-=================-==================================================
>     ii  axiom             0.20040831-1      A general purpose computer algebra system: main bi
>     (0)<mcelrath@moya:~> axiom
>     Segmentation fault
> 
> This is the alpha architecture.
> 
> If I understand correctly, GCL is compiled-in?  I do not have gcl itself
> installed on this machine.

\start
Date: Sun, 26 Sep 2004 23:22:49 -0400
From: Bill Page
To: "'Bob McElrath'" <bob+debian-user@mcelrath.org>
Subject: Axiom support with LatexWiki

On Sunday, September 26, 2004 3:48 PM Bob McElrath
bob+debian-user@mcelrath.org wrote:
> ... 
> But we really need to have people setting this up in a chroot
> jail.  I have been reading up on this...we need a script to
> create the jail.

This would certainly be desirable for Internet use (such as on
MathAction), but for stand alone (localhost only) access it is
not so relevant.

The concept of the "Doyen" that Tim is pursuing is that people
will install a local copy of LatexWiki and use it as an Axiom
front-end. Some of the local pages would later be uploaded to
an Internet accessible system like MathAction. The idea is that
(most) people prefer to make mistakes and learn in private in
an environment that they trust (their own machine). If the
uploading and downloading of pages can be made reasonably
seamless, then this model might go at least part way to solving
the collaboration problem - it helps people avoid the perception
of loss of control and lack of privacy that some people associate
with using web-based systems.

> 
> > I promised Tim that I would set something up for this, but I
> > have not yet had the time. If you have some time to write up
> > a short description of how you did it, I think it would be
> > most appreciated.
> 
> I would like to distribute axiom support with LatexWiki.  I 
> have tied my version numbers to ZWiki, and they will release
> 0.35 on 10/1.  Do you think we could add this by then?  (or
> maybe a bit after to ensure 0.35 compatibility)
> 

I am willing to help but I still don't know enough to make this
happen. I would say that it depends on your own availability.

> Bill our darcs repos have diverged, your patches no longer 
> apply cleanly to latexwiki.  I have moved the functions
> 'runCommand' and 'log' into util.py so that they can be used
> by axiom/reduce.  There are a couple other conflicts too
> (I improved plone/stylesheet in latexwiki.css).  Why do you
> have a font-size +2 in your latexwiki.css?

Honestly, I forget. I think it must have had something to do
with trying to get proper image-text alignment - which is still
not quite right and I don't know why. The alignment is fine
on your site but has never been quite right on MathAction. As I
recall there are some differences in the versions of ghostscript
and PIL between your setup and the one on MathAction. But I
don't know enough to say whether that is the cause or even if
it is, what would be the fix (other than backing out to
previous versions ):

> Will you have time to merge this in the next week or two?

Do you mean: upgrade MathAction to the newest LatexWiki and ZWiki
and record compatible changes in the MathAction repository?
Answer: Maybe, but don't count on it. If I can, it will be
before Thursday this week. After that I am tied up for nearly
a month and I want to get this "pamphlet" thing working before
that.

> 
> FYI, I have gotten MathML/LatexWiki working in Plone::
> 
    http://mcelrath.org/Plone/ITeXTest

I like the way you have configured Plone! Simpler. I think
I might try to make the Axiom Portal look more like that.

> You will need my zwiki patches to do that::

    http://bob.mcelrath.org/darcs/zwiki

> Hopefully I will get those into ZWiki 0.35 but I haven't
> been able to get Simon's attention in the last couple of
> days.  ;)

MathML is not a priority for me right now but the new version
of Reduce (not yet on MathAction) is supposed to be able to
generate MathML directly. It might be interesting to compare
the results of directly generated MathML versus LaTeX to MathML
via ITeX.

\start
Date: Mon, 27 Sep 2004 13:51:05 +0000
From: Martin Rubey
To: William Sit
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

William Sit writes:

> Martin Rubey wrote:

> > I'm not so sure about "wrong". One (not me...) could argue that the two
> > univariate polynomials 3*x+1 and 3*t+1 are the same. On the other hand, I
> > (!)  would say that this behaviour should be reserved for SUPs.

> Yes, when univariate polynomials are interpreted as functions in the
> mathematical sense, 3*x+1 and 3*t+1 are the same (x, t are dummy variables or
> placeholders for the functions). But this is seldom the interpretation in
> symbolic computation.  Here, we are getting closer to a discussion on what
> "equality" means, a well-understood problem with many possibilities but no
> clear choice that would work for all situations. I am not sure what "this
> behaviour" refers to, or why SUPs are more appropriate.

I mean (using your terminology): 

"interpreting polynomials as functions" -> "use SUPs, please!"

> > And indeed, axiom does say that
> > ((x::UP(x, INT))=(t::UP(t, INT)))::Boolean
> > is false.

> Again, at the risk of being repetitve, be careful here. 

Oops, thank you. I did not really understand. This made it clear to me:

> In the first instance, it looks for a domain T: Type and a signature for
> [equation:(T,T)->Equation(T)], while in the latter, a domain S:SetCategory
> and a signature for ["=": (S,S)-> Boolean].

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

> Equation(T) only needs T:Type. Equation(T) has CoercibleTo(Boolean) if
> T:SetCategory.  I wish Axiom had not overloaded the operator "=" but say used
> "=?" for boolean (indeed, I like it to always use an identifier ending with ?
> for all functions with codomain Boolean). There is really no good reason to
> coerce lhs and rhs to a common S:SetCategory if lhs and rhs are not already
> in the same domain, then they are not equal, period, even if a test for
> equality has not been implemented. Note that lhs and rhs are always evaluated
> (and presumably simplified to $Rep form) before the test. If they do not
> belong to the same domain, why should they be equal in a super-domain? Of
> course, if they do not belong to the same domain (without coercion), no ["="]
> will be found and so no result will be output; but in that case, an error
> message is the correct response (and the error should be trapped via a
> throw/catch mechanism) -- it is like someone writes an *equality* where the
> lhs and rhs does not have the same fundamental dimensions of time, length,
> mass -- it is an error that should be caught. Note that to coerce the lhs and
> rhs to a common domain T to use [equation] would make sense in some cases,
> because after all, we could have written the equation as lhs-rhs=0 if the
> domain T has AbelianGroup and we may want to solve the equation.

I think you are right. When I get to it, I'll set up a MathAction page
summarizing all this.

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

The following is all under the hypothesis that we want to find valid and clear
semantics for domains like UP(x, EXPR INT). (I believe we do)

> > For any polynomial (or series) domain that has a specified list of
> > variables, I want that axiom ensures that any coefficient of a member does
> > not contain one of these variables. Examples:

> > (1/x)::UP(x, EXPR INT) produces an error
> > x*2^x::UP(x, EXPR INT) produces an error
> > (1/x)::UP(x, FRAC POLY INT) produces an error
> > (1/x)::UTS(FRAC POLY INT,x,0) produces an error

> I am not sure. If UP(x, EXPR INT) is a valid domain (which it is at present),
> then all the above can be regarded as in the ground ring EXPR INT.

Well, this depends on the semantics we want for a domain like UP(x, EXPR
INT). I argue that, *if* we want that something like UP(x, EXPR INT) makes
sense, then the only sane choice is, that the "outermost" domain "takes" all
the variables. Otherwise we will run into trouble sooner or later. Moreover,
I don't see any need for a domain UP(x, EXPR INT) as it is interpreted
currently, i.e., that allows members like 1/x or x*sin(x). 

> > More generally, the "outermost" domain "takes" all the variables.

> In that case, you would forbid expressions like x^2 sin(x) - cos(x)/x in
> UP(x, EXPR INT), where the expression can either be considered as in the
> ground ring EXPR INT, or as a polynomial of degree 2.

Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this
could be viewed as a polynomial. Of course, this argument is based on the idea
that x=x, i.e, there shouldn't be different x's in one expression.

> I don't think the second view is necessarily "wrong," just that Axiom at
> present does not do this conversion consistently. I gave some examples where
> the built-in coercions led to inconsistencies in [degree].

I'm pretty sure that it is next to impossible to do this conversion
consistently. For example:

(14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT)

   (14)  1
                    Type: Fraction UnivariatePolynomial(x,Expression Integer)
(15) -> x::UP(x, EXPR INT)/x::EXPR INT

         1
   (15)  - x
         x
                             Type: UnivariatePolynomial(x,Expression Integer)

are both completely correct, given the strange semantics of UP(x, EXPR INT).

> > POLY EXPR INT would be the domain of polynomials with coefficients that do not
> > contain any variables. For example,
> > 
> > (x*sin(2))::POLY EXPR INT would be ok
> > (x*sin(y))::POLY EXPR INT would produce an error.
> 
> Again, I am not sure why the second one should be an error and the first is not,
> if POLY EXPR INT is allowed at all. In both cases, the element may be
> interpreted either as in EXPR INT, or a linear polynomial with coefficient in
> EXPR INT. Neither is mathematically wrong and each is useful. 

I agree that the second example is on the borderline. However, if we were to
allow it, the description of the new semantics of POLY EXPR INT would be
considerably more complicated. (I even doubt that we could find a good description)

> The problem is each element may have two different data representations, and
> the[:: POLY EXPR INT] does not say specifically what data representation
> should be used.

I wouldn't think in terms of data representations yet. My credo: First
determine good semantics, then worry about how to implement/represent them.

> We need a clearer way to make the choice. Using a hidden and probably
> unjustified convention that the "outer domain takes all the variables" is
> questionable.

I disagree: I am convinced that this convention is clear. The only other choice
for me would be to depreciate these domains.

> > The domain EXPR POLY INT would be strictly the same as EXPR INT, I think.

> No, we are not talking about mathematics, but data structure. I think we
> agree that the current semantics allowed is ambiguous and for this reason,
> any reformating should be done with specific variables.

I would like to have a mapping from maths to axiom as clear as possible. And
given the convention that the "outermost" domain "takes" all the variables (it
can), EXPR POLY INT and EXPR INT would be the same mathematically, since any
polynomial is an EXPR. Of course, the representations could be different in the
two domains.

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

I agree on everything you say about expressions with specified variables.


> > ---------------------------------------------------------------------------

I don't have anything clever to say right now about defining a wrapper of
"variables" that has values in Any.

If we want to follow the convention "outermost domain takes all variables it
can" we can simply add a function "variables: % -> List Symbol" to QFCAT (or
wherever it should go), since we only want to test for symbols right now.

Note that only the interpreter catches bogus like UP(x, UP(x, INT)) right
now. It may be an option to change the interpreter rather than the library, but
I think this is the wrong direction to go. BTW: Do you (or anybody else reading
this) know how the interpreter catches this? In fact, it is broken anyway:

(12) -> x::UP(x,UP(x,INT))
 
   UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) is not a 
      valid type.
(12) -> monomial(1,1)$UP(x,UP(x,INT))

   (12)  x
                Type: UnivariatePolynomial(x,UnivariatePolynomial(x,Integer))

Thus I think the direction to go is to put these checks into the compiler.

> > -------------------------------------------------------------------------
> > 
> > just for the record:
> > 
> > > > I agree, if there remains a clear design. For example, I find the wealth of
> > > > polynomial domains and packages a little confusing:
> > > >
> > > > polycat.spad
> > > > poly.spad
> > > > newpoly.spad
> > > > rf.spad
> >     gdpoly.spad
> >     multpoly.spad
> >     prtition.spad
> >     xlpoly.spad
> >     xpoly.spad
> >     wtpol.spad
> >     ...
> > 
> Wait till we get all the varieties of EXPR (and dare I mention DPOLYCAT or
> DEXPR?)

What would DPOLYCAT or DEXPR be?

\start
Date: Tue, 28 Sep 2004 10:29:57 -0400
From: Tim Daly
To: Martin Rubey
Subject: axiom and aldor cooperation (resend)

Amusingly enough, it appears that my post to axiom-legal was
automatically discarded as spam mail. Thus I'll violate my
own rule and post this thru axiom-developer. I do, however,
appreciate your attempt to keep the license-related discussions
in axiom-legal.

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

Martin,

Axiom and Aldor still work together as far as I know. And from discussions
with Stephen they will continue to do so.

I'm not exactly sure that I'm allowed to distribute the Aldor sources
although I do have permission to access those sources. If I were
allowed to distribute the source tarball I'd treat it the same way I
treat other packages I use, namely, verbatim track the latest changes
and guarantee that Axiom correctly builds and runs with those changes.

The current binary requires the user to visit aldor.org and to
agree to the license. This makes it impossible to integrate into
the Axiom build. 

Thus I've done very little in the way of actively pushing Aldor 
in the current Axiom distribution. I'd like to do more as I have a
huge pile of C++ code I'm maintaining, most of which would simply
disappear if I could use Aldor. But the feedback about lack of sources
and licensing issues are just beyond my ability to bear at the moment.

Stephen Watt is the proper person to address the issue.

\start
Date: 28 Sep 2004 14:05:16 -0400
From: Camm Maguire
To: perry@ux2.math.us.edu.pl
Subject: Re: Axiom question

Greetings!

perry@ux2.math.us.edu.pl writes:

> Dear Camm Maguire,
> 
> Being interested in Axiom CAS, I recently downloaded and installed 
> the deb packages prepared by you. Firs of all I would like to express 
> that I deeply appreciate the fact that you prepared such easy-to 
> install version of Axiom. However, I have a question: according to 

Glad to hear it is of use to you!

> the docs, Axiom should have two features that I wasn't able to use. 
> Namely: graphics/drawing capabilities and explorer-interface.
> I just wonder if these features are unavailable in the Debian 
> package or it is something wrong with my configuration.
> 

These are features from the former commercial product which have not
yet been integrated into 'open axiom' upstream.  The date on the
package is that of the cvs snapshot taken of the sources.  You can
follow the progress, and contribute if you would like, at
list.

Take care,

> I tried it on Libranet Linux (off-spring of Debian) on Athlon+512MB 
> RAM+ nVidia GeForce 5200 as well as on my ThinkPad 600 
> notebook with Mandrake 10 (after converting deb->rpm).
> 
> Yours,
> P. Koprowski
> 
> 
> --
> dr Przemyslaw Koprowski
> Faculty of Mathematics
> Silesian University

\start
Date: 28 Sep 2004 14:21:02 -0400
From: Camm Maguire
To: Bob McElrath <bob+debian-user@mcelrath.org>
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, 'Hans Peter Wuermli' Hans Peter Wuermli

Greetings!  Haven't heard anything here -- just wondering if this
issue is still live.

Take care,

Camm Maguire writes:

> Greetings!  My apologies, but I've lost the head of this thread.  I'm
> assuming that there is a segfault problem with debian alpha axiom
> (unstable).  (GCL is built in btw).  I'm also assuming the problem
> shows up on startup.  In this case, I cannot reproduce -- just
> downloaded the binaries and installed on escher.debian.org's unstable
> dchroot.  Of course you can only run these on Debian testing or
> unstable due to the libc et.al dynamic dependencies.  Is that the
> problem?  If any of this is close, please fill in a detailed way I can
> reproduce the crash, or better yet, send a copy both to me and to the
> Debian BTS.  'reportbug' is good for this.
> 
> For the package to build, btw, the compiled axiom must successfully
> run the full input test suite, so the very existence of the alpha
> package means that this was done.  You can find a log on
> buildd.debian.org if interested.
> 
> Take care,
> 
> Bob McElrath <bob+debian-user@mcelrath.org> writes:
> 
> > Bill Page [Bill Page] wrote:
> > > Hans,
> > > 
> > > Do I understand correctly that after re-compiling Axiom that
> > > you now have a fully operational LatexWiki system under debian
> > > that can run Axiom? If so, congratulations! I think there are
> > > a number of other people (including Tim Daly :) who would very
> > > much like to setup a similar stand alone LatexWiki/Axiom system.
> > 
> > And me!
> > 
> > But we really need to have people setting this up in a chroot jail.  I
> > have been reading up on this...we need a script to create the jail.
> > 
> > > I promised Tim that I would set something up for this, but I
> > > have not yet had the time. If you have some time to write up a
> > > short description of how you did it, I think it would be most
> > > appreciated.
> > 
> > I would like to distribute axiom support with LatexWiki.  I have tied my
> > version numbers to ZWiki, and they will release 0.35 on 10/1.  Do you
> > think we could add this by then?  (or maybe a bit after to ensure 0.35
> > compatability)
> > 
> > Bill our darcs repos have diverged, your patches no longer apply cleanly
> > to latexwiki.  I have moved the functions 'runCommand' and 'log' into
> > util.py so that they can be used by axiom/reduce.  There are a couple
> > other conflicts too (I improved plone/stylesheet in latexwiki.css).  Why
> > do you have a font-size +2 in your latexwiki.css?  Will you have time to
> > merge this in the next week or two?
> > 
> > FYI, I have gotten MathML/LatexWiki working in Plone::
> > 
> >     http://mcelrath.org/Plone/ITeXTest
> > 
> > You will need my zwiki patches to do that::
> > 
> >     http://bob.mcelrath.org/darcs/zwiki
> > 
> > Hopefully I will get those into ZWiki 0.35 but I haven't been able to
> > get Simon's attention in the last couple of days.  ;)  As a reminder my
> > latexwiki repo is here::
> > 
> >     http://bob.mcelrath.org/darcs/latexwiki
> > 
> > > Did you download the binary version of Axiom that failed from
> > > debian unstable? If so, we should be sure to let Camm Maguire
> > > know since he is the architect of the debian version. What
> > > version of GCL are you using for the re-compile? What is the
> > > hardware platform that you are using?
> > 
> > Mine is a debian binary::
> > 
> >     (0)<mcelrath@moya:~> dpkg -l axiom
> >     Desired=Unknown/Install/Remove/Purge/Hold
> >     | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> >     |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> >     ||/ Name              Version           Description
> >     +++-=================-=================-==================================================
> >     ii  axiom             0.20040831-1      A general purpose computer algebra system: main bi
> >     (0)<mcelrath@moya:~> axiom
> >     Segmentation fault
> > 
> > This is the alpha architecture.
> > 
> > If I understand correctly, GCL is compiled-in?  I do not have gcl itself
> > installed on this machine.

\start
Date: Tue, 28 Sep 2004 15:15:47 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom crashing in Zope-Plone
Cc: Bill Page, 'Hans Peter Wuermli' Hans Peter Wuermli, Bob McElrath <bob+debian-user@mcelrath.org>

Cam,

The original report from Hans:

  http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00056.html

referred to what later was discovered to be a seg fault
(EXITSTATUS:139 from Python 2.2 popen3) generated by Axiom
when run as a sub-process (popen3). Hans later reported that
the failure occured while running a debian binary version
of Axiom on an Intel i386 box.

In

  http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00059.html

Bob McElrath reported that he obtained the same failure
when trying to run a debian binary version of Axiom as a
sub-process on an Alpha debian system. It also turned
out that Bob observed the seg fault even when Axiom was
not run as a sub-process.

In the message

  http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00062.html

and

  http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00064.html

Hans reported success on the same hardware platform and
debian version but with Axiom re-compiled from source.

In

  http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00065.html

Bob McElrath supplied some details of the debian and
axiom installation on his Alpha system which was still
failing with a seg fault.

Your suggested possible cause being "libc et.al dynamic
dependencies" in the case of Bob's system seems plausible
to me. I expect he will get back to you about this soon.

----------

Since Hans' problem was solved with a re-compile of Axiom
from source (and a different, older? version of gcl) on a
debian Intel platform, I would worry that this might
indicated a memory management problem which is more severe
when Axiom is run as a sub-process - perhaps with limited
physical memory since Python + Zope + LaTeX + +Ghostscript
+ Axiom is a pretty heavy combination.

Hans said that he would be busy with his "day job" for
the next week but that he intended to try to build the
MathAction configuration again from scratch to see he
he gets the same problem and solution.

Thanks for looking into this!

Regards,
Bill Page.

> -----Original Message-----
> From: Camm Maguire [mailto:Camm Maguire]
> Sent: Tuesday, September 28, 2004 2:21 PM
> To: Bob McElrath
> Cc: list; Bill Page; 'Hans Peter Wuermli'
> Subject: Re: Axiom crashing in Zope-Plone
> 
> 
> Greetings!  Haven't heard anything here -- just wondering if this
> issue is still live.
> 
> Take care,
> 
> Camm Maguire writes:
> 
> > Greetings!  My apologies, but I've lost the head of this 
> thread.  I'm
> > assuming that there is a segfault problem with debian alpha axiom
> > (unstable).  (GCL is built in btw).  I'm also assuming the problem
> > shows up on startup.  In this case, I cannot reproduce -- just
> > downloaded the binaries and installed on 
> escher.debian.org's unstable
> > dchroot.  Of course you can only run these on Debian testing or
> > unstable due to the libc et.al dynamic dependencies.  Is that the
> > problem?  If any of this is close, please fill in a 
> detailed way I can
> > reproduce the crash, or better yet, send a copy both to me 
> and to the
> > Debian BTS.  'reportbug' is good for this.
> > 
> > For the package to build, btw, the compiled axiom must successfully
> > run the full input test suite, so the very existence of the alpha
> > package means that this was done.  You can find a log on
> > buildd.debian.org if interested.
> > 
> > Take care,
> > 
> > Bob McElrath <bob+debian-user@mcelrath.org> writes:
> > 
> > > Bill Page [Bill Page] wrote:
> > > > Hans,
> > > > 
> > > > Do I understand correctly that after re-compiling Axiom that
> > > > you now have a fully operational LatexWiki system under debian
> > > > that can run Axiom? If so, congratulations! I think there are
> > > > a number of other people (including Tim Daly :) who would very
> > > > much like to setup a similar stand alone LatexWiki/Axiom system.
> > > 
> > > And me!
> > > 
> > > But we really need to have people setting this up in a 
> chroot jail.  I
> > > have been reading up on this...we need a script to create 
> the jail.
> > > 
> > > > I promised Tim that I would set something up for this, but I
> > > > have not yet had the time. If you have some time to write up a
> > > > short description of how you did it, I think it would be most
> > > > appreciated.
> > > 
> > > I would like to distribute axiom support with LatexWiki.  
> I have tied my
> > > version numbers to ZWiki, and they will release 0.35 on 
> 10/1.  Do you
> > > think we could add this by then?  (or maybe a bit after 
> to ensure 0.35
> > > compatability)
> > > 
> > > Bill our darcs repos have diverged, your patches no 
> longer apply cleanly
> > > to latexwiki.  I have moved the functions 'runCommand' 
> and 'log' into
> > > util.py so that they can be used by axiom/reduce.  There 
> are a couple
> > > other conflicts too (I improved plone/stylesheet in 
> latexwiki.css).  Why
> > > do you have a font-size +2 in your latexwiki.css?  Will 
> you have time to
> > > merge this in the next week or two?
> > > 
> > > FYI, I have gotten MathML/LatexWiki working in Plone::
> > > 
> > >     http://mcelrath.org/Plone/ITeXTest
> > > 
> > > You will need my zwiki patches to do that::
> > > 
> > >     http://bob.mcelrath.org/darcs/zwiki
> > > 
> > > Hopefully I will get those into ZWiki 0.35 but I haven't 
> been able to
> > > get Simon's attention in the last couple of days.  ;)  As 
> a reminder my
> > > latexwiki repo is here::
> > > 
> > >     http://bob.mcelrath.org/darcs/latexwiki
> > > 
> > > > Did you download the binary version of Axiom that failed from
> > > > debian unstable? If so, we should be sure to let Camm Maguire
> > > > know since he is the architect of the debian version. What
> > > > version of GCL are you using for the re-compile? What is the
> > > > hardware platform that you are using?
> > > 
> > > Mine is a debian binary::
> > > 
> > >     (0)<mcelrath@moya:~> dpkg -l axiom
> > >     Desired=Unknown/Install/Remove/Purge/Hold
> > >     | 
> Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-
> installed
> > >     |/ Err?=(none)/Hold/Reinst-required/X=both-problems 
> (Status,Err: uppercase=bad)
> > >     ||/ Name              Version           Description
> > >     
> +++-=================-=================-======================
> ============================
> > >     ii  axiom             0.20040831-1      A general 
> purpose computer algebra system: main bi
> > >     (0)<mcelrath@moya:~> axiom
> > >     Segmentation fault
> > > 
> > > This is the alpha architecture.
> > > 
> > > If I understand correctly, GCL is compiled-in?  I do not 
> have gcl itself
> > > installed on this machine.

\start
Date: Tue, 28 Sep 2004 21:11:51 +0200
From: Hans Peter Wuermli Hans Peter Wuermli
To: Camm Maguire
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, Bob McElrath <bob+debian-user@mcelrath.org>

Sorry, as the origin of the email exchanges I couldn't answer to any of the 
questions (as I was abroad with the priviledge of not having had access to 
email).

Apparently, others than myself are interested in a standalone AxiomWiki. I 
tried a long time to get the axiomWrapper running in ZWiki suspecting missing 
access right and alike to be the cause for the failure. I run Debian testing 
augmented by some Zope products which the Debian distribution does not have. 
Downloading the latest Axiom source, compiling and using the executable got 
everything running. As soon as I'll have time I will write down the details, 
but frankly there were no secrets or tricks necessary. 

Cheers, H.P.

On Monday 27 September 2004 03.15, you wrote:
> Greetings!  My apologies, but I've lost the head of this thread.  I'm
> assuming that there is a segfault problem with debian alpha axiom
> (unstable).  (GCL is built in btw).  I'm also assuming the problem
> shows up on startup.  In this case, I cannot reproduce -- just
> downloaded the binaries and installed on escher.debian.org's unstable
> dchroot.  Of course you can only run these on Debian testing or
> unstable due to the libc et.al dynamic dependencies.  Is that the
> problem?  If any of this is close, please fill in a detailed way I can
> reproduce the crash, or better yet, send a copy both to me and to the
> Debian BTS.  'reportbug' is good for this.
>
> For the package to build, btw, the compiled axiom must successfully
> run the full input test suite, so the very existence of the alpha
> package means that this was done.  You can find a log on
> buildd.debian.org if interested.
>
> Take care,
>
> Bob McElrath <bob+debian-user@mcelrath.org> writes:
> > Bill Page [Bill Page] wrote:
> > > Hans,
> > >
> > > Do I understand correctly that after re-compiling Axiom that
> > > you now have a fully operational LatexWiki system under debian
> > > that can run Axiom? If so, congratulations! I think there are
> > > a number of other people (including Tim Daly :) who would very
> > > much like to setup a similar stand alone LatexWiki/Axiom system.
> >
> > And me!
> >
> > But we really need to have people setting this up in a chroot jail.  I
> > have been reading up on this...we need a script to create the jail.
> >
> > > I promised Tim that I would set something up for this, but I
> > > have not yet had the time. If you have some time to write up a
> > > short description of how you did it, I think it would be most
> > > appreciated.
> >
> > I would like to distribute axiom support with LatexWiki.  I have tied my
> > version numbers to ZWiki, and they will release 0.35 on 10/1.  Do you
> > think we could add this by then?  (or maybe a bit after to ensure 0.35
> > compatability)
> >
> > Bill our darcs repos have diverged, your patches no longer apply cleanly
> > to latexwiki.  I have moved the functions 'runCommand' and 'log' into
> > util.py so that they can be used by axiom/reduce.  There are a couple
> > other conflicts too (I improved plone/stylesheet in latexwiki.css).  Why
> > do you have a font-size +2 in your latexwiki.css?  Will you have time to
> > merge this in the next week or two?
> >
> > FYI, I have gotten MathML/LatexWiki working in Plone::
> >
> >     http://mcelrath.org/Plone/ITeXTest
> >
> > You will need my zwiki patches to do that::
> >
> >     http://bob.mcelrath.org/darcs/zwiki
> >
> > Hopefully I will get those into ZWiki 0.35 but I haven't been able to
> > get Simon's attention in the last couple of days.  ;)  As a reminder my
> > latexwiki repo is here::
> >
> >     http://bob.mcelrath.org/darcs/latexwiki
> >
> > > Did you download the binary version of Axiom that failed from
> > > debian unstable? If so, we should be sure to let Camm Maguire
> > > know since he is the architect of the debian version. What
> > > version of GCL are you using for the re-compile? What is the
> > > hardware platform that you are using?
> >
> > Mine is a debian binary::
> >
> >     (0)<mcelrath@moya:~> dpkg -l axiom
> >     Desired=Unknown/Install/Remove/Purge/Hold
> >
> >     | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-insta
> >     |lled / Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
> >     | uppercase=bad)
> >     |
> >     ||/ Name              Version           Description
> >
> >    
> > +++-=================-=================-=================================
> >================= ii  axiom             0.20040831-1      A general
> > purpose computer algebra system: main bi (0)<mcelrath@moya:~> axiom
> >     Segmentation fault
> >
> > This is the alpha architecture.
> >
> > If I understand correctly, GCL is compiled-in?  I do not have gcl itself
> > installed on this machine.

\start
Date: Tue, 28 Sep 2004 12:38:41 -0700
From: Bob McElrath <bob+debian@mcelrath.org>
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone
Cc: Camm Maguire, 'Hans Peter Wuermli' Hans Peter Wuermli, Bob McElrath <bob+debian-user@mcelrath.org>

Page, Bill [Bill Page] wrote:
> Bob McElrath supplied some details of the debian and
> axiom installation on his Alpha system which was still
> failing with a seg fault.
> 
> Your suggested possible cause being "libc et.al dynamic
> dependencies" in the case of Bob's system seems plausible
> to me. I expect he will get back to you about this soon.

alpha architecture:
    ii  libc6.1           2.3.2.ds1-11      GNU C Library: Shared libraries
axiom segfaults
    ii  libc6.1           2.3.2.ds1-16      GNU C Library: Shared libraries
axiom runs fine

i386 architecture:
    ii  libc6             2.3.2.ds1-12      GNU C Library: Shared libraries
axiom runs fine

Thus, it would appear that the debian package needs to add a dependency
on libc6 2.3.2.ds1-12 or greater.  I do not know why on alpha it is
"libc6.1" and on intel it is "libc6".  

Hans, can you confirm on intel?

\start
Date: Wed, 29 Sep 2004 01:02:01 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Dear Martin:

Martin Rubey wrote:

> "interpreting polynomials as functions" -> "use SUPs, please!"

OK, I see what you meant: the variable in SUP is unspecified. But there is
really not that much difference between UP and SUP (UP is a special extension of
SUP, in fact UP == SUP add coerce: Variable(x)-> UP(x, R)
where coerce(v)== monomial(1,1) and another for coerce to outputform, printing
"x" instead of "?". So x is identified with ? under coerce for input, and ? is
printed as x on output. The only changes are in input/output. See also next
comment.

[...] Regarding [equation] and [equal] :

> I think you are right. When I get to it, I'll set up a MathAction page
> summarizing all this.

That would be very much appreciated. But, perhaps no so fast:
Here is an example worth examining:

supint:=monomial(1,1)$SUP(INT)
suppoly:=monomial(1,1)$SUP(POLY INT)
g:Boolean:= (supint = suppoly)

The interpreter coerced supint:SUP(INT) to SUP(POLY INT) and then returns g as
true. Mathematically (see Lang, Algebra; more discussion later), supint is a
function from Variable(?)->INT with supint(?)=1$INT, and suppoly is a function
from Variable(?)->POLY INT, with suppoly(?)=1$(POLY INT), so as functions they
are different. The coercion means we identify supint with the composition supint
followed by the embedding INT->POLY INT (so that 1$INT is identified with
1$(POLY INT)). This is all mathematically acceptible. So for equality testing
a=b, coercion may be acceptable in certain cases, contrary to what I advocated
last time. I was thinking about the case where a:A, b:B and A is a subdomain of
B, but could not find an example where a=b is true as a statement in B, but b is
not in A. In the above example, A is the domain of functions from
Variable(?)->INT (or if you like, powers of the unspecified variable ?).
Similarly for B. So A is NOT a subdomain of B, but there is an embedding A -> B
induced by INT -> POLY INT. Of course, if we do make this identification, then
suppoly is in SUP(INT). (Axiom does allow this in the package SUP2(R,S)).

suppoly::SUP INT
  ?

So I am no longer sure about banning all automatic coercions for [equal]. But I
don't know how else to avoid contradictions in Axiom if coercion remains the way
it works.

upx:=monomial(1,1)$UP(x,INT)
g:= (supint = suppoly)
  true
g:= (upx = supint)
  true
g:= (upx = suppoly)
  false

Coercing to the common domain SUP POLY INT for the last test may be the cause
for the contradiction.  More interestingly:

upx * supint * suppoly
   2  
  x ?

supint * suppoly * upx
    2
  x?

g:= (upx * supint * suppoly = supint * suppoly * upx)
  false

Exercise: try the other four permutations and predict the results.

> ------------------------------------------------------------------------
> Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this
> could be viewed as a polynomial. Of course, this argument is based on the idea
> that x=x, i.e, there shouldn't be different x's in one expression.
> 
> I'm pretty sure that it is next to impossible to do this conversion
> consistently. For example:
> 
> (14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT)
> 
>    (14)  1
>                     Type: Fraction UnivariatePolynomial(x,Expression Integer)
> (15) -> x::UP(x, EXPR INT)/x::EXPR INT
> 
>          1
>    (15)  - x
>          x
>                              Type: UnivariatePolynomial(x,Expression Integer)
> 
> are both completely correct, given the strange semantics of UP(x, EXPR INT).

The problem is caused by the user in (15). An undeclared x (as in "x ::") is
treated in the interpreter (you must declare for the compiler) as the unique
element of Variable(x). Any time such an x is coerced into UP(y, ?), it will
check if y is x, and if so, return the monomial x in UP(y,?), otherwise it tries
to coerce x into ? when possible, or gives an error if not. As I have pointed
out before, Axiom is not confused, the user is. Axiom cannot possibly rule out
such user behavior because each operation (x::UP(x,?), x::EXPR INT, and /) is
correctly performed. To do so would require Axiom to "look ahead" when
processing x::UP(x,?). This is unreasonable as well as impossible -- how far
ahead? what if the x::EXPR INT is something returned by another routine?

I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now
stands.** Unfortunately, the general and categoric constructs in Axiom make it
difficult to "exclude" specific domains (POLY(R) is valid for any ring R; the
user is allowed to construct POLY(R) for whatever R, even if R is POLY(S). In
fact, I don't know of any Axiom mechanism to exclude specific domains in a
constructor's parameters. (Axiom allows declaring domains to HAVE certain
attributes, but I believe does not allow them to NOT HAVE certain attributes). 

Below, I'll try to analyse where the present problem lies and propose a way to
correct the problem. Even if you agree with my analysis, whether the correction
should be implemented or not is still subject to discussion. 

The problem lies in the original construction of POLY or EXPR: these domains
were meant to be user-friendly, they include any polynomial (or expression) in
whatever variables the user inputs. When a user is "lazy" and works in such
domains, it is implicitly assumed that (s)he is not aware of, or does not care
for, any particular data structure. So it is implicitly assumed that (s)he would
not extend such domains by adding more variables because these domains are
already all-encompassing as far as variables go (but the coefficient domain may
be extended to one that does not involve new variables).

Now if we are to "generalize" the construction of POLY (and in fact the
construction of ANY domain with "variables," whether the set of "variables" is a
specific finite set of symbols or the set of all symbols), then we should go
back to the mathematical meaning of the polynomial ring (see Lang, Algebra,
1965). The set of indeterminates can be ANY set, so that towers like Q[S][T] is
mathematically meaningful for ANY sets S, T (even if S and T are the same set,
because the sets are only used to *index* the indeterminates: recall (Lang, p.
110) that a (primitive) monomial over S is a function f:S -> N (N the monoid of
non-negative integers) of finite support; and a polynomial ring over a ring R
with indeterminates (indexed by) S is the monoid algebra R[S] generated over R
by all (primitive) monomials. Normally, we would simply denote the variable
indexed by s: S by s, but this is "abuse of language" because the "variable"
indexed by s is actually a function and should be named f_s where f_s(s)=1 and
f_s(t) = 0 for t not equal to s. With this more pedantic notation, R[S] is
really $R[(f_s)_{s \in S}]$ (using TeX).  So if after forming R[S], we want to
form R[S][T] where T = S, then by definition, a duplicate set of monomials 
g:T->N is used and R[S][T] is $R[(f_s)_{s \in S}][(g_t)_{t \in T}]$ and no
confusion would arise even when S = T. (You may think of the row index set and
column index set of a square nxn matrix; both are [1..n], but we would use a
different notation say i for row and j for column. Anyone using i for both
indices, especially in programs, ...) 

Now the problem with the current implementation of any polynomial ring (or
Expression(R)) is that such duplicates are not anticipated (or ignored for
efficiency perhaps). If we were to generalize the construction by identifying
the "variables" with an indexed notation (for example, in R[x,y], the x and y
are actually (x,R) and (y,R); in programming terms, prefix or postfix x and y by
an identifier string unique to R much like C++), then we can create towers
without any ambiguity -- assuming no user would know these secret identifiers.
So "the set of all symbols" does not really mean ALL symbols but only those
within some limited constructive rule for symbols. In outputs, we may provide a
switch to turn the identifier part on or off.

In the new generalized version:

)set mess scope on

x::UP(x,EXPR INT)/x::EXPR INT

would output something like:
 
x$UP(x, EXPR INT)/x$(EXPR INT)

and not 1. The tags show the user exactly what is done without having to examine
the sometimes very long output from )set mess bot on.

Let me say that there is pehaps a role for constructs like POLY POLY INT or POLY
EXPR INT.  Examples: computing syzygies of polynomials generating an ideal, or
more generally the defining set of algebraic polynomial (equations) for
algebraic functions -- a (non-linear) system of differential equations is simply
algebraic equations for functions and their derivatives. However, just as POLY
INT is for the "lazy" user, so would the new POLY POLY INT. Any serious
computation should identify (and separate) the variables in towers.

The utlimate question is: is it worth the trouble to generalize? If it is easy
to modify the compiler to add the identifiers, then that would be the easier
route. If not, I'll vote no unless someone shows me an example in a real
computation where this new type of construct is necessary, cannot be done
otherwise, and the benefit outweighs the work required.

> I wouldn't think in terms of data representations yet. My credo: First
> determine good semantics, then worry about how to implement/represent 
> them.
> 
> > We need a clearer way to make the choice. Using a hidden and probably
> > unjustified convention that the "outer domain takes all the variables" 
> > is questionable.
> 
> I disagree: I am convinced that this convention is clear. The only other
> choice for me would be to depreciate these domains.

Unfortunately, the current convention is not "outer domain takes all the
variables." 

)clear all
a:=monomial(1,1)$UP(x, INT)
  x

a::SUP INT
  ?

a::SUP UP(x,INT)
  x

Even though a tower of polynomial rings is involved in the above, these are
legitimate mathematical constructs (and correctly done) -- the unspecified
variable is intended to be transcendental over ANY coefficient domain, and is
often used to work with minimal polynomial of an element algebraic over the
coefficient domain. Here it shows that in coercing a variable into
SUP(R), the interpreter first try to coerce it into R, and failing that, to to
unspecified variable. So in this case, SUP only takes a variable when necessary.
   
> > > The domain EXPR POLY INT would be strictly the same as EXPR INT, I 
> > > think.
> 
> > No, we are not talking about mathematics, but data structure. I think we
> > agree that the current semantics allowed is ambiguous and for this 
> > reason, any reformating should be done with specific variables.
> 
> I would like to have a mapping from maths to axiom as clear as possible. 
> And given the convention that the "outermost" domain "takes" all the
> variables (it can), EXPR POLY INT and EXPR INT would be the same
> mathematically, since any polynomial is an EXPR. Of course, the
> representations could be different in the two domains.

See above discussion on indexed method constructing polynomial rings.
 
> I agree on everything you say about expressions with specified variables.

Good, specified variables is the way to go. After all, what is strong typing
without specificity?

> > > ---------------------------------------------------------------------
> 
> I don't have anything clever to say right now about defining a wrapper of
> "variables" that has values in Any.
> 
> If we want to follow the convention "outermost domain takes all variables
> it can" we can simply add a function "variables: % -> List Symbol" to 
> QFCAT (or wherever it should go), since we only want to test for symbols 
> right now.

I am not convinced the convention is desirable.

> Note that only the interpreter catches bogus like UP(x, UP(x, INT)) right
> now. It may be an option to change the interpreter rather than the 
> library, but I think this is the wrong direction to go. BTW: Do you 
> (or anybody else reading this) know how the interpreter catches this?
> In fact, it is broken anyway:
> 
> (12) -> x::UP(x,UP(x,INT))
> 
>    UnivariatePolynomial(x,UnivariatePolynomial(x,Integer)) is not a
>       valid type.
> (12) -> monomial(1,1)$UP(x,UP(x,INT))
> 
>    (12)  x
>                 Type: UnivariatePolynomial(x,UnivariatePolynomial(x,Integer))

This is the same "error" you found some time ago, where somehow :: is handled
differently from : or coerce. In the second (12), the interpreter can find the
monomial function in $UP(x, *) and so it is happy -- never mind the *. In the
first (12), the interpreter must find the coerce function but don't know which
to pick, even if it did find them. If you packaged call, everything would be ok.

(1) -> coerce(x)$UP(x, UP(x, INT))
       x
(2) -> degree %
       1
(3) -> coerce(coerce(x)$UP(x, INT))$UP(x, UP(x, INT))
       x
(4) -> degree %
       0

I think the failure in (12) is an interpreter problem not able to find the
functions or cannot decide on what the user wants: (1) or (3). The error message
is an "error" in itself. UP(x, UP(x, INT)) seems a perfectly good domain in the
current Axiom system and the two x's are different (I believe in SUP, the
variable is indexed in the sense above; for SUPs with different coefficient
rings, these become equal only when coerced into a SUP with an extended
coefficient ring). This is the nature of SUP from which UP is derived. It's only
the user who assigns the same symbol for I/O, but shouldn't have.

Generally, the Axiom compiler language is more precise and the interpreter
because it tries to be smart, does not always succeed in interpreting user
intentions. Nonetheless, it is still doing quite a good job.

> Thus I think the direction to go is to put these checks into the compiler.

I don't know enough about compilers: Can a compiler single out (12) to disallow
it? For now, just don't use the same symbol for two different things, and
perhaps fix the error message with a warning instead.

> What would DPOLYCAT or DEXPR be?

DPOLCAT already exists (Differential Polynomial Category, sorry for misspelling
of abbreviation -- actually a restriction of abbreviation rules in Axiom to 7
characters to allow for DPOLCAT-). DEXPR would be Differential Expression (these
would involve derivatives or integrals of functions that could not be simplified
such as derivatives of Bessel functions, but also derivatives of other special
functions satisfying higher order differential equations).

\start
Date: Wed, 29 Sep 2004 12:10:30 +0000
From: Martin Rubey
To: William Sit
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Dear William,

I'll only reply to the "mixing up variables" issue, since I do not have a clear
picture of the others yet. On the other hand, it seems to me that our
discussion is more about philosophy, since we agree that MEXPR(vars, Ring) is
the way to go.

William Sit writes:
 > Dear Martin:
 > 
 > Martin Rubey wrote:

 > > Yes. Given x^2 sin(x) - cos(x)/x, no sane mathematician will say that this
 > > could be viewed as a polynomial. Of course, this argument is based on the idea
 > > that x=x, i.e, there shouldn't be different x's in one expression.
 > > 
 > > I'm pretty sure that it is next to impossible to do this conversion
 > > consistently. For example:
 > > 
 > > (14) -> x::UP(x, EXPR INT)/x::UP(x, EXPR INT)
 > > 
 > >    (14)  1
 > >                     Type: Fraction UnivariatePolynomial(x,Expression Integer)
 > > (15) -> x::UP(x, EXPR INT)/x::EXPR INT
 > > 
 > >          1
 > >    (15)  - x
 > >          x
 > >                              Type: UnivariatePolynomial(x,Expression Integer)
 > > 
 > > are both completely correct, given the strange semantics of UP(x, EXPR INT).

 > The problem is caused by the user in (15). An undeclared x (as in "x ::") is
 > treated in the interpreter (you must declare for the compiler) as the unique
 > element of Variable(x). Any time such an x is coerced into UP(y, ?), it will
 > check if y is x, and if so, return the monomial x in UP(y,?), otherwise it
 > tries to coerce x into ? when possible, or gives an error if not. As I have
 > pointed out before, Axiom is not confused, the user is. 

Well, the result *is* confusing. And I don't think that this behaviour could be
useful.

 > Axiom cannot possibly rule out such user behavior because each operation
 > (x::UP(x,?), x::EXPR INT, and /) is correctly performed. To do so would
 > require Axiom to "look ahead" when processing x::UP(x,?). This is
 > unreasonable as well as impossible -- how far ahead? what if the x::EXPR INT
 > is something returned by another routine?

I don't understand: it can! Well, I mean: it could. One possibility is the
following: every domain that has (named) variables should have a function vars:
R -> List Symbol and isvar?: Symbol -> Boolean. (I think the latter is not
strictly necessary: it should return true if the Symbol could be a variable in
the domain) Then coercions could be done as I suggested: 

if any?(isvar?, vars(thing)) 

then thing cannnot be regarded as a coefficient.

I do admit that to integrate SUP into this picture might be tricky.
  
 > I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now
 > stands.** Unfortunately, the general and categoric constructs in Axiom make
 > it difficult to "exclude" specific domains (POLY(R) is valid for any ring R;
 > the user is allowed to construct POLY(R) for whatever R, even if R is
 > POLY(S). In fact, I don't know of any Axiom mechanism to exclude specific
 > domains in a constructor's parameters. (Axiom allows declaring domains to
 > HAVE certain attributes, but I believe does not allow them to NOT HAVE
 > certain attributes).

As it now stands, the way to do things is simple: don't use towers of domains
with variables. (One exeption is polynomials with coefficients that are
expressions not containing variables: we have to use POLY EXPR INT here...)

 > Below, I'll try to analyse where the present problem lies and propose a way
 > to correct the problem. Even if you agree with my analysis, whether the
 > correction should be implemented or not is still subject to discussion.

Do I understand correctly: You propose (roughly) that variables should carry a
tag that tells which domain they belong to.
  
 > Let me say that there is pehaps a role for constructs like POLY POLY INT or
 > POLY EXPR INT.  Examples: computing syzygies of polynomials generating an
 > ideal, or more generally the defining set of algebraic polynomial
 > (equations) for algebraic functions -- a (non-linear) system of differential
 > equations is simply algebraic equations for functions and their
 > derivatives. 

Could you give an example here? I do not understand.
  
 > Unfortunately, the current convention is not "outer domain takes all the
 > variables."

Hmmm? I didn't say that it was. By the way, "the outer domain takes all the
variables" is an inprecise summary. That's why I added "it can" from time to
time...

For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a
variable of the outer domain, y a coefficient. No confusion can arise.

Maybe it would be better to say "a variable that can be taken by an outer
domain, cannot appear as a coefficient". To explain that (1/x)::POLY(EXPR INT)
should yield an error, note that the variable is x, not (1/x).

 > )clear all
 > a:=monomial(1,1)$UP(x, INT)
 >   x
 > 
 > a::SUP INT
 >   ?

Note that this does not work in the compiler. You have to use makeSUP
expressively. And in fact, I think it shouldn't work in the interpreter either.
 
 > a::SUP UP(x,INT)
 >   x
  
 > Even though a tower of polynomial rings is involved in the above, these are
 > legitimate mathematical constructs (and correctly done) -- the unspecified
 > variable is intended to be transcendental over ANY coefficient domain, and
 > is often used to work with minimal polynomial of an element algebraic over
 > the coefficient domain. Here it shows that in coercing a variable into
 > SUP(R), the interpreter first try to coerce it into R, and failing that, to
 > to unspecified variable. So in this case, SUP only takes a variable when
 > necessary.

As an aside: towering SUP's is also an interesting issue. Consider

makeSUP(y::UP(y,SUP INT)*x::UP(x,INT)) giving 
   (20)  ? ?
          Type: SparseUnivariatePolynomial SparseUnivariatePolynomial Integer

Well, you know that.
     
 > > I would like to have a mapping from maths to axiom as clear as possible.
 > > And given the convention that the "outermost" domain "takes" all the
 > > variables (it can), EXPR POLY INT and EXPR INT would be the same
 > > mathematically, since any polynomial is an EXPR. Of course, the
 > > representations could be different in the two domains.
  
 > See above discussion on indexed method constructing polynomial rings.

I agree that your proposal (if I understood it) is also clean.

 > > Thus I think the direction to go is to put these checks into the compiler.
  
 > I don't know enough about compilers: Can a compiler single out (12) to
 > disallow it? For now, just don't use the same symbol for two different
 > things, and perhaps fix the error message with a warning instead.

I meant to say: "put these checks into the algebra." This is clearly possible.

\start
Date: Wed, 29 Sep 2004 07:37:56 -0400
From: Bill Page
To: Martin Rubey,	'Bob McElrath' <bob+debian@mcelrath.org>
Subject: literate programming pamphlet files for MathAction
Cc: "Bill Page \(E-mail\)" <Bill Page>

Martin (and others);

I have started to document the work I am doing to implement
full Axiom pamphlet file support on MathAction. I hope to
have an test version of this extension available before the
weekend.

There are few more notes and some examples here:

  http://test.axiom-developer.org/wiki/ConversionToHTML

My approach is to use Norman Ramsey's Latex to HTML (l2h)
noweave filter. This filter together with noweave, is able
to produce HTML files directly from noweb (pamphlet) files.
l2h is written in Icon - so over the last couple of days
I had to learn yet another language. Icon is quite a tidy
fast and apparently well suited language for this sort of
complex conversion. I have modified and extended l2h  so that
inline and display math environments as well as the axiom,
aldor and reduce pseudo-environments are passed straight
through the conversion. Now that I understand Icon and
thanks to Norman's literate programming style, I have also
added some missing things needed my first set of test files.

The output of the modified l2h can then be given directly
to LatexWiki (or MathAction) as an HTML+LaTeX file. When
it is fully integrated into MathAction, the pamphlet file
itself will be stored and converted transparently using
noweave with the modified l2h filter when clicking Save.

Please let me know if you have any questions or suggestions.
It will help motivate me to complete this work... :)

\start
Date: Wed, 29 Sep 2004 13:59:44 +0000
From: Martin Rubey
To: Bill Page
Subject: Re: literate programming pamphlet files for MathAction
Cc: 'Bob McElrath' <bob+debian@mcelrath.org>

Dear Bill,

great.

Since you asked for suggestions, I have one (but it is low priority): It would
be even better if the entries in the table of contents were active links...

Martin

Page, Bill writes:
 > Martin (and others);
 > 
 > I have started to document the work I am doing to implement
 > full Axiom pamphlet file support on MathAction. I hope to
 > have an test version of this extension available before the
 > weekend.
 > 
 > There are few more notes and some examples here:
 > 
 >   http://test.axiom-developer.org/wiki/ConversionToHTML
 > 
 > My approach is to use Norman Ramsey's Latex to HTML (l2h)
 > noweave filter. This filter together with noweave, is able
 > to produce HTML files directly from noweb (pamphlet) files.
 > l2h is written in Icon - so over the last couple of days
 > I had to learn yet another language. Icon is quite a tidy
 > fast and apparently well suited language for this sort of
 > complex conversion. I have modified and extended l2h  so that
 > inline and display math environments as well as the axiom,
 > aldor and reduce pseudo-environments are passed straight
 > through the conversion. Now that I understand Icon and
 > thanks to Norman's literate programming style, I have also
 > added some missing things needed my first set of test files.
 > 
 > The output of the modified l2h can then be given directly
 > to LatexWiki (or MathAction) as an HTML+LaTeX file. When
 > it is fully integrated into MathAction, the pamphlet file
 > itself will be stored and converted transparently using
 > noweave with the modified l2h filter when clicking Save.
 > 
 > Please let me know if you have any questions or suggestions.
 > It will help motivate me to complete this work... :)

\start
Date: Wed, 29 Sep 2004 13:22:43 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Martin Rubey wrote:
 
>  > Axiom cannot possibly rule out such user behavior because each operation
>  > (x::UP(x,?), x::EXPR INT, and /) is correctly performed. To do so would
>  > require Axiom to "look ahead" when processing x::UP(x,?). This is
>  > unreasonable as well as impossible -- how far ahead? what if the x::EXPR INT
>  > is something returned by another routine?
> 
> I don't understand: it can! Well, I mean: it could. One possibility is the
> following: every domain that has (named) variables should have a function vars:
> R -> List Symbol and isvar?: Symbol -> Boolean. (I think the latter is not
> strictly necessary: it should return true if the Symbol could be a variable in
> the domain) Then coercions could be done as I suggested:
> 
> if any?(isvar?, vars(thing))
> 
> then thing cannnot be regarded as a coefficient.

But the two functions vars and isvar? are kind of available, perhaps not named
that way, but surely there are functions similar that serve the same purpose, if
all you want is to test whether a domain has "variables." For example, monomial,
degree, freeOf? You may have to do a more complicated test, but you can test
these right now. But I still do not see how the above test can rule out a
construction like EXPR EXPR INT. It's a catch-22 situation. I don't see any
action can be taken at compile time of the EXPR constructor other than put in
the code for the if-statement to run at instantiation (run) time. If EXPR EXPR
INT is encountered by the compiler, an outer version of the if-statment will be
compiled.  So say your test returns false, assuming this test is executed at run
time when EXPR EXPR INT is instantiated, what is the then-clause? Can you first
instantiate the domain and then uninstantiate it? I think a simple error message
after this outer if-statement fails at instantiation time is not sufficient to
undo the instantiation; halting on error is not as good as catching this
construction at compile time. This would mean putting the rules for construction
into the grammar for the parser -- but the grammar does not know anything about
EXPR (or any specific constructor for that matter)!

> 
> I do admit that to integrate SUP into this picture might be tricky.
> 
It sure would be. Even for the others, you have to make sure preventing
"illegal" towers will not break any code. "There is no such thing as a simple
job."

>  > I see no reason to allow POLY EXPR INT or similar constructs **as Axiom now
>  > stands.** Unfortunately, the general and categoric constructs in Axiom make
>  > it difficult to "exclude" specific domains (POLY(R) is valid for any ring R;
>  > the user is allowed to construct POLY(R) for whatever R, even if R is
>  > POLY(S). In fact, I don't know of any Axiom mechanism to exclude specific
>  > domains in a constructor's parameters. (Axiom allows declaring domains to
>  > HAVE certain attributes, but I believe does not allow them to NOT HAVE
>  > certain attributes).
> 
> As it now stands, the way to do things is simple: don't use towers of domains
> with variables. (One exeption is polynomials with coefficients that are
> expressions not containing variables: we have to use POLY EXPR INT here...)

That's a good example we have to be careful if we prohibit certain towers. But
that is not the only example.

>  > Below, I'll try to analyse where the present problem lies and propose a way
>  > to correct the problem. Even if you agree with my analysis, whether the
>  > correction should be implemented or not is still subject to discussion.
> 
> Do I understand correctly: You propose (roughly) that variables should carry a
> tag that tells which domain they belong to. 

Yes. However, the tag is tied to the coefficient domain (which may have old
variables of its own), not the domain with (the new) variables. This corresponds
better to the mathematical notion of the "variables" ("algebraic indeterminates"
is the precise term) being algebraically independent over the coefficient
domain.
 
>  > Let me say that there is perhaps a role for constructs like POLY POLY INT or
>  > POLY EXPR INT.  Examples: computing syzygies of polynomials generating an
>  > ideal, or more generally the defining set of algebraic polynomial
>  > (equations) for algebraic functions -- a (non-linear) system of differential
>  > equations is simply algebraic equations for functions and their
>  > derivatives.
> 
> Could you give an example here? I do not understand.

Let's say I am hunting for two polynomials f(x), g(x) and I know they satisfy
some algebraic relations with coefficents that are polynomials. The polynomials
expressing these algebraic relations would then be in POLY POLY INT, such as 

h = a(x) y^3 + b(x) z^2 - c(x) 

where a, b, c are in POLY INT, and y, z when substituted by f, g would give
zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of
course, we know it would be better to use specified variables and work in
DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN
carry out these computations in POLY INT alone, but the more natural setting is
POLY POLY INT (for example, we may want to compute the grobner basis of the h's
in POLY POLY INT with POLY INT as coefficient domain. Relations like  h(f,g) = 0
are called a syzygies of (f,g) and are important computational objects in
algebraic geometry. If g(x) = df/dx, then h(f,g)=0 is a differential equation on
f(x).

> 
>  > Unfortunately, the current convention is not "outer domain takes all the
>  > variables."
> 
> Hmmm? I didn't say that it was. By the way, "the outer domain takes all the
> variables" is an inprecise summary. That's why I added "it can" from time to
> time...

Sorry, I misquoted.

> For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a
> variable of the outer domain, y a coefficient. No confusion can arise.

Yes, but you would disallow the prior use of x in POLY INT, which is where we
started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a
new indeterminate x over POLY INT. Tagging would distinguish this x from any
possible prior use of x.

> Maybe it would be better to say "a variable that can be taken by an outer
> domain, cannot appear as a coefficient". To explain that (1/x)::POLY(EXPR INT)
> should yield an error, note that the variable is x, not (1/x).
> 
>  > )clear all
>  > a:=monomial(1,1)$UP(x, INT)
>  >   x
>  >
>  > a::SUP INT
>  >   ?
> 
> Note that this does not work in the compiler. You have to use makeSUP
> expressively. And in fact, I think it shouldn't work in the interpreter either.

I don't know the mechanics of how the interpreter handles ::. We have seen it
uses at least more than one way (that is, it may use coerce, convert, and here,
makeSUP). I often don't know what map is used since ")set mess bot on" does not
always give output on "simple" things like this. However, we all know that the
compiler needs precise information, so if the interpreter is smart enough to use
makeSUP when :: is used, what's wrong with that?
 
>  > a::SUP UP(x,INT)
>  >   x
> 
>  > Even though a tower of polynomial rings is involved in the above, these are
>  > legitimate mathematical constructs (and correctly done) -- the unspecified
>  > variable is intended to be transcendental over ANY coefficient domain, and
>  > is often used to work with minimal polynomial of an element algebraic over
>  > the coefficient domain. Here it shows that in coercing a variable into
>  > SUP(R), the interpreter first try to coerce it into R, and failing that, to
>  > to unspecified variable. So in this case, SUP only takes a variable when
>  > necessary.
> 
> As an aside: towering SUP's is also an interesting issue. Consider
> 
> makeSUP(y::UP(y,SUP INT)*x::UP(x,INT)) giving
>    (20)  ? ?
>           Type: SparseUnivariatePolynomial SparseUnivariatePolynomial Integer
> 
> Well, you know that.

If we tag the variables, there will be no need for SUP using unspecified
variables and printing out ? all the time and the above I/O problem will go
away.

>  > > I would like to have a mapping from maths to axiom as clear as possible.
>  > > And given the convention that the "outermost" domain "takes" all the
>  > > variables (it can), EXPR POLY INT and EXPR INT would be the same
>  > > mathematically, since any polynomial is an EXPR. Of course, the
>  > > representations could be different in the two domains.
> 
>  > See above discussion on indexed method constructing polynomial rings.
> 
> I agree that your proposal (if I understood it) is also clean.

Thanks. I probably wrote too much!
 
>  > > Thus I think the direction to go is to put these checks into the compiler.
> 
>  > I don't know enough about compilers: Can a compiler single out (12) to
>  > disallow it? For now, just don't use the same symbol for two different
>  > things, and perhaps fix the error message with a warning instead.
> 
> I meant to say: "put these checks into the algebra." This is clearly possible.

Not clear to me at all! Perhaps I am missing the obvious. I believe it is going
to be a mess even if it is possible. It would be difficult to specify precisely
what towers are allowed or not. I think we should allow all towers and variables
should not be mixed (in any solution) and it is easier to do so with tags than
with tests. Tests are inefficient because it is a run-time penalty; while tags,
except at compile time, do not exert a penalty at all -- the symbol hash table
is the same, just the identifiers are longer.
Date: Wed, 29 Sep 2004 12:10:18 -0700
From: Bob McElrath
To: Bill Page
Cc: zwiki@zwiki.org
Subject: Re: literate programming pamphlet files for MathAction

Page, Bill [Bill Page] wrote:
> Martin (and others);
> 
> I have started to document the work I am doing to implement
> full Axiom pamphlet file support on MathAction. I hope to
> have an test version of this extension available before the
> weekend.
> 
> There are few more notes and some examples here:
> 
>   http://test.axiom-developer.org/wiki/ConversionToHTML
> 
> My approach is to use Norman Ramsey's Latex to HTML (l2h)
> noweave filter. This filter together with noweave, is able
> to produce HTML files directly from noweb (pamphlet) files.
> l2h is written in Icon - so over the last couple of days
> I had to learn yet another language. Icon is quite a tidy
> fast and apparently well suited language for this sort of
> complex conversion. I have modified and extended l2h  so that
> inline and display math environments as well as the axiom,
> aldor and reduce pseudo-environments are passed straight
> through the conversion. Now that I understand Icon and
> thanks to Norman's literate programming style, I have also
> added some missing things needed my first set of test files.

Let me suggest that you do this as a ZWiki "pagetype".  (see pagetypes/
in the ZWiki source)  The relevant code for latexwiki is in the
__init__.py file.

Each pagetype should define an input type and an output type.  (and the
output type should almost always be html)

> The output of the modified l2h can then be given directly
> to LatexWiki (or MathAction) as an HTML+LaTeX file. When
> it is fully integrated into MathAction, the pamphlet file
> itself will be stored and converted transparently using
> noweave with the modified l2h filter when clicking Save.
> 
> Please let me know if you have any questions or suggestions.
> It will help motivate me to complete this work... :)

Let me tell you what I have been doing, since it is very similar...

ZWiki needs a huge rewrite of its page-rendering code.  Right now it is
a big pile of regexes and because of this, one can find cases where it
will mangle pages.  This is especially relevant for latex.  I have
started this, and right now have a standalone code which does it
"properly".  This is a subclass of StructuredText and uses that
machinery to render pages.

Why this is relevant to you:

When this is done I will start adding new page types.  For me the first
will be "true" latex.  But since this is all done within the
StructuredText system, new pagetypes (such as "spad") can *inherit* the
needed latex functionality from latexwiki.  Thus we can combine our work
into new page types in ways that cannot mangle the document.

The StructuredText classes are very simple.  Basically for each text
"object" (like $math$) you have to write one function to recognize it
and one function to render it.  In addition there is a list of which
"recognizers" have more importance than others, so you know what to do
with things like [foo $bar$] vs. $foo [bar]$ or -- which takes
properly with successive regexes that operate on the whole document.
That it works at all right now is a rather large hack involving
successive conversions to html, and ignoring html...

This is not as good as a formally defined document grammar, but is
probably the best we can get with what we are doing.

Join me on #zwiki at irc.freenode.net if you'd like to discuss this
further.  I think we should discuss the "big scheme" before we head in
different directions and end up with a pile of incompatible software.

I have placed my preliminary StructuredText classes here::

    http://bob.mcelrath.org/WikiStructuredText

along with a standalone example program showing how to use it.  I hope
this should make it obvious how to extend.

This will result in a more extensible, understandable, and robust
codebase.  Not to mention faster.

P.S. do I understand that MathAction is your website, and not a piece of
software?

\start
Date: Thu, 30 Sep 2004 09:36:27 +0000
From: Martin Rubey
To: Bob McElrath
Subject: Re: literate programming pamphlet files for	MathAction
Cc: zwiki@zwiki.org, "Bill Page \(E-mail\)" <Bill Page>

Yet another suggestion:

In Axiom (and Aldor) code, there are two types of comments: -- and ++.

The first tells the compiler to throw the comment away, the latter to keep
it. It seems that there are programs that can use these "descriptions", I
suppose Hyperdoc is one. More precisely: +++ tells the compiler that the
comment concerns the next name, ++ concerns the preceding name.

I thus suggest a tiny bit of syntax highlighting: It would be great if the
++(+) comments would be printed a *little* differnent than the rest of the
code, maybe in italic or a different color. (Since the often contain code, they
need to be printed in the same font as code.)

The -- comments often contain old code, so maybe a "lighter" face would be
appropriate. Those -- comments that explain the code will vanish and merge into
the pamphlet style documentation, I suspect.


\start
Date: Thu, 30 Sep 2004 10:24:32 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Hi Martin,

It is not exactly clear what you want, but if it is just for the purpose 
of editing .pamphlet files, there is already some support for Aldor code 
edited in Emacs. See aldor.org or http://www.hemmecke.de/aldor.

However, I don't like the #pile mode of Aldor/Axiom very much. This 
might cause some problems with syntax highlighting.

My mode even seems to work in connection with the Emacs noweb-mode, so 
it should even highlight code within pamphlet files. You should put 
something like this

%EMACS Local Variables:
%EMACS mode: noweb
%EMACS noweb-code-mode: aldor-mode
%EMACS End:

At the end of each pamphlet file or use other methods to convince Emacs 
to load the right mode if it displays a .pamphlet file.


Jinlong Cai <jcai3@uwo.ca> wrote another aldor-mode which is certainly 
more advanced than mine, since it incorporates support for the Aldor 
debugger. However, I haven't seen his mode openly available.



There are some attempts to extract the ++ and +++ documentation from 
Aldor .asy files and transform them finally to html. This goes under the 
name AldorDoc, but is not very much advance yet. Unfortunately, Yannis 
Chicha has no time to make progress with AldorDoc.

But appart from syntax highlighting there is another question which is 
still to be discussed. "What kind of structure should ++ comments have?"
Note that if these documentation comments are processed automatically, 
there should be some tags so that the documentation compiler knows where 
to link some names to or how to typeset certain pieces of the 
documentation. Personally, I would very much like to get the 
functionality of JavaDoc, but unfortunately ++ comments might become 
unreadable in the .pamphlet file (which is undesirable).
But here people of Axiom and Aldor should work together so that they 
come up with ONE nice suggestion and program that produces a online 
version of the category hierarchy similar to JavaDoc or AlDoc (see
http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html)

Aldoc (http://www-sop.inria.fr/safir/WHOSWHO/Manuel.Bronstein/) (in 
contrast to AldorDoc) unfortunately does NOT use the ++ comments but 
uses LaTeX code embedded in the .as files.


Ralf

Martin Rubey wrote:
> Yet another suggestion:
> 
> In Axiom (and Aldor) code, there are two types of comments: -- and ++.
> 
> The first tells the compiler to throw the comment away, the latter to keep
> it. It seems that there are programs that can use these "descriptions", I
> suppose Hyperdoc is one. More precisely: +++ tells the compiler that the
> comment concerns the next name, ++ concerns the preceding name.
> 
> I thus suggest a tiny bit of syntax highlighting: It would be great if the
> ++(+) comments would be printed a *little* differnent than the rest of the
> code, maybe in italic or a different color. (Since the often contain code, they
> need to be printed in the same font as code.)
> 
> The -- comments often contain old code, so maybe a "lighter" face would be
> appropriate. Those -- comments that explain the code will vanish and merge into
> the pamphlet style documentation, I suspect.

\start
Date: Thu, 30 Sep 2004 10:51:23 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Hi Ralf,

my suggestion concerns only the (future) presentation of pamphlet files on the
mathaction wiki.

On the other hand, great that you are pointing out an aldor mode for emacs. If
this mode really supports pamphlet files, this would be pretty.

Ralf HEMMECKE writes:

 > There are some attempts to extract the ++ and +++ documentation from 
 > Aldor .asy files and transform them finally to html. This goes under the 
 > name AldorDoc, but is not very much advance yet. Unfortunately, Yannis 
 > Chicha has no time to make progress with AldorDoc.

In an ideal world, the documentation of Aldor and Axiom will be done with the
same tool. It seems to me, that the pamphlet + mathaction wiki approach is
quite sophisticated.

Unfortunately it seems that quite some work has been done more than once. It
seems that aldoc and the pamphlet approach are quite similar. Maybe we could at
least reuse the aldoc latex class for Axiom...

 > "What kind of structure should ++ comments have?"  Note that if these
 > documentation comments are processed automatically, there should be some
 > tags so that the documentation compiler knows where to link some names to or
 > how to typeset certain pieces of the documentation. 

Yes.

 > Personally, I would very much like to get the functionality of JavaDoc, but
 > unfortunately ++ comments might become unreadable in the .pamphlet file
 > (which is undesirable).

why do you think that they might become unreadable?

 > But here people of Axiom and Aldor should work together so that they 
 > come up with ONE nice suggestion and program that produces a online 
 > version of the category hierarchy 

Yes.

\start
Date: Thu, 30 Sep 2004 11:27:02 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Dear Martin,

>  > Personally, I would very much like to get the functionality of JavaDoc, but
>  > unfortunately ++ comments might become unreadable in the .pamphlet file
>  > (which is undesirable).
> 
> why do you think that they might become unreadable?

In ++ comments one might wish to include some mathematical formulae. 
Writing them in MathML makes the ++ comments unreadable. Many 
mathematicians can read LaTeX these days, so I would prefer LaTeX here.
However, even the LaTeX style will not be there forever.

I would agree on some XML like style, but this should come with an 
editor that hides the tags and presents the things inside nicely. (I 
know it is not well thought of.)

Personally, I became familiar with noweb only recently, and it works 
great. The \usepackage{srcltx} facility together with some newer dvi 
viewers like kdvi or xdvi, let you 'inverse search' in the dvi file. 
When you click at some place in the .dvi file, your editor opens and 
points directly to the place in the .tex file. I have a modified version 
of srcltx that jumps to the place in the corresponding .nw file instead 
of the generated .tex file. I have simply replaced

\def\src@@include#1#2{%
     \src@before@file@hook{#2.tex}%
     \src@include{#2}%
     \src@after@file@hook{#1}%
}

in srcltx 2004/05/15 v1.4

by

\def\src@@include#1#2{%
     \src@before@file@hook{#2}%--rhx: removed '.tex' extension
     \src@include{#2}%
     \src@after@file@hook{#1}%
}

In connection to the extension rule of just adding .tex to the noweb file

    noweave FILE.nw > FILE.nw.tex

this works quite nicely for me.

But maybe this inverse-search facility is not necessary if pamphlet 
files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no 
experiences with the latter.)

But still, the ++ code would remain untouched (and unformated) even in 
the .dvi file (and thus maybe unreadable). So I have not quite made up 
my mind of how to document in a structured way by using the ++ comments.

\start
Date: Thu, 30 Sep 2004 11:38:24 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Ralf HEMMECKE writes:
 > Dear Martin,
 > 
 > >  > Personally, I would very much like to get the functionality of JavaDoc, but
 > >  > unfortunately ++ comments might become unreadable in the .pamphlet file
 > >  > (which is undesirable).
 > > 
 > > why do you think that they might become unreadable?
 > 
 > In ++ comments one might wish to include some mathematical formulae. 
 > Writing them in MathML makes the ++ comments unreadable. Many 
 > mathematicians can read LaTeX these days, so I would prefer LaTeX here.

Why on earth would you write them in MathML?

 > However, even the LaTeX style will not be there forever.

I doubt this. Well, for "forever" < 30 years, I'm pretty sure that LaTeX will
stay with us.


 > I would agree on some XML like style

I will not.

 > I have a modified version 
 > of srcltx that jumps to the place in the corresponding .nw file instead 
 > of the generated .tex file. I have simply replaced
 > 
 > \def\src@@include#1#2{%
 >      \src@before@file@hook{#2.tex}%
 >      \src@include{#2}%
 >      \src@after@file@hook{#1}%
 > }
 > 
 > in srcltx 2004/05/15 v1.4
 > 
 > by
 > 
 > \def\src@@include#1#2{%
 >      \src@before@file@hook{#2}%--rhx: removed '.tex' extension
 >      \src@include{#2}%
 >      \src@after@file@hook{#1}%
 > }
 

very nice.
 
 > In connection to the extension rule of just adding .tex to the noweb file
 > 
 >     noweave FILE.nw > FILE.nw.tex
 > 
 > this works quite nicely for me.
 > 
 > But maybe this inverse-search facility is not necessary if pamphlet 
 > files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no 
 > experiences with the latter.)

I suspect that small changes (like typos) will be done via MathAction
directly. Bigger changes will be done locally, and I will certainly use your
srcltx modification! Thanks!

 > But still, the ++ code would remain untouched (and unformated) even in the
 > .dvi file (and thus maybe unreadable).

I don't understand this. For postprocessing and editing, use
example.spad.pamphlet, for printing the example.spad.dvi, for browsing the
.pamphlet.spad.html output, for computing the example.spad format. All of them
will include the code of the spad (or aldor) file -- always human
readable. Except example.spad.pamphlet, all files are read only.

\start
Date: Thu, 30 Sep 2004 12:06:39 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Hi Martin,

>  > In ++ comments one might wish to include some mathematical formulae. 
>  > Writing them in MathML makes the ++ comments unreadable. Many 
>  > mathematicians can read LaTeX these days, so I would prefer LaTeX here.
> 
> Why on earth would you write them in MathML?

What would you suggest?

I am very much open to everything, even LaTeX, but there should be some 
standard of how to document with ++ and this is missing currently!

Would there be somebody else interested in this topic? Or would such a 
discussion be too early?

>  > I would agree on some XML like style
> 
> I will not.

That was not a proposal. I just need some standard. And I was only 
thinking of XML since there are more and more tools that can handle this.

>  > But still, the ++ code would remain untouched (and unformated) even in the
>  > .dvi file (and thus maybe unreadable).

> I don't understand this. For postprocessing and editing, use
> example.spad.pamphlet, for printing the example.spad.dvi, for browsing the
> .pamphlet.spad.html output, for computing the example.spad format. All of them
> will include the code of the spad (or aldor) file -- always human
> readable. Except example.spad.pamphlet, all files are read only.

All ASCII files are human readable, but that is not the point. One can 
certainly catch the information in $a_1^2$ quite quickly, but written in 
MATHML this would take some while (at least for some unexperienced 
person). This is what I mean by unreadable and why with an XML-like tag 
form, there would be a need of an intelligent editor.

\start
Date: Thu, 30 Sep 2004 12:22:00 +0000
From: Martin Rubey
To: William Sit
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Dear William,

your point of view becomes clearer and clearer to me. I am nearly convinced :-)
In the following I'm only going to correct some apparent misunderstandings.

William Sit writes:
 > 
 > 
 > Martin Rubey wrote:

 > > every domain that has (named) variables should have a function vars: R ->
 > > List Symbol and isvar?: Symbol -> Boolean.
 > > 
 > > if any?(isvar?, vars(thing))
 > > 
 > > then thing cannnot be regarded as a coefficient.
 > 
 > But the two functions vars and isvar? are kind of available, perhaps not named
 > that way, but surely there are functions similar that serve the same purpose, if
 > all you want is to test whether a domain has "variables." 

The important thing would be that all these functions would have the same name
and modeline. Otherwise I cannot test for them. The closest match is the
function variables.

 > But I still do not see how the above test can rule out a construction like
 > EXPR EXPR INT.

It wouldn't. In fact, EXPR EXPR INT would not be forbidden, only, the
coefficient domain would not be allowed to contain any variables.

In fact, for EXPR EXPR INT, to clarify, lets denote this by EXPR COEFF, the
statement

if any?(isvar?, vars(thing))

should always return false, i.e., the situation that Axiom tries to coerce
something that contains a variable to COEFF should never happen. If it does, I
misunderstood the coercion process.

Thus, I do not propose to prevent the instantiation of domains. I only propose
to throw errors when Axiom is forced to do coercions that are not good.

 > > I do admit that to integrate SUP into this picture might be tricky.
 > > 
 > It sure would be. Even for the others, you have to make sure preventing
 > "illegal" towers will not break any code.

I suspect you misunderstood me: my proposal does not make any towers
"illegal". Hence, it would not break any (well written) code.

 > > As it now stands, the way to do things is simple: don't use towers of
 > > domains with variables. (One exeption is polynomials with coefficients
 > > that are expressions not containing variables: we have to use POLY EXPR
 > > INT here...)
 > 
 > That's a good example we have to be careful if we prohibit certain
 > towers. But that is not the only example.

Again: following my proposal, POLY EXPR INT would not be prohibited. Quite the
contrary!

 > > Do I understand correctly: You propose (roughly) that variables should
 > > carry a tag that tells which domain they belong to.
 > 
 > Yes. However, the tag is tied to the coefficient domain (which may have old
 > variables of its own), not the domain with (the new) variables. This
 > corresponds better to the mathematical notion of the "variables" ("algebraic
 > indeterminates" is the precise term) being algebraically independent over
 > the coefficient domain.

Good. If you rite up your proposal, maybe you could elaborate a bit on the
precise tagging. See below.

 > Let's say I am hunting for two polynomials f(x), g(x) and I know they
 > satisfy some algebraic relations with coefficents that are polynomials. The
 > polynomials expressing these algebraic relations would then be in POLY POLY
 > INT, such as
 > 
 > h = a(x) y^3 + b(x) z^2 - c(x) 
 > 
 > where a, b, c are in POLY INT, and y, z when substituted by f, g would give
 > zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of
 > course, we know it would be better to use specified variables and work in
 > DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN
 > carry out these computations in POLY INT alone, but the more natural setting
 > is POLY POLY INT

This is a nice example. I'd like to use it to raise an issue with your
proposal: suppose you have somehow generated h in POLY COEFF (where COEFF =
POLY INT, just to make it easier to talk about), such that y and z are
variables in POLY COEFF and a(x), b(x) and c(x) are coefficients, i.e., in
COEFF.

The question is, how to multiply to such POLY COEFF's ?

Suppose you ask for h*x. How would you instruct Axiom to understand the
multiplier x as an element of COEFF, and how would you instruct Axiom to
understand x as a variable in h?

)set mess scope on

h::(POLY POLY INT)*x::(POLY INT)

-> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...

versus

h::(POLY POLY INT)*x::(POLY POLY INT)

-> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...

correct?

Following my approach, you couldn't be *that* lazy. You'd have to say

h::DMP([y,z], POLY INT).

I realize right now, that I didn't consider POLY UP(x, INT) yet... As my
proposal is formulated right now, the coefficient domain would not contain any
variables. That's might not be that good, since POLY FRAC UP(x, INT) might be
an interesting domain.

 > > For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a
 > > variable of the outer domain, y a coefficient. No confusion can arise.
 > 
 > Yes, but you would disallow the prior use of x in POLY INT, which is where we
 > started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a
 > new indeterminate x over POLY INT. 

I wouldn't, but I see your point.

 > I don't know the mechanics of how the interpreter handles ::. We have seen
 > it uses at least more than one way (that is, it may use coerce, convert, and
 > here, makeSUP). I often don't know what map is used since ")set mess bot on"
 > does not always give output on "simple" things like this. 

It would be really nice to have )set me bo on give output here too! I suspect
that the problem is that not all of the code is in the algebra, where I think
it should be.
 
 > > I agree that your proposal (if I understood it) is also clean.
 > 
 > Thanks. I probably wrote too much!

No. It is difficult to guess what I know or understand, and what needs
explaining. You did explain many things I knew, you did explain many things I
did not know...

 > > I meant to say: "put these checks into the algebra." This is clearly possible.
 > 
 > Not clear to me at all! Perhaps I am missing the obvious. I believe it is
 > going to be a mess even if it is possible. It would be difficult to specify
 > precisely what towers are allowed or not. 

Yes.

 > I think we should allow all towers and variables should not be mixed (in any
 > solution) and it is easier to do so with tags than with tests.

Yes. However, we have to agree on one philosophy, I'm afraid. Would you be able
to write down as cleanly as possible the two proposals and add them add them at
the bottom of 

http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong

?

(Write a text file, click edit on the top right, paste, click save)

 > Tests are inefficient because it is a run-time penalty; 

True.

 > while tags, except at compile time, do not exert a penalty at all -- the
 > symbol hash table is the same, just the identifiers are longer.

True.

\start
Date: Thu, 30 Sep 2004 12:31:36 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

Ralf HEMMECKE writes:
 > Hi Martin,
 > 
 > >  > In ++ comments one might wish to include some mathematical formulae. 
 > >  > Writing them in MathML makes the ++ comments unreadable. Many 
 > >  > mathematicians can read LaTeX these days, so I would prefer LaTeX here.
 > > 
 > > Why on earth would you write them in MathML?
 > 
 > What would you suggest?

LaTeX. In the spad files, this is the way it is currently done: There are two
commands, \spad and \axiom, whose meaning I do not really now. Apart of this,
some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX
as possible.

 > I am very much open to everything, even LaTeX, but there should be some
 > standard of how to document with ++ and this is missing currently!
 > 
 > Would there be somebody else interested in this topic? Or would such a
 > discussion be too early?

I'd like to concentrate on making the two languages become one (i.e. Aldor)
first.

 > All ASCII files are human readable, but that is not the point. One can 
 > certainly catch the information in $a_1^2$ quite quickly, but written in 
 > MATHML this would take some while (at least for some unexperienced 
 > person). This is what I mean by unreadable and why with an XML-like tag 
 > form, there would be a need of an intelligent editor.

Hence, don't use it.

\start
Date: Thu, 30 Sep 2004 07:40:49 -0400
From: Tim Daly
To: Martin Rubey, Bill Page
Subject: re: literate programming pamphlet files for MathAction
Cc: chicha@essi.fr, jcai3@uwo.ca, Ralf Hemmecke

Martin writes:

>  > In connection to the extension rule of just adding .tex to the noweb file
>  > 
>  >     noweave FILE.nw > FILE.nw.tex
>  > 
>  > this works quite nicely for me.
>  > 
>  > But maybe this inverse-search facility is not necessary if pamphlet 
>  > files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no 
>  > experiences with the latter.)
> 
> I suspect that small changes (like typos) will be done via MathAction
> directly. Bigger changes will be done locally, and I will certainly use your
> srcltx modification! Thanks!

I hope that, in the longer term, the mathaction wiki page presents the
original pamphlet file when you click 'edit'. That would imply running
noweb in the background when you click 'save'. The hard part, of course,
is that the change might actually fail, in which case there will be a
noweb msg or latex log file. 

If we could do this then it would be possible (at least technically)
to maintain axiom directly from the wiki pages. Of course there are
a lot of little steps along the way. I'd like to see the ability to 
integrate CVS (or arch?) automatically into web page changes. 

Once mathaction can run stand-alone we plan to put it on a live-CD
and use it to 'front-end' a doyen system. Somewhere after that time
it would be interesting to be able to work on a page locally and then
"drag and drop" from your local browser tab (where you write/test) to
the mathaction tab on the host. At which point you could locally 
develop a pamphlet for a conference and publish it to the mathaction
website.

That said, I want to complement Bill on this excellent work. I spent
most of yesterday demonstrating the mathaction wiki to various 
people at my university. Everyone is impressed. His work really 
brings out the smiles as people begin to realize how potentially
useful this will be. In the long term this is going to define the
way computational science is done. Thanks, Bill.

\start
Date: Thu, 30 Sep 2004 13:00:49 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>

>  > >  > In ++ comments one might wish to include some mathematical formulae. 
>  > >  > Writing them in MathML makes the ++ comments unreadable. Many 
>  > >  > mathematicians can read LaTeX these days, so I would prefer LaTeX here.
>  > > 
>  > > Why on earth would you write them in MathML?
>  > 
>  > What would you suggest?
> 
> LaTeX. In the spad files, this is the way it is currently done: There are two
> commands, \spad and \axiom, whose meaning I do not really now. Apart of this,
> some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX
> as possible.

Well, is there some list of possible commands that are usable in ++ like 
\axiom and \spad etc. What is their meaning. My hope would be that a 
documentation compiler could even produce hyperlinks from certain tags. 
Is this possible in Axiom?

> I'd like to concentrate on making the two languages become one (i.e. Aldor)
> first.

As far as I know there are 3 languages, all slightly different.
A Aldor
S SPAD
I Axiom interpreter language

I could live with A \ne I, because the interpreter is there to make life 
easier for the lazy user. For serious programming, however, Axiom should 
use Aldor, not SPAD. I believe that SPAD and Aldor still differ in some 
places, unfortunately.

\start
Date: Thu, 30 Sep 2004 08:06:38 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction
Cc: chicha@essi.fr, jcai3@uwo.ca

> >  > In ++ comments one might wish to include some mathematical formulae. 
> >  > Writing them in MathML makes the ++ comments unreadable. Many 
> >  > mathematicians can read LaTeX these days, so I would prefer LaTeX here.
> > 
> > Why on earth would you write them in MathML?
> 
> What would you suggest?
> 
> I am very much open to everything, even LaTeX, but there should be some 
> standard of how to document with ++ and this is missing currently!

I'm interested in this thread (though buried under a huge project in work
at the moment). The ++ and -- comments were part of the original 
documentation mechanism. In the long term these will go away. The 
code generated for the compiler won't contain documentation (since the
compiler doesn't care). There will be new environments in the pamphlet
file which will be standardized and automatically extracted. Standard
environments include \begin{testcase} for integrating .input file tests,
\begin{concept} for tagging the introduction of a new concept that needs
to be pushed into a semantic network (see the crystal discussion in the
history), etc. These stylized environments will, like \begin{list}, 
probably have special sub-tags (like \testinput and \testresult so 
testcases can automatically verify the results).

++ and -- suffer from the usual problem of documentation. programmers
will not maintain documentation tags. mostly because almost nobody
but the programmer ever reads code. we tried to be clever about it
and make the comments "live" with hyperdoc (a pre-javadoc idea). 
unfortunately it still suffers from the fact that embedded comments
are not the primary reason for a .spad file. I'm hoping that the
pamphlet file (which makes the documentation task primary and coding
secondary) will encourage computational mathematicians to actually
write papers that include working code and programmers to write real
papers that explain their algorithms. 

\start
Date: Thu, 30 Sep 2004 15:56:43 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: literate programming pamphlet files for MathAction
Cc: chicha@essi.fr, jcai3@uwo.ca

>> I am very much open to everything, even LaTeX, but there should be 
>> some standard of how to document with ++ and this is missing 
>> currently!

> I'm interested in this thread (though buried under a huge project in 
> work at the moment). The ++ and -- comments were part of the original
>  documentation mechanism. In the long term these will go away.

Why should they go away? Is there a way in Axiom to produce a 
hyperlinked category hierarchy? Such a hierarchy should be generated 
from the actual CODE and not some latex documentation around. If then 
there is some helpful documentation like the ++ comments that describe 
the input/output parameters and approximately what the 
domain/category/function is doing, this would greatly help programmers.

I don't say that this should be the only documentation, but it should 
not go away, because programmers need the exact interface of functions 
in a compact way. Sometimes one knows what a function is doing, but not 
exactly in which order the parameters go and what there exact 
specification is. Putting this information away from the function code 
is dangerous.

Of course with noweb, one can do everything nicely, but the 
documentation is lost for the Aldor compiler then.

> The code generated for the compiler won't contain documentation 
> (since the compiler doesn't care).

This is NOT true for the Aldor compiler. Aldor compiles .as -> .ao -> .o
in a way so that the ++ comments are still extractable from the machine 
independent .ao files. Leaving the ++ information in, would leave the 
option of generating some type of documentation even from .al libraries 
(a collection of .ao file) where the source code is not available.

> There will be new environments in the pamphlet file which will be
> standardized and automatically extracted. Standard environments
> include \begin{testcase} for integrating .input file tests,
> \begin{concept} for tagging the introduction of a new concept that
> needs to be pushed into a semantic network (see the crystal
> discussion in the history), etc. These stylized environments will,
> like \begin{list}, probably have special sub-tags (like \testinput
> and \testresult so testcases can automatically verify the results).

Speaking of testcases, you should have a look at AUnit.

http://www.myjavaserver.com/~tmgisi/aldor-jsp/showPackage.jsp?id=1

Maybe this could be also useful for Axiom. Christian 
Christian Aistleitner took much effort to translate the JUnit 
idea from Java to Aldor. I think he did great work.

Christian, could you update your website with the newest version. On the 
above site it is still AUnit0.0.1.

> ++ and -- suffer from the usual problem of documentation. programmers
> will not maintain documentation tags. mostly because almost nobody 
> but the programmer ever reads code. we tried to be clever about it 
> and make the comments "live" with hyperdoc (a pre-javadoc idea). 
> unfortunately it still suffers from the fact that embedded comments 
> are not the primary reason for a .spad file. I'm hoping that the 
> pamphlet file (which makes the documentation task primary and coding
> secondary) will encourage computational mathematicians to actually 
> write papers that include working code and programmers to write real
> papers that explain their algorithms.

I agree to a certain extend, but not completely. The pamphlet idea is 
wonderful, but the paper-style text is quite unhandy as a reference 
manual. An additional documentation like, for example,

http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html

would be desirable. Or can this be done already with AXIOM?

\start
Date: Thu, 30 Sep 2004 08:26:55 -0700
From: Bob McElrath
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>


Ralf HEMMECKE [Ralf Hemmecke] wrote:
> But maybe this inverse-search facility is not necessary if pamphlet 
> files are edited via MathAction or LaTeXWiki. (Unfortunately, I have no 
> experiences with the latter.)

That is an interesting idea...I will have to try that in my latex
papers.

I discovered recently that one can use::

    <body tal:attributes="ondblclick
    python:'document.location=\''+here.page_url()+'/editform\'';" >

To get a double click anywhere in the page to open up the LatexWiki edit
form.  All that is required for what you suggest is to also position the
cursor.

\start
Date: Thu, 30 Sep 2004 10:25:44 -0400
From: Tim Daly
To: list
Subject: literate programming pamphlet files for MathAction

Ralf,

re: Why should ++ comments go away?

There were actually 3 distinguished levels: + ++ and +++, an idea
lifted from lisp's use of ; ;; and ;;; comments.  The idea was a
poor-man's way of doing \section, \subsection, and \subsubsection kind
of commenting with some cheesy syntax. Later we added keywords, special
tags (like \axiom) and function signature comments.

The problems are apparent and, as one of the original developers and 
the primary author of most of the bad signature comments, I can see
the flaws. I'll contrast them with the pamphlet mechanism.

First, ++ comments are a cheap imitation of tex. You can include certain
macros like \axiom in them and certain magic post processing occurs.
What this set of magic tags are, why they are there, and how they affect
the presentation later is not clearly documented. There is a limited set
and, unless you wrote the original mechanism (i.e. are me) it is very
hard to extend. 

Pamphlet files let you use the full power of tex, including hyperlinking
packages and, now noweb and a browser. Thus we gain 4 benefits. 
 (a) the world understands tex so no documentation of the tags is needed, 
 (b) the mechanism is entirely general so anyone can make their own tags, 
 (c) less code needs to be maintained, and 
 (d) it all works with general purpose tools (mathaction, browser, etc).

Second, ++ comments live in files intended to be fed to a compiler. As a 
programmer I develop my own style of coding and, unless the compiler
enforces some syntax, I will do things my own way. In fact, to try to
overcome this problem you'll notice that the compiler actually complains
if either the ++ comments are improperly indented or they are missing.
I wrote the code that enforces that because I know programmers. But,
frankly, it still fails because the mindset is still to "make it work".
Thus programmers discovered that ++ comments can be complete nonsense
and the compiler will shut up. So I added a check for certain tags.
Same result. We shouldn't feed the compiler anything it can't use.
(With some cleverness we COULD define a function that could allow a 
program to reference its own pamphlet at runtime. This might be useful)

Pamphlet files change the emphasis from programming to writing a document.
You not only have to satisfy the compiler you also have to satisfy noweb
and tex (and l2h, etc). Thus, the emphasis is on creating a document. For
a programmer this is awkward. But pamphlet files are intended for doing
computational science which is a very specialized area of programming.
Once I got my old code back after 15 years I realized that unless we 
keep the theory with the code there is no hope of maintaining, modifying,
and extending these heavy science systems. Pamphlet files are intended
to make sure we can.

Third, you comment that "the ++ comments would greatly help programmers"
The pamphlet files are intended to satisfy what appear to be
a couple audiences, some of which are programmers who don't know the
science and some of which are scientists who don't program. I believe
that we are on the cusp of a new group of people that I refer to as
computational scientists. They are cross trained in both programming and
their particular science. Maintaining special, outdated, weak, and painful
syntax "for the programmers" is not helpful.

Pamphlet files need some "canonical examples". I have permission to use
a couple phd thesis documents, technical papers that have algorithm
descriptions, proofs, complexity analysis, etc, sections of books and
other document sources. The idea is to "set the standard" for what we
can expect from a full, professionally documented, scientifically sound,
document with execution semantics. This will evolve over time as we add
new functionality (a test harness, a semantic network, drag and drop
installation, etc). 

Fourth, you mention that sometimes a programmer just wants the documentation
of the arguments. There is no reason why we need special syntax for this
and, as mentioned above, the previous programmers did not provide this.
The Axiom compiler does extract this type information while compiling. See
)show Integer
for an example of the output. 

Pamphlet files allow tagging of arguments in such a way that we could
construct automatic hyperlinks for arguments. And the hyperlinks would
go to other pamphlet files so that not only the type of the argument is
apparent but the rational for the choice is available.

Fifth, you said "This is NOT true for the Aldor compiler". Currently the
Aldor compiler will process ++ comments and pass them along... to nothing.

Pamphlet files will work with Aldor code. There is no language restriction
on noweb files (which is why I chose noweb rather than, say, CWeb). If you
look at the Axiom sources virtually every file is a pamphlet file including
lisp, c, boot, makefiles, etc. Thus making a pamphlet file using Aldor is
already supported. And all of the magic that MathAction will support is
automatic. The Aldor compiler should not know about comments.

Sixth, you reference the javadoc-like documentation style
(http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html)

Pamphlet files can contain this information and it can be parsed out
either with noweb, tex, l2h, etc. However, I'd expect that the original
pages in the pamphlet .dvi file can not only contain this information but
format it in a similar way if you so desire with additional information.
Bill Page's MathAction approach also allows multiple people to contribute
a wide rand of expertise to the documentation (for instance, the web page
you reference has a typo which I could fix if it were on a wiki).

As for hierarchical information the src/algebra/Makefile.pamphlet contains
the current lattice of types. This information is waiting for someone to
exploit it. Bill and I have both looked at it in the past. Perhaps it will
get integrated into the MathAction site in some reasonable way.

This is a long winded way of saying that I believe literate documents
(if not exactly pamphlet files) are the way forward not just for Axiom
but for scientific systems in general. The whole Axiom library, while
in pamphlet files now, needs better documentation. The current
"canonical example", which still needs much more work, is
dhmatrix.spad.pamphlet.

I know it all seems like a lot of work but we are at the beginning of
the collision of computing with science. If we go back to the last
century and look at math proofs from that time they seem like just so
much handwaving compared to the standards of proofs today. In 30 years
lightly commented source code with ++ and -- will seem unprofessional.
Algorithms will be expected to have termination proofs, correctness
proofs, examples, test cases, complexity analysis, working source code
and a sound basis in theory in order to pass as professional
scientific work.

All of which is clearly just my opinion on the subject.  But at least
this will give you some idea why I believe ++ comments will die.

\start
Date: Thu, 30 Sep 2004 09:18:06 -0700
From: Bob McElrath
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha <chicha@essi.fr>, Jinlong Cai <jcai3@uwo.ca>, Ralf Hemmecke

Martin Rubey [Martin Rubey] wrote:
> Ralf HEMMECKE writes:
>  > What would you suggest?
> 
> LaTeX. In the spad files, this is the way it is currently done: There are two
> commands, \spad and \axiom, whose meaning I do not really now. Apart of this,
> some simple LaTeX commands like \em and \{ are used. Of course, as little LaTeX
> as possible.

This is the goal of LatexWiki.  The idea is to have a text format that
has markup that is as natural as possible.  If you are not familiar with
StructuredText, take a look at::

    http://mcelrath.org/Notes/StructuredTextRules

I have added basic latex math components like $$, \[\] and
\begin{equation}...\end{equation}.  StructuredText is used by the python
and zope projects for their in-code documentation.  It might also be
appropriate for Axiom.

As I mentioned elsewhere, StructuredTextLatex will soon be available
standalone, so axiom/aldor users need not run all fo zope and zwiki to
look at the source docs.  It will generate either HTML+images for
equations or XHTML+MathML.

\start
Date: Thu, 30 Sep 2004 09:25:04 -0700
From: Bob McElrath
To: Tim Daly
Subject: re: literate programming pamphlet files for MathAction
Cc: chicha@essi.fr, Bill Page, jcai3@uwo.ca, Ralf Hemmecke

root [Tim Daly] wrote:
> I hope that, in the longer term, the mathaction wiki page presents the
> original pamphlet file when you click 'edit'. That would imply running
> noweb in the background when you click 'save'. The hard part, of course,
> is that the change might actually fail, in which case there will be a
> noweb msg or latex log file. 

Right now tha page is not rendered and an error is printed at the bottom
of the page when you view it.  Ideally, this integration should be
tighter.  Perhaps a "test" button that could pop up the rendered page?

> If we could do this then it would be possible (at least technically)
> to maintain axiom directly from the wiki pages. Of course there are
> a lot of little steps along the way. I'd like to see the ability to 
> integrate CVS (or arch?) automatically into web page changes. 

This was mentioned before...

Zope has a rudimentary "change history" that can be used to undo bad
changes, but it is crude as a versioning system.

There is also a Zope product called FileSystemSite in which your site
is stored in a directory on the filesystem, rather than in the ZODB.
Such a directory can simultaneously be a CVS/arch/darcs repository.
Presumably it wouldn't be that hard to get Zope/ZWiki/LatexWiki to
ignore the CVS directory.

\start
Date: Thu, 30 Sep 2004 13:23:16 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Mixing up variables: (was Re: conditionally defined functions)

Hi Martin:

Martin Rubey wrote:

>  > But the two functions vars and isvar? are kind of available, perhaps not named
>  > that way, but surely there are functions similar that serve the same purpose, if
>  > all you want is to test whether a domain has "variables."
> 
> The important thing would be that all these functions would have the same name
> and modeline. Otherwise I cannot test for them. The closest match is the
> function variables.

Having the same function names and modeline of course simplifies the predicate.
What I meant was at the expense of a more complicated predicate, you can
currently make the same test without the new functions. But what you gain in the
(code) efficiency of the predicate, you pay for by adding the functions to
multiple domains.
 
>  > But I still do not see how the above test can rule out a construction like
>  > EXPR EXPR INT.
> 
> It wouldn't. In fact, EXPR EXPR INT would not be forbidden, only, the
> coefficient domain would not be allowed to contain any variables.

In my opinion, I think that (coefficient domain EXPR INT not allowed to have any
variables) is too drastic. Perhaps because of this view, I misunderstood you
intention was to forbid such towers through testing the presence of isvar? etc.

> In fact, for EXPR EXPR INT, to clarify, lets denote this by EXPR COEFF, the
> statement
> 
> if any?(isvar?, vars(thing))
> 
> should always return false, i.e., the situation that Axiom tries to coerce
> something that contains a variable to COEFF should never happen. If it does, I
> misunderstood the coercion process.

Given that the test is categorically included in the constructor EXPR, if it
always return false for EXPR COEFF, it would also have to return false in COEFF
= EXPR INT. No? You did not specify where this "if" statement resides.

I don't know if there are any statement that will make Axiom coerce something
that contains a variable to COEFF, but I have shown you examples where a
variable is coerced into COEFF = POLY INT of SUP(COEFF). So yes, "it does," but
may be it still "should never happen." The "coercion process" is an entirely
interpreter process because it is trying to be "smart" for "lazy" users. I don't
understand how this is done (will have to ask Bob Sutor, or look at source
code). What I am (guess, we are) doing is observe what it does and trying to
infer how it does things. It may be what the Chinese call "the blind men feeling
an elephant." (which means each only gets part of the picture, depending on
where one place his hand).


> 
> Thus, I do not propose to prevent the instantiation of domains. I only propose
> to throw errors when Axiom is forced to do coercions that are not good.

Can you please explain step by step how the "if" line will be called into action
when  Axiom is so forced after a tower is instantiated?
 
>  > > I do admit that to integrate SUP into this picture might be tricky.
>  > >
>  > It sure would be. Even for the others, you have to make sure preventing
>  > "illegal" towers will not break any code.
> 
> I suspect you misunderstood me: my proposal does not make any towers
> "illegal". Hence, it would not break any (well written) code.

My mistake. But you changed the semantics of the tower. Almost by definition,
any code that can be ambiguous/confusing to the reader is not well written. If
such code exists in the library, we should find them and rewrite them. Adding
code to prevent bad code is difficult, because you can never catch all of them.
(This reminds me of  programs that attempts catch students' math mistakes. The
programmers (me included) are never as ingenious as the students.)

>  > > As it now stands, the way to do things is simple: don't use towers of
>  > > domains with variables. (One exeption is polynomials with coefficients
>  > > that are expressions not containing variables: we have to use POLY EXPR
>  > > INT here...)
>  >
>  > That's a good example we have to be careful if we prohibit certain
>  > towers. But that is not the only example.
> 
> Again: following my proposal, POLY EXPR INT would not be prohibited. Quite the
> contrary!
> 
>  > > Do I understand correctly: You propose (roughly) that variables should
>  > > carry a tag that tells which domain they belong to.
>  >
>  > Yes. However, the tag is tied to the coefficient domain (which may have old
>  > variables of its own), not the domain with (the new) variables. This
>  > corresponds better to the mathematical notion of the "variables" ("algebraic
>  > indeterminates" is the precise term) being algebraically independent over
>  > the coefficient domain.
> 
> Good. If you rite up your proposal, maybe you could elaborate a bit on the
> precise tagging. See below.
> 
>  > Let's say I am hunting for two polynomials f(x), g(x) and I know they
>  > satisfy some algebraic relations with coefficents that are polynomials. The
>  > polynomials expressing these algebraic relations would then be in POLY POLY
>  > INT, such as
>  >
>  > h = a(x) y^3 + b(x) z^2 - c(x)
>  >
>  > where a, b, c are in POLY INT, and y, z when substituted by f, g would give
>  > zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of
>  > course, we know it would be better to use specified variables and work in
>  > DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN
>  > carry out these computations in POLY INT alone, but the more natural setting
>  > is POLY POLY INT
> 
> This is a nice example. I'd like to use it to raise an issue with your
> proposal: suppose you have somehow generated h in POLY COEFF (where COEFF =
> POLY INT, just to make it easier to talk about), such that y and z are
> variables in POLY COEFF and a(x), b(x) and c(x) are coefficients, i.e., in
> COEFF.
> 
> The question is, how to multiply to such POLY COEFF's ?
> 
> Suppose you ask for h*x. How would you instruct Axiom to understand the
> multiplier x as an element of COEFF, and how would you instruct Axiom to
> understand x as a variable in h?
> 
> )set mess scope on
> 
> (1) h::(POLY POLY INT)*x::(POLY INT)
> 
> -> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...
> 
> versus
> 
> (2) h::(POLY POLY INT)*x::(POLY POLY INT)
> 
> -> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...
> 
> correct?

I suppose you are asking how the interpreter can discern the meaning of h*x.
Under the tag proposal, x is already bound and tagged as x$(COEFF) by the prior
use of a(x): COEFF, and h: POLY COEFF is also bound (note that I am not using
::).  So h*x (not h:: POLY COEFF * x:: COEFF) has unambiguous meaning. If you
insist on using :: as given, then both coercions in (1) are unnecessary, and the
first coercion in (2) for h is unnecessary while the coercion x::POLY COEFF
would be the natural coercion (that is COEFF as subdomain of POLY, similiar to
saying 3::POLY INT); the multiplication would be the multiplication in POLY
COEFF, but since x is in COEFF, this is scalar multiplication (similar to 3*t in
POLY INT). In other words, both (1) and (2) produce same result and uses the
same scalar multiplication. The "scoped" output you gave for (2) is incorrect in
that the notation x$(POLY COEFF) means a (tagged) variable x of the outer POLY,
so it is a different x.

Perhaps if you change your question to simply how to coerce 'w, where 'w:Symbol,
to POLY COEFF and to COEFF, it would illustrate what is needed better (at least
one less confusion). (I'll drop the ' before w now, having made clear that w is
"virgin"). The solution is quite simple in fact (and you'll like this): having
all existing variables clearly tagged, we can assign a virgin symbol using your
outer rule! So

(3) w::POLY POLY INT
   -> w$(POLY COEFF)
(4) w::POLY INT
   -> w$COEFF
 
Of course, I am only using COEFF to clarify where w belongs. But this is really
not necessary because the way tags are *output* adopts your "outer" convention
in the sense that the variable always belong to the Varset of the outermost
domain (not that it "takes" from the inner domains). To avoid confusion, I will
refer to this as the "outer output" convention. *Internally*, w$COEFF may be a
concatenation of a hash for w and a hash for INT (as a variable over INT) and
w$(POLY COEFF) would be a concatenation of the hash for w and a hash for COEFF. 

Note that this method of tagging (to the coefficient domain and not the
polynomial ring) allows for "mixing" or lifting. If a user wants to have UP(w,
INT), that w would also be the *same* as the w in POLY INT and coercion between
the two domain is a breeze because in both case, it is actually the same symbol
(concatenation of hash for w and hash for INT). If the user wants UP(w, COEFF)
this w would be the same as the w in POLY COEFF. Again this is all natural when
we say, mathematically, let w be an indeterminate (or transcendental) over INT
-- mathematicians DON'T care which polynomial ring w belongs to! (too bad Axiom
cares). Just another example to clarify:

  w$(POLY COEFF)::UP(w, COEFF)   is perfectly ok.

  w$(POLY COEFF)::UP(w, INT)     is ok too 

(because w transcendental over COEFF=POLY INT is a fortiori transcendental over
INT)

  w$(POLY INT)::UP(w, COEFF)     becomes a ground element

 Note again: w$(POLY INT) is NOT w$(UP(w, COEFF)) because the transcendental w
over INT is not necessarily transcendental over COEFF=POLY INT --in fact in this
example, it belongs to COEFF.

> Following my approach, you couldn't be *that* lazy. You'd have to say
> 
> h::DMP([y,z], POLY INT).

Wouldn't you rather be lazier? :-)

> I realize right now, that I didn't consider POLY UP(x, INT) yet... As my
> proposal is formulated right now, the coefficient domain would not contain any
> variables. That's might not be that good, since POLY FRAC UP(x, INT) might be
> an interesting domain.

According to your "outer" rule, POLY UP(x, INT) would be the same as POLY INT,
and POLY FRAC UP(x, INT) would be POLY FRAC INT. So there would be no reason to
use the towers, except that the towers may be constructed "after the fact" (that
UP(x, INT) was already used in previous computations). This is exactly what I
meant by your rule, if implemented, would forbid prior use (though not the tower
itself).

>  > > For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would be a
>  > > variable of the outer domain, y a coefficient. No confusion can arise.
>  >
>  > Yes, but you would disallow the prior use of x in POLY INT, which is where we
>  > started! I would interpret, when a user uses UP(x, POLY INT), that (s)he wants a
>  > new indeterminate x over POLY INT.
> 
> I wouldn't, but I see your point.

What do you mean "I wouldn't"? Even under your approach, x is a new
indeterminate over POLY INT because POLY INT cannot contain x!

>  > I don't know the mechanics of how the interpreter handles ::. We have seen
>  > it uses at least more than one way (that is, it may use coerce, convert, and
>  > here, makeSUP). I often don't know what map is used since ")set mess bot on"
>  > does not always give output on "simple" things like this.
> 
> It would be really nice to have )set me bo on give output here too! I suspect
> that the problem is that not all of the code is in the algebra, where I think
> it should be.

I agree that it is likely the interpreter has magic code, but I don't see how
such code be in the algebra (spad source). Because users are lazy, the
interpreter has to make the choice or guess the choice of which (often
overloaded) function the user wants. In the algebra code, you can't be lazy or
it won't compile! Sometimes I do wish the compiler gets some of the IQ from the
interpreter, it would have saved a lot of time -- when stuck with a problem on
coercion, I often go to the interpreter for help using )set mess bot on.

>  > > I agree that your proposal (if I understood it) is also clean.
>  >
>  > Thanks. I probably wrote too much!
> 
> No. It is difficult to guess what I know or understand, and what needs
> explaining. You did explain many things I knew, you did explain many things I
> did not know...
> 
>  > > I meant to say: "put these checks into the algebra." This is clearly possible.
>  >
>  > Not clear to me at all! Perhaps I am missing the obvious. I believe it is
>  > going to be a mess even if it is possible. It would be difficult to specify
>  > precisely what towers are allowed or not.
> 
> Yes.
> 
>  > I think we should allow all towers and variables should not be mixed (in any
>  > solution) and it is easier to do so with tags than with tests.
> 
> Yes. However, we have to agree on one philosophy, I'm afraid. Would you be able
> to write down as cleanly as possible the two proposals and add them add them at
> the bottom of
> 
> http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong
> 

I visited your page and it is taken from your posts. However, we have posted
back and forth and as you said, comments cannot be taken out of context and in
email, we quote each other. I don't know how to do that in mathaction. 

I could be wrong, but my impression is that the attractiveness of mathaction
pages is that you can run live Axiom code and it is browser based. So I think it
is an ideal platform for documentation or summaries with examples, but a rather
poor platform for casual discussion. For example, one can only add comments at
the bottom, making it difficult to refer to lines or codes on the page. But even
if it becomes more fancy like MS Word, where you can insert comments anywhere,
the page would not be "clean". Despite the extra effort, in order that someone
not familiar with the issues can follow, the pages have to be tutorial in style.
And that takes rewriting.
I don't know how detail or how brief I should write (that is, who will be the
readers?)

> 
> (Write a text file, click edit on the top right, paste, click save)

I don't like text files and much prefer LaTeX to get pdf or dvi output. Lots of
text editors don't have good line breaks (or paragraph reflow) and arbitrarily
change them (like most email programs). Is text file the only choice?

The text file would have to include Axiom code fragments as examples. I don't
know how to get "live" axiom with mathaction, the way your pages look.

Well, I think this is truely a joint effort and fruitful discussion. I wouldn't
have thought of the problem (or proposal) if you didn't raise it. So, thanks.


\start
Date: Thu, 30 Sep 2004 13:46:06 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction

On Thu, Sep 30, 2004 at 10:24:32AM +0200, Ralf HEMMECKE wrote:

> Jinlong Cai <jcai3@uwo.ca> wrote another aldor-mode which is certainly 
> more advanced than mine, since it incorporates support for the Aldor 
> debugger. However, I haven't seen his mode openly available.
> 

Hello,

Actually, Jinlong did not write the Aldor emacs mode of which you
speak. That was my work, and I simply gave him the code to use during
his ISSAC demo of the Aldor debugger. 

This aldor mode is not currently on aldor.org since I wrote it with
GNU/Emacs in mind, and have found XEmacs to have a few problems
dealing with the elisp. One I can support both emacs's, it will appear
on aldor.org.

If anyone would like a copy, just email me and I'll gladly send you
it. The code is GPL'ed and I fully intend it to be available to all. 

\start
Date: Thu, 30 Sep 2004 21:29:00 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: re: literate programming pamphlet files for MathAction

Stephen,

Please accept my apologies for mixing the names.

Ralf

Stephen Wilson wrote:
> On Thu, Sep 30, 2004 at 10:24:32AM +0200, Ralf HEMMECKE wrote:
> 
> 
>>Jinlong Cai <jcai3@uwo.ca> wrote another aldor-mode which is certainly 
>>more advanced than mine, since it incorporates support for the Aldor 
>>debugger. However, I haven't seen his mode openly available.
>>
> 
> 
> Hello,
> 
> Actually, Jinlong did not write the Aldor emacs mode of which you
> speak. That was my work, and I simply gave him the code to use during
> his ISSAC demo of the Aldor debugger. 
> 
> This aldor mode is not currently on aldor.org since I wrote it with
> GNU/Emacs in mind, and have found XEmacs to have a few problems
> dealing with the elisp. One I can support both emacs's, it will appear
> on aldor.org.
> 
> If anyone would like a copy, just email me and I'll gladly send you
> it. The code is GPL'ed and I fully intend it to be available to all. 
> 
> Sincerely,
> Steve



