\start
Date: Thu, 1 Nov 2007 00:16:43 -0400
From: Bill Page
To: list
Subject: Re: iterators and cartesian product.

On 10/31/07, Gabriel Dos Reis wrote:
>
> On Wed, 31 Oct 2007, Bill Page wrote:
> | ...
> | I mean: What does Monad as defined in the Axiom library right now:
> |
> | ++  Monad is the class of all multiplicative monads, i.e. sets
> | ++  with a binary operation.
> |
> | have to do with Monads in Haskell?
>
> That is explained in the reference to Philip Wadler's paper I pointed
> to in my earlier message.
>

Philip Wadler's paper is well known and was published in 1992. The
Axiom category

)abbrev category MONAD Monad
++ Authors: J. Grabmeier, R. Wisbauer
++ Date Created: 01 March 1991
++ Date Last Updated: 11 June 1991

and the associated domains:

AlgebraicGivenbyStructuralConstants
AssociatedJoranAlgebra
AssociatedLieAlgebra
FreeNilpotentLie
GenericNonAssociativeAlgebra
LieSquareMatrix

seem to me to refer to subjects very different than Philip Wadler's
paper. I do not see any higher-order functions like 'map', 'unit' or
'join' defined here at all. Certainly Axiom does have various forms of
list comprehensions and functions like 'map' defined for many domains
but I do not see that generalized in any way in the existing Monad
category and associated domains.

Please, what do you see that I am missing?

> | Isn't that what you implied by your comment?
>
> Yes.
>

Sorry, I don't understand that at all. Maybe this discussion is best
saved for another time after I have had more time to think about how
to do these things in Axiom.

\start
Date: Thu, 1 Nov 2007 01:49:22 -0400
From: Bill Page
To: list
Subject: Axiom Wiki and Portal are moving
Cc: William Stein

Dear Axiom Users and Developers;

Earlier in October Tim Daly asked me if I would be able to move the Axiom wiki:

    http://wiki.axiom-developer.org

and the Axiom portal:

    http://portal.axiom-developer.org

web applications to a new server. The server where they have resided
for the last three years is a shared virtual server located at a
privately operated ISP. During the entire time Tim has paid for the
operation of this server from his own personal financial resources.
Meanwhile Tim's priorities for the original Axiom project have been
clarified and two new forks of Axiom (FriCAS and OpenAxiom) have been
created as a result. As implementer of the wiki and portal
applications on the axiom-developer server (based on the 'mathaction'
and 'LatexWiki' extension of ZWiki), I have argued that these
applications should actually support all of the existing Axiom-related
projects (Axiom, FriCAS, OpenAxiom and Aldor on Axiom) developers and
users as well as continue to provide interfaces for Reduce, Maxima,
and Sage. But Tim has decided that he would rather devote the
resources of the axiom-developer.org server to more Axiom-project
specific activities and also (if possible) reduce the cost of
operation of this server. This is certainly his prerogative and it is
my intention to help him meet that goal with as little disruption to
people who current use these applications as possible.

As most of you probably already know, William Stein offered to host a
version of the Axiom wiki and Axiom portal applications on the large
multi-processor computer system that supports the Sage project. So I
have spent some time over the last couple of months re-implementing
mathaction and related software there. The software is not identical
to the software on axiom-developer.org but rather a long-needed
software upgrade based on the most recent release of ZWiki. As a
result, the specific look and feel of the new web sites is not
identical to the old ones. There are some missing features some of
which can be restored by special customizations of ZWiki (e.g. the
lefthand sidebar, the comment preview function and the Axiom menus at
the bottom of the edit page). Some of these I have not yet had time to
do and others I am considering alternative ways of doing something
similar but with less special customization. Also, due to lack of
time, I have moved only a subset of the web pages from the old sites
to the new one. This is true of both the wiki and portal sites.

In spite of this and in view of Tim's desire to complete the move as
soon as possible, I would like to invite everyone to begin using the
new sites now. They can be found at:

    http://axiom-wiki.newsynthesis.org

and

    http://axiom-portal.newsynthesis.org

Don't be fooled by the domain name "newsynthesis.org". This is a
domain name that I own but the names 'axiom-wiki' and 'axiom-portal'
are actually mapped to the 'sage.math.washington.edu' server supplied
by William Stein. I intend to continue to make these names available
for Axiom-related use over at least the next 10 years. I chose this
approach in order to provide as conveniently short urls as possible
and also to permit the urls to remain the same and be remapped in case
of any possible future move of these applications.

For the time being, the applications at 'axiom-developer.org' will
continue to operate but at some point (final details still to be
determined) the old url names may be re-mapped to point at the same
site as the new ones (for search engine compatibility) before they are
eventually phased out altogether and the applications and associated
database removed from axiom-developer.org.

So I would like to encourage everyone who cares about Axiom (and/or
it's forks) and who is interested in wiki and portal support for these
projects to help with testing and re-populating the new sites as soon
as possible. After three years of operation of the Axiom wiki there
are a fairly large number of out-dated, poorly organized and possibly
irrelevant pages which probably should not be simply copied over to
the new site. I would be very very happy if some other Axiom users and
developers would agree to assist with this "shifting" and
re-organizing effort. Copying missing content between the sites can be
easily done by cutting-and-pasting the text from the 'edit' of the old
site to the corresponding 'edit' page of the new site. I would be
happy to discuss details, make suggestions and general try to help
anyone who wants to try this. These web sites are intended to be
community supported web sites and everyone is welcome and encouraged
to participate in making them as useful as possible to all Axiom users
and developers.

The most serious missing component at the new Axiom wiki site is the
existing database of IssueTracker reports. I have tried unsuccessfully
to copy to the old database to the new server. In any case it is also
true that a number of these reports may be obsolete or may not apply
equally to all of the Axiom projects. Also some of the Axiom projects
(forks) have their own way of tracking problems, e.g. OpenAxiom simply
uses SourceForge. So I am open to suggestions on how to proceed with
this transferring this information (and/or comments about whether this
is really necessary or not).

At this time Aldor is the only computer algebra program that has not
yet been installed on the new server. (Axiom, Maxima, Reduce, and Sage
are also working.) My current priority is to complete the build of
Aldor for Axiom so that it will be possible to run the Aldor example
code on the wiki pages again. My intention is to use the newest
version of FriCAS and the new open source release of Aldor. Some
things have changed since I did this last, so it may take a little
more time but this should be completed in the new few days.

And as usual, if you have any questions, comments, suggestions or
criticisms I would be glad to hear them.

\start
Date: 01 Nov 2007 07:21:57 +0100
From: Martin Rubey
To: list
Subject: Re:  Axiom Wiki and Portal are	moving
Cc: William Stein

Dear Bill,

I'm very grateful to you, even though I'm unhappy that axiom-developer.org will
not have the same contents in future.  Oh dear, I link to it in a paper...

Bill Page writes:

>     http://axiom-wiki.newsynthesis.org
> 
> and
> 
>     http://axiom-portal.newsynthesis.org

These names sound quite good to me.  "new synthesis" has something optimistic!

> The most serious missing component at the new Axiom wiki site is the existing
> database of IssueTracker reports. I have tried unsuccessfully to copy to the
> old database to the new server. In any case it is also true that a number of
> these reports may be obsolete or may not apply equally to all of the Axiom
> projects. Also some of the Axiom projects (forks) have their own way of
> tracking problems, e.g. OpenAxiom simply uses SourceForge. So I am open to
> suggestions on how to proceed with this transferring this information (and/or
> comments about whether this is really necessary or not).

Oh dear, that's too bad.  In fact, I'm quite shocked.  

I wanted to make the following suggestion already some time ago: If the three
projects intend to cooperate, I think it would be a very wise thing to have
only one database for bugs.

I like IssueTracker a lot, mainly, because it is so easy to demonstrate the
bug.  Since we have several projects now, it would be necessary though to be
able to select any subset of

fixed in Axiom
fixed in FriCAS
fixes in OpenAxiom

Since FriCas and Axiom refers to the IssueTracker numbers in the logfiles and
in source, it is a must (if possible) to keep the database numbering as is.

Do you know already whether transferring is a fundamental problem?

\start
Date: 01 Nov 2007 09:31:46 +0100
From: Francois Maltey
To: list
Subject: About mutable and functions.

I like this discuss about mutable variables.

You know I also teach caml. I notice that the 2 manners "mutable data" 
and "not-mutable" data must be separate. 
If not, everybody make a lot of errors.

Functional languages, mathematics and not-mutable datas are very close.

What do you think about this concrete matrix example ?

A := matrix [[1,2],[3,4]]
fct A == .... A.(1,1) := 10 .... and the result is a number or others.

Mathematics say that both 3*A matrices bellow are equal :
The variable A is the same and we don't see any assin command.

3*A 
fct A
3*A     --- ve verify the matrix.

We don't understand why A changes.
First we think about the result of fct, not about the manner we get it.

Is it possible to have an automatic copy of the variables in a function ?

On the other hand, if we want to code a matrix sequence we write :
M := matrix [[...]]
fct A == ...A.(1,1):=A.... A -- this A is the result, the new matrix.
M := fct M 
M := fct M -- to iterate.

The time for copying data-structure isn't so long that we must think 
everytime about it. Axiom is designed for mathematics.

Axiom Guru's find obvious to code
fct M == A:=copy M ... ....     in the first case.
fct A == A.(1,1) := 12 .... A   in the second case.
and it's a little faster.

But that forces to teach what are mutable/not-mutable data 
in the first courses of axiom. 
This isn't the aim of axiom which is a mathematical language.

fct A == ... ....               axiom copy the matrix.
fct A == A.(1,1) := 12 .... A   the outer M := explains the matrix change.

Maple use a silly evalm matrix command. 
And I never get difficult with mupad which copy data structure by default.

And what do you think about lists ?
My first thought for mathematics thinks that lists aren't mutable.
But list becomes mutable with L.3 := 33. This assign command is too easy.

A setelt! (L, 3, 33) doesn't hide the same difficult.

\start
Date: Thu, 1 Nov 2007 07:50:35 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Re: iterators and cartesian product.

On Thu, 1 Nov 2007, Bill Page wrote:

| 
| On 10/31/07, Gabriel Dos Reis wrote:
| >
| > On Wed, 31 Oct 2007, Bill Page wrote:
| > | ...
| > | I mean: What does Monad as defined in the Axiom library right now:
| > |
| > | ++  Monad is the class of all multiplicative monads, i.e. sets
| > | ++  with a binary operation.
| > |
| > | have to do with Monads in Haskell?
| >
| > That is explained in the reference to Philip Wadler's paper I pointed
| > to in my earlier message.
| >
| 
| Philip Wadler's paper is well known and was published in 1992.

Then, I'm surprised you do not see they are the same categorial notion.
It is not that I'm unwilling to explain what it is.  I just don't have
the time right now.  However, since I do have references to existing
explanations, I can point you there.  Wadler's paper is one of the
simplest explanations. Or, you can go directly read Moggi's paper.
If you still disagree, then, let stop it at there.

\start
Date: Wed, 31 Oct 2007 13:36:52 -0700
From: Arthur Ralfs
To: Constantine Frangos
Subject: Re: [Axiom-math] Axiom: Errors on suse 10.2, 32 bit

Constantine,

There are various versions of "axiom" floating around but to build
the silver branch go here:

http://wiki.axiom-developer.org/AxiomSources

and execute the "git-clone" command in a suitable directory.
git is available under Yast in opensuse.

There is one glitch in that opensuse changed the location
of the X libraries with 10.2 and the locations specified in
the top level Makefile have to be changed.

Open up the Makefile.pamphlet and go to the Makefile.linux
section.  The X libraries used to be in something like "/usr/X11/lib"
or maybe "/usr/X11R6/lib" and are now in just "/usr/lib".  So
Change the "XLIB" environment variable to /usr/lib and eliminate
any other X11 or X11R6 you see, like maybe in CCF and LDF
(I'm looking at a Makefile.pamphlet that I've already altered).

Then just follow the directions in readme, setting the AXIOM and
PATH variables as told to by configure.

You of course have to make sure that you have latex and the
basic development packages installed as well.

Arthur

Constantine Frangos wrote:
> Thanks for the response.
>
> I will try to build axiom on suse 10.2. If possible please email me the 
> website from where I can download the sources.tgz, etc, and any available 
> instructions. 
>
> (I want to install under a specific directory and not the default 
> /usr/local/... )
>
> I dont know why "fedora"  appears as a directory name. It could imply that 
> the binaries (I downloaded) were built on a fedora system ?
>
> C. Frangos.
>
> On Wednesday 31 October 2007 18:45, you wrote:
>   
>> C. Frangos wrote:
>>     
>>> I have installed the axiom binaries on a suse linux 10.2, 32 bit system,
>>> and am trying some basic commands.
>>>
>>> I am getting the errors below.
>>>
>>> (Some time ago Tim Daly reported similar errors on my behalf. The two
>>> responses that were posted referred to lisp, which I
>>> unfortunately do not know. Its not clear how to fix the problem).
>>>
>>> (In the meantime I am using 2004 axiom (no graphics) compiled on an old
>>> suse linux 7.2 system, 32 bit).
>>>
>>> Any assistance would be much appreciated.
>>>
>>> TIA,
>>>
>>> Constantine Frangos.
>>>
>>>
>>>
>>>
>>> (11) -> x(s)==(q:=cos(s);return(q))
>>>                                                                    Type:
>>> Void (12) -> x(y)
>>>    Compiling function x with type Variable y -> Expression Integer
>>> cc1: error: /root/axiom/mnt/fedora5/bin/../h: Permission denied
>>> (12) -> x(y)
>>>
>>>    (12)  cos(y)
>>>                                                      Type: Expression
>>> Integer (13) ->
>>>
>>>
>>> (11) -> draw(sin(x),x=-1..1);
>>>    Loading /home/apps/axiombin/mnt/fedora5/algebra/SEG.o for domain
>>>       Segment
>>>    Loading /home/apps/axiombin/mnt/fedora5/algebra/SEGBIND.o for domain
>>>       SegmentBinding
>>>    Loading /home/apps/axiombin/mnt/fedora5/algebra/FLOAT.o for domain
>>>       Float
>>> .................................
>>>  Loading /home/apps/axiombin/mnt/fedora5/algebra/DISPLAY.o for
>>>       package DisplayPackage
>>>    Loading /home/apps/axiombin/mnt/fedora5/algebra/MKFLCFN.o for
>>>
>>>
>>>       package MakeFloatCompiledFunction
>>> cc1: error: /root/axiom/mnt/fedora5/bin/../h: Permission denied
>>>
>>>    >> System error:
>>>
>>>    (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
>>> -I/root/axiom/mnt/fedora5/bin/../h  -O3 -fomit-frame-pointer -c
>>> \"/tmp/gazonk7.c\" -o \"/tmp/gazonk7.o\" -w") returned a non-zero value
>>> 0.
>>>
>>> (11) ->
>>>
>>>
>>> _______________________________________________
>>> Axiom-math mailing list
>>> Axiom-math@nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/axiom-math
>>>       
>> Hi Constantine,
>>
>> I tried your commands on openSUSE 10.2 with a silver build from 2007-08-25.
>> They both worked although when I closed the graph window I got the messages
>> below.  Why don't you build axiom yourself rather than using binaries?
>> I don't
>> know much about these matters but I notice "fedora5" in your error
>> messages. Does that mean your binary was built on fedora?
>>
>> Arthur Ralfs
>>
>> (4) -> *** glibc detected ***
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman:
>> free(): invalid pointer: 0x0805309c ***
>> ======= Backtrace: =========
>> /lib/libc.so.6[0xb7d606e1]
>> /lib/libc.so.6(cfree+0x89)[0xb7d61d79]
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman[0x80
>> 4a385]
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman[0x80
>> 4b577]
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman[0x80
>> 4b631]
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman[0x80
>> 49155] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7d11f9c]
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman[0x80
>> 48d81] ======= Memory map: ========
>> 08048000-0804f000 r-xp 00000000 08:06 4766627
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman
>> 0804f000-08050000 r--p 00006000 08:06 4766627
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman
>> 08050000-08051000 rw-p 00007000 08:06 4766627
>> /home/arthur/axiom/silver/silver-07-08-25/silver/mnt/linux/lib/viewman
>> 08051000-08074000 rw-p 08051000 00:00 0          [heap]
>> b7b00000-b7b21000 rw-p b7b00000 00:00 0
>> b7b21000-b7c00000 ---p b7b21000 00:00 0
>> b7ce0000-b7cea000 r-xp 00000000 08:05 2019224    /lib/libgcc_s.so.1
>> b7cea000-b7cec000 rw-p 00009000 08:05 2019224    /lib/libgcc_s.so.1
>> b7cec000-b7cee000 rw-p b7cec000 00:00 0
>> b7cee000-b7cf0000 r-xp 00000000 08:05 2019186    /lib/libdl-2.5.so
>> b7cf0000-b7cf2000 rw-p 00001000 08:05 2019186    /lib/libdl-2.5.so
>> b7cf2000-b7cf6000 r-xp 00000000 08:05 2352187    /usr/lib/libXdmcp.so.6.0.0
>> b7cf6000-b7cf8000 rw-p 00003000 08:05 2352187    /usr/lib/libXdmcp.so.6.0.0
>> b7cf8000-b7cfa000 r-xp 00000000 08:05 2352185    /usr/lib/libXau.so.6.0.0
>> b7cfa000-b7cfc000 rw-p 00001000 08:05 2352185    /usr/lib/libXau.so.6.0.0
>> b7cfc000-b7e24000 r-xp 00000000 08:05 2019180    /lib/libc-2.5.so
>> b7e24000-b7e25000 r--p 00128000 08:05 2019180    /lib/libc-2.5.so
>> b7e25000-b7e27000 rw-p 00129000 08:05 2019180    /lib/libc-2.5.so
>> b7e27000-b7e2a000 rw-p b7e27000 00:00 0
>> b7e2a000-b7f42000 r-xp 00000000 08:05 2352770    /usr/lib/libX11.so.6.2.0
>> b7f42000-b7f46000 rw-p 00118000 08:05 2352770    /usr/lib/libX11.so.6.2.0
>> b7f46000-b7f48000 rw-p b7f46000 00:00 0
>> b7f6f000-b7f70000 r-xp b7f6f000 00:00 0          [vdso]
>> b7f70000-b7f8b000 r-xp 00000000 08:05 2019173    /lib/ld-2.5.so
>> b7f8b000-b7f8d000 rw-p 0001a000 08:05 2019173    /lib/ld-2.5.so
>> bfc9d000-bfcb4000 rw-p bfc9d000 00:00 0          [stack]

\start
Date: Thu, 1 Nov 2007 10:07:09 -0400
From: Bill Page
To: Martin Rubey
Subject: Re: Axiom Wiki and Portal are moving

Martin,

On 01 Nov 2007 07:21:57 +0100, you wrote:
>
> I'm very grateful to you, even though I'm unhappy that axiom-developer.org
> will not have the same contents in future.  Oh dear, I link to it in a paper...
>

I haven't checked this with Tim but I think it his intention to retain
ownership of the 'axiom-developer.org' domain for the foreseeable
future independent of what ever happens to the 'axiom-developer.org'
server. Even though the Axiom wiki and portal applications will not be
running on the 'axiom-developer.org' server at some time in the near
future, it is possible of the owner of a domain to map specific names
in that domain to other machines. So with Tim's help we could manage
to keep the names  'wiki.axiom-developer.org' and
'portal.axiom-developer.org' pointing at working versions of the Axiom
wiki and portal. Of course these web sites are always subject to
change over time since that is the nature of the applications but I do
not think you should fear that the link in your paper will not work in
the immediate future.

> Bill Page writes:
>
> >     http://axiom-wiki.newsynthesis.org
> >
> > and
> >
> >     http://axiom-portal.newsynthesis.org
>
> These names sound quite good to me.  "new synthesis" has something optimistic!
>

Good! I am very optimistic about Axiom. :-)

> > The most serious missing component at the new Axiom wiki site is the existing
> > database of IssueTracker reports. I have tried unsuccessfully to copy to the
> > old database to the new server. In any case it is also true that a number of
> > these reports may be obsolete or may not apply equally to all of the Axiom
> > projects. Also some of the Axiom projects (forks) have their own way of
> > tracking problems, e.g. OpenAxiom simply uses SourceForge. So I am open to
> > suggestions on how to proceed with this transferring this information (and/or
> > comments about whether this is really necessary or not).
>
> Oh dear, that's too bad.  In fact, I'm quite shocked.
>

Change is inevitable...

> I wanted to make the following suggestion already some time ago: If the three
> projects intend to cooperate, I think it would be a very wise thing to have
> only one database for bugs.
>

I agree.

> I like IssueTracker a lot, mainly, because it is so easy to demonstrate the
> bug.  Since we have several projects now, it would be necessary though to be
> able to select any subset of
>
> fixed in Axiom
> fixed in FriCAS
> fixed in OpenAxiom
>

That is a good suggestion. I think we can easily implement that.

Related to this is a subject which you have raised in the past about
mathaction. I think that in order to fully support all three flavors
of Axiom it will also probably be necessary to allow a user to specify
which version of Axiom is used to execute the commands contained in a
web page. Given the nature of the way that mathaction software works
(because it runs the entire contents of a page in one "batch" when you
click "save"), it would be difficult to refer to more than one version
of Axiom in the same web page. But I think that is desirable and I
plan to find a way to accomplish this. Hopefully pages which refer to
more than one version will be rare.

I propose the following syntax:

  \begin{axiom}[open-axiom]
  ...
  \end{axiom}

Perhaps we could also support some standard versions, e.g.

  \begin{axiom}[fricas,1.1]
  ...
  \end{axiom}

Here [...] is an optional parameter. {axiom} by itself would refer to
one of the three versions of axiom (no guarantee which one).
{axiom}[open-axiom] would refer to the most recently installed version
of open-axiom, etc.

> Since FriCas and Axiom refers to the IssueTracker numbers in the logfiles and
> in source, it is a must (if possible) to keep the database numbering as is.
>

That is possible since issuetracker entries are just wiki pages and
these can be easily renamed.

> Do you know already whether transferring is a fundamental problem?
>

No it is not a fundamental problem, it is only a result of a
combination of changes that makes the usual method of doing this (by a
program call ZSyncer) fail. The main reason for the failure is that
the page type field that indicates to ZWiki how to process the
contents of a page has changed in this new version. I tried to resolve
this problem by using the "export to xml" function that is built into
Zope and by using a script to edit the page type field before
re-importing it to the new server, but then I discovered that the
format of this xml file is quite complex and has also changed. To make
this work would require more time and programming. One approach might
be to hach the ZSyncer package so that it makes the change of page
types internally during the transfer.

The problem with the usual "cut-and-paste" method is that I have not
found any way to transfer the status and classification field
information. Only the text content of the page is visible. Of course
it would be possible to set the fields later, but we are talking about
nearly 300 pages.

An alternative that I haven't checked is using "External Edit". I do
not have the external edit feature enabled on my workstation so I
cannot easily check. Martin, I think you do use this right? Could you
check if the status field information appears editable when you access
the page this way? One more approach that *might* work is to use ftp
to access the page and copy it to the new system. ftp is currently
enabled at the axiom-developer.org site but not yet at the
newsynthesis site. I will try this as soon as I get a bit more serious
time to spend on it (this weekend).

\start
Date: Thu, 1 Nov 2007 09:13:19 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Re: Axiom Wiki and Portal are moving

On Thu, 1 Nov 2007, Bill Page wrote:

| > I like IssueTracker a lot, mainly, because it is so easy to demonstrate the
| > bug.  Since we have several projects now, it would be necessary though to be
| > able to select any subset of
| >
| > fixed in Axiom
| > fixed in FriCAS
| > fixed in OpenAxiom
| >
| 
| That is a good suggestion. I think we can easily implement that.

Given my past experience with Axiom, I strongly feel that OpenAxiom
should not be prevented from maintaining its tracker.  That by no
means implies 'non-cooperation' -- but I cannot prevent determined
people to construe it that way.  We can definitely work out two-way
communication channels between the tracker if that is possible.

\start
Date: Thu, 1 Nov 2007 10:30:52 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Axiom Wiki and Portal are moving

On 11/1/07, Gabriel Dos Reis wrote:
> On Thu, 1 Nov 2007, Bill Page wrote:
>
> | > I like IssueTracker a lot, mainly, because it is so easy to demonstrate the
> | > bug.  Since we have several projects now, it would be necessary though to be
> | > able to select any subset of
> | >
> | > fixed in Axiom
> | > fixed in FriCAS
> | > fixed in OpenAxiom
> | >
> |
> | That is a good suggestion. I think we can easily implement that.
>
> Given my past experience with Axiom, I strongly feel that
> OpenAxiom should not be prevented from maintaining its tracker.

I absolutely agree with you! I think the issue tracking system at
SourceForge is very good even though it does not allow one to easily
illustrate a problem. It is standard and well known to open source
developers.

If you would prefer that users of OpenAxiom only submit reports to the
tracker at SourceForge, we can easily insert a warning message in the
issuetracker on the Axiom wiki providing a link and informing users
that they should instead submit a report at SourceForge.

> That by no means implies 'non-cooperation' -- but I cannot prevent
> determined people to construe it that way.

I understand that. I do not see your position as 'non-cooperation' -
quite the opposite. I think you need to be free to develop the project
using the best tools available. There are a lot of different options.

> We can definitely work out two-way communication channels
> between the tracker if that is possible.
>

I think some things are possible but as usual not so easy. For example
it is possible to configure ZWiki to accept mail sent to a specific
address on the server. The mail could for example originate from a
subscription to the tracker system at SourceForge. The mail could be
filtered and added to a specific web page on the Axiom wiki. Perhaps a
similar link could be implemented in the other direction since I think
it is possible to submit issues to SourceForge via email, right?

\start
Date: 01 Nov 2007 12:54:00 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Axiom-mail] Axiom Wiki and Portal are moving
Cc: William Stein

Bill Page writes:

| In spite of this and in view of Tim's desire to complete the move as
| soon as possible, I would like to invite everyone to begin using the
| new sites now. They can be found at:
| 
|     http://axiom-wiki.newsynthesis.org
| 
| and
| 
|     http://axiom-portal.newsynthesis.org

What will happen to the email MathAction?

\start
Date: Thu, 1 Nov 2007 14:14:10 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Axiom Wiki and Portal are moving
Cc: William Stein

On 01 Nov 2007 12:54:00 -0500, Gabriel Dos Reis wrote:
> Bill Page writes:
>
> | new sites now. They can be found at:
> |
> |     http://axiom-wiki.newsynthesis.org
> |
> | and
> |
> |     http://axiom-portal.newsynthesis.org
>
> What will happen to the email MathAction?
>

Right now on 'axiom-developer.org' email sent to
'MathAction' containing a prefix in the subject
line such as

  Subject: [Moving] ...

is automatically added as a comment to the page named 'Moving' on the
Axiom Wiki. This works well for people who are subscribed to the wiki
so that that receive notices of new pages and edits with this same
return address.

This includes Names that begin with numbers, eg. [187 trouble with
tuples] which refer to issue tracker reports.

Doing this requires a special alias in the configuration of sendmail
on the server to pipe the content of the email to a particular method
called 'mailin' at the wiki url. I have not yet asked William Stein if
he is willing to allow this sort of 'mailin' processing on the
'sage.math.washington.edu' server. If so, then we can at least
temporarily redirect the old email address to the new one at for
example: 'mathaction@axiom.newsynthesis.org'

Alternatively we could just redirect 'MathAction'
to some appropriate mailing list.

Any preferences?

\start
Date: Thu, 1 Nov 2007 13:19:06 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Axiom-mail] Axiom Wiki and Portal are moving
Cc: William Stein

On Thu, 1 Nov 2007, Bill Page wrote:

| Doing this requires a special alias in the configuration of sendmail
| on the server to pipe the content of the email to a particular method
| called 'mailin' at the wiki url. I have not yet asked William Stein if
| he is willing to allow this sort of 'mailin' processing on the
| 'sage.math.washington.edu' server. If so, then we can at least
| temporarily redirect the old email address to the new one at for
| example: 'mathaction@axiom.newsynthesis.org'
| 
| Alternatively we could just redirect 'MathAction'
| to some appropriate mailing list.
| 
| Any preferences?

If newsynthesis.org is going to be the `preferred' domain name, one
may just discontinue MathAction as well.  But, not
having to do the actual work, it might be easier for me to state what
should be done...

\start
Date: Thu, 1 Nov 2007 14:29:54 -0600
From: Tim Daly
To: Bill Page
Subject: wiki.axiom-developer.org

Bill,

+I haven't checked this with Tim but I think it his intention to retain
+ownership of the 'axiom-developer.org' domain for the foreseeable
+future independent of what ever happens to the 'axiom-developer.org'
+server. Even though the Axiom wiki and portal applications will not be
+running on the 'axiom-developer.org' server at some time in the near
+future, it is possible of the owner of a domain to map specific names
+in that domain to other machines. So with Tim's help we could manage
+to keep the names  'wiki.axiom-developer.org' and
+'portal.axiom-developer.org' pointing at working versions of the Axiom
+wiki and portal. Of course these web sites are always subject to
+change over time since that is the nature of the applications but I do
+not think you should fear that the link in your paper will not work in
+the immediate future.

In the interest of keeping things running we can point the names
you need to the new server location and continue to use 
wiki.axiom-developer.org and portal.axiom-developer.org. 
Feel free to change the httpd.conf file to forward-point.
Thus Martin's references should continue to function.

The server costs have been rising due to the huge data loads on the
machine. I need to reduce that monthly outlay so I plan to strip most
of the non-essential data. Most of the data costs are associated with
the wiki, the portal, and your home directory. It is costing me
several thousand dollars a year to maintain that server at the present
time and the costs have risen every month. At the current rate of rise
the server will cost me about $5000./yr within a year. I need to reduce
this cost considerably. Thus, I've asked you to find another server
and William Stein has been kind enough to host your effort.

\start
Date: Thu, 1 Nov 2007 22:37:33 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re:  Axiom Wiki and Portal are	moving
Cc: William Stein

Bill Page wrote:
> 
> Dear Axiom Users and Developers;
> 
> Earlier in October Tim Daly asked me if I would be able to move the Axiom wiki:
> 
>     http://wiki.axiom-developer.org
> 
> and the Axiom portal:
> 
>     http://portal.axiom-developer.org
> 
> web applications to a new server.

> In spite of this and in view of Tim's desire to complete the move as
> soon as possible, I would like to invite everyone to begin using the
> new sites now. They can be found at:
> 
>     http://axiom-wiki.newsynthesis.org
> 
> and
> 
>     http://axiom-portal.newsynthesis.org
> 

> So I would like to encourage everyone who cares about Axiom (and/or
> it's forks) and who is interested in wiki and portal support for these
> projects to help with testing and re-populating the new sites as soon
> as possible. After three years of operation of the Axiom wiki there
> are a fairly large number of out-dated, poorly organized and possibly
> irrelevant pages which probably should not be simply copied over to
> the new site. I would be very very happy if some other Axiom users and
> developers would agree to assist with this "shifting" and
> re-organizing effort. Copying missing content between the sites can be
> easily done by cutting-and-pasting the text from the 'edit' of the old
> site to the corresponding 'edit' page of the new site.

Bill, I must admit that I have doubts concerning your migration
tactic.  AFAU there are two goals:

1) Primary goal: migrate content and users from the old site
   to the new site.
2) Secondary goal: update software and the content.

As you wrote: Axiom wiki is a comunity site, so migrating users
to the new site is crucial.  But to migrate users it is
essential to migrate content.  I took quick look at the new site
and I see that a large part (most??) of content is missing
-- for example most links on AxiomContributions page does not work
and many positions from the page on the old site are missing.

IIUC you propose to transfer rest of the content via cutting-and-pasting
from the old site.  I think this is problematic: without proofreading
almost any automatic procedure will work better.  You probably hope
that volunteers will proofread the content while copying.  However,
it seems that creating current content took about 3 years.  I would
expect that proofreading the site will take month or two and
proofreaders will be slowed down by the need to copy things --
I am not saying that proofreading itself takes a lot of time,
but simply that our volunteers are in general busy, and can spend
only a short time doing this.

During that time the new site will be more or less broken, so many
users will try to use the old site -- since only old site will
be "complete".  Similarly links will continue to point to the old
site.  Another problem is that users may come to the old place and
add content there -- migrating additions will cause extra trouble.

I would suggest to migrate content as much as possible in automatic
way.  Once the new site is fully functional I would made first
stage of transition:
-- put prominent notice about new site on the front page of
   the old site
-- change old site to read-only and display notice about new
   site on any attempt to edit
-- redirect all links to the new site.

In the next stage (two weeks or maybe month later) I would replace
all pages on the old site by a notice about move and link to
the corresponding page on the new site.  I would handle updates
to the content separately.

Rationalle: without proper action users will continue to come
to the old site: it shows in search engines, it is in bookmarks,
there are links to it.  The first stage is intended to shift
critical mass of links and users to the new site.  To avoid loosing
users old site should be operational.  Making old site read-only
should avoid problems with synchronization.  Redirecting links
should help with search engines and bookmarks -- search engines
should notice new site, new bookmarks to links will point to
the new site.

Concerning update of content: the move may cause some loss of
users.  Operating both sites in paralell is intended to minimize
user loss.  However, it is essential that new site is fully
operational -- otherwise users will go to the old site or we may
loose them.  IMHO trying to update content during migration
slows down migration and causes extra work.


> The most serious missing component at the new Axiom wiki site is the
> existing database of IssueTracker reports. I have tried unsuccessfully
> to copy to the old database to the new server. In any case it is also
> true that a number of these reports may be obsolete or may not apply
> equally to all of the Axiom projects. Also some of the Axiom projects
> (forks) have their own way of tracking problems, e.g. OpenAxiom simply
> uses SourceForge. So I am open to suggestions on how to proceed with
> this transferring this information (and/or comments about whether this
> is really necessary or not).
>

FriCAS also has a bug tracker at SourceForge.  As a person reading
bug reports I find bugzilla format preferable compared to current
IssueTracker format.  More precisely:
-- bugzilla is more restrictive when comes to edits, for example
   for normal users is append-only and does not allow unautorized
   changes to metadata (bug classification)
-- IssueTracker shows Axiom output as images which is unsearchable,
   does not work on text terminal and may hide some important
   information 


However, I feel that access to old reports is important, so I certainly
would like to see old reports at the new site.

I belive that common bug tracker for all Axiom forks would be good.
In the past Tim said that he does not want FriCAS bugs in Axiom bug
tracker, so FriCAS bug tracker was created.  Certainly, common
bug tracker make sense only if one can restrict view so that
only bugs reported against given fork are visible.  Technically,
this should be not a problem...

\start
Date: Fri, 2 Nov 2007 11:22:47 -0400
From: Bill Page
To: list
Subject: Re: Axiom Wiki and Portal are moving
Cc: William Stein

On 11/1/07, Waldek Hebisch wrote:
>
> Bill Page wrote:
> ...
> > new sites now. They can be found at:
> >
> >     http://axiom-wiki.newsynthesis.org
> >
> > and
> >
> >     http://axiom-portal.newsynthesis.org
> >
> ...
> Bill, I must admit that I have doubts concerning your migration
> tactic.  AFAU there are two goals:
>
> 1) Primary goal: migrate content and users from the old site
>    to the new site.
> 2) Secondary goal: update software and the content.
>

Waldek, I very much appreciate your taking the time to comment. I also
have doubts as I will explain below. But I would state my own goals
with respect to the migration somewhat differently:

 Primary goal 1: Support all versions/forks of Axiom at one website
 Primary goal 2: Reduce the operating costs of the axiom-developer.org website
 Secondary goal 1: update software
 Secondary goal 2: migrate critical and selected content

The first three goals are well served by re-installing the web
applications at another site.
Notice I do not mention either updating content or migrating users.

> As you wrote: Axiom wiki is a comunity site, so migrating users
> to the new site is crucial.  But to migrate users it is
> essential to migrate content.  I took quick look at the new site
> and I see that a large part (most??) of content is missing
> -- for example most links on AxiomContributions page does not work
> and many positions from the page on the old site are missing.
>

I think we should be quite honest: There are very few users. Only
about 3 or 4 people have ever made any effort to actually use the web
site in the way it was intended - as a wiki, a community maintained
web site. I do not think there will be any problem convincing these
same people to continue to contribute to the new site.

On the other hand, from the log statistics we can see that the Axiom
wiki website does have quite a large number of visits by people who
want only to read something about Axiom and is also very actively
crawled by the major search engines. From my point of view, I think
the partial content that I have already copied from the old site to
the new is sufficient to sustain this sort of use of the site.

> IIUC you propose to transfer rest of the content via cutting-and-pasting
> from the old site.  I think this is problematic: without proofreading
> almost any automatic procedure will work better.  You probably hope
> that volunteers will proofread the content while copying.

I do not understand your comment about proofreading. I suspect that
probably my reference to cut-and-paste was not very clear and that you
probably are not very familiar with how the content of the Axiom is
created and maintained. Cut-and-paste is simple. It involves only a
few steps and the entire content of a page is transferred and
re-created in essential one step by clicking Save.

Here is what I was hoping that you would do:

When you looked at the AxiomContributions page and noticed that some
apparently useful content was missing you could have added it with
less than 30 seconds effort. For example in detail:

1) At the new site

   http://axiom-wiki.newsynthesis.org/AxiomContributions

2) You see

  [CommonDenominator for polynomials]?

  where you would like to see a link to this web page that existed on
the old site.

3) Click on the blue ? to begin (re-)creating the page.

4) Open the source for this page at the old site in a separate browser window

  http://wiki.axiom-developer.org/CommonDenominatorForPolynomials/src

  Notice /src at the end of the url and also the rule of removing
blanks and capitalizing the first letter of each word.

5) Click Edit/Select All, Edit/Copy

6) Place the cursor in textbox in the page creation form and click
Edit/Paste to move the enter text of the page

7) Click the 'Create' button to render the new page. The link on the
AxiomContributions has been automatically updated.

Maybe during this process you notice that something is out of date so,
now you might continue by clicking 'edit' (upper right corner of page)
and make the correction.

> However,  it seems that creating current content took about 3 years.

I think a lot of this content is of out of date and no longer
interesting. I would prefer to place the emphasis on generating new
content and updating the old (if still relevant).

>  I would expect that proofreading the site will take month or two and
> proofreaders will be slowed down by the need to copy things --
> I am not saying that proofreading itself takes a lot of time,
> but simply that our volunteers are in general busy, and can spend
> only a short time doing this.
>

What is the purpose of proof-reading? Keep in mind that this is a
*wiki* web site. The content can be edited by anyone at any time and
this use is strongly *encouraged*. Editing and extending the content
is an ongoing process.

> During that time the new site will be more or less broken, so many
> users will try to use the old site -- since only old site will
> be "complete".

A wiki web site is never "complete". It is there to be changed,
updated and extended as time and motivation allow.

> Similarly links will continue to point to the old site.  Another problem
> is that users may come to the old place and add content there --
> migrating additions will cause extra trouble.
>

We can easily disable updates to the old site and direct the user to
the new site in the resulting error message page.

> I would suggest to migrate content as much as possible in automatic
> way.

Because of the change in the underlying software I do not know any
easy way to accomplish this sort of automatic migration for the Axiom
wiki site. I have already done as much automatic migration to the
Axiom portal site as possible using the ZSyncer tool. If you have some
ideas about how to do more automatic migration I would be very
interested in this.

> Once the new site is fully functional I would made first
> stage of transition:

I do not know what you mean by "fully functional" except if you refer
to content as we discussed above. Other than that, I think the new
site is (almost) fully functional as a wiki and as a portal. The only
missing part right now that I know about as I mentioned in my previous
email is support for Aldor.

> -- put prominent notice about new site on the front page of
>    the old site

That is done now.

> -- change old site to read-only and display notice about new
>    site on any attempt to edit

I can do that today if everyone agrees that is the right approach.

> -- redirect all links to the new site.
>

I think this would be inconvenient. The old site must remain
accessible for some period of to allow content to be transferred.

> In the next stage (two weeks or maybe month later) I would replace
> all pages on the old site by a notice about move and link to
> the corresponding page on the new site.  I would handle updates
> to the content separately.
>

I do not think we have the luxury of spending this much time and using
this sort of more structured approach.

> Rationalle: without proper action users will continue to come
> to the old site: it shows in search engines, it is in bookmarks,
> there are links to it.  The first stage is intended to shift
> critical mass of links and users to the new site.  To avoid loosing
> users old site should be operational.

I do not know what is the required "critical mass" of links or users.
So far as I can see we have never reached this "critical mass" stage
in either links or users yet even on the old site.

> Making old site read-only should avoid problems with
> synchronization.

Yes, but I do not expect the sites to every be anything except
approximately synchronized.

> Redirecting links should help with search engines and
> bookmarks -- search engines should notice new site, new
> bookmarks to links will point to the new site.
>

I think eventually redirecting links is definitely a good idea once
the old site is no longer accessible at all. In fact I can tell from
the web logs of the new site that the search engines have already
noticed and started to crawl the new site. They are very agressive
these days.

> Concerning update of content: the move may cause some loss of
> users.  Operating both sites in paralell is intended to minimize
> user loss.  However, it is essential that new site is fully
> operational -- otherwise users will go to the old site or we may
> loose them.  IMHO trying to update content during migration
> slows down migration and causes extra work.
>

As I explained above, I think that this is quite normal for a wiki-based site.

> ...
> FriCAS also has a bug tracker at SourceForge.  As a person reading
> bug reports I find bugzilla format preferable compared to current
> IssueTracker format.

Of course I have no problem if you chose that as the preferred method
of reporting bugs for FriCAS.

>  More precisely:
> -- bugzilla is more restrictive when comes to edits, for example
>    for normal users is append-only and does not allow unautorized
>    changes to metadata (bug classification)

Why do you think that is important? Do you expect such changes?

> -- IssueTracker shows Axiom output as images which is unsearchable,
>    does not work on text terminal and may hide some important
>    information
>

If desired Axiom output can be displayed in text form by including the commands:

)set output tex off
)set output algebra on

But I do not understand why you would wish to use a "text terminal".

>
> However, I feel that access to old reports is important, so I certainly
> would like to see old reports at the new site.
>

Agreed but transferring them is a problem.

> I belive that common bug tracker for all Axiom forks would be good.
> In the past Tim said that he does not want FriCAS bugs in Axiom bug
> tracker, so FriCAS bug tracker was created.  Certainly, common
> bug tracker make sense only if one can restrict view so that
> only bugs reported against given fork are visible.  Technically,
> this should be not a problem...
>

There are many good alternatives when it comes to bug tracking. For
example the Sage project is using the Trac system.

http://trac.edgewall.org

that includes it's own integrated wiki and interface to subversion.

Do you think we should try to operate something like this as a common
bug tracker for all the Axiom versions/forks?

\start
Date: Sat, 3 Nov 2007 18:27:22 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Re: Axiom Wiki and Portal are moving
Cc: William Stein

Bill Page wrote:
> 
> On 11/1/07, Waldek Hebisch wrote:
> >
> > Bill, I must admit that I have doubts concerning your migration
> > tactic. 
> Waldek, I very much appreciate your taking the time to comment. I also
> have doubts as I will explain below. But I would state my own goals
> with respect to the migration somewhat differently:
> 
>  Primary goal 1: Support all versions/forks of Axiom at one website
>  Primary goal 2: Reduce the operating costs of the axiom-developer.org website
>  Secondary goal 1: update software
>  Secondary goal 2: migrate critical and selected content
> 
> The first three goals are well served by re-installing the web
> applications at another site.
> Notice I do not mention either updating content or migrating users.
> 
> > As you wrote: Axiom wiki is a comunity site, so migrating users
> > to the new site is crucial.  But to migrate users it is
> > essential to migrate content.  I took quick look at the new site
> > and I see that a large part (most??) of content is missing
> > -- for example most links on AxiomContributions page does not work
> > and many positions from the page on the old site are missing.
> >
> 
> I think we should be quite honest: There are very few users. Only
> about 3 or 4 people have ever made any effort to actually use the web
> site in the way it was intended - as a wiki, a community maintained
> web site. I do not think there will be any problem convincing these
> same people to continue to contribute to the new site.
> 
> On the other hand, from the log statistics we can see that the Axiom
> wiki website does have quite a large number of visits by people who
> want only to read something about Axiom and is also very actively
> crawled by the major search engines. From my point of view, I think
> the partial content that I have already copied from the old site to
> the new is sufficient to sustain this sort of use of the site.
>

We are using different terminology here: for me people visiting the
site are users.  But I do not want discuss names here.  For me
important point of wiki is that content may be viewed by large
number of visitors.  And I belive that you want visitors to go
to the new site.

 
> > IIUC you propose to transfer rest of the content via cutting-and-pasting
> > from the old site.  I think this is problematic: without proofreading
> > almost any automatic procedure will work better.  You probably hope
> > that volunteers will proofread the content while copying.
> 
> I do not understand your comment about proofreading.

You wrote about obsolete pages: to find out if a page is obsolete
you need to read it.  And my impression is that 100% obsolete
pages are rare, rather part of a page is obsolete.  So to
eliminate obsolete pages and/or improve content you need
proofreading.

However below you explain that you just want mechanical copy...

> I suspect that
> probably my reference to cut-and-paste was not very clear and that you
> probably are not very familiar with how the content of the Axiom is
> created and maintained. Cut-and-paste is simple. It involves only a
> few steps and the entire content of a page is transferred and
> re-created in essential one step by clicking Save.
> 
> Here is what I was hoping that you would do:
> 
> When you looked at the AxiomContributions page and noticed that some
> apparently useful content was missing you could have added it with
> less than 30 seconds effort. For example in detail:
> 
> 1) At the new site
> 
>    http://axiom-wiki.newsynthesis.org/AxiomContributions
> 
> 2) You see
> 
>   [CommonDenominator for polynomials]?
> 
>   where you would like to see a link to this web page that existed on
> the old site.
> 
> 3) Click on the blue ? to begin (re-)creating the page.
> 
> 4) Open the source for this page at the old site in a separate browser window
> 
>   http://wiki.axiom-developer.org/CommonDenominatorForPolynomials/src
> 
>   Notice /src at the end of the url and also the rule of removing
> blanks and capitalizing the first letter of each word.
> 

OK, so we have easy way to grab sources of all pages from the old
site.

> 5) Click Edit/Select All, Edit/Copy
> 
> 6) Place the cursor in textbox in the page creation form and click
> Edit/Paste to move the enter text of the page
> 
> 7) Click the 'Create' button to render the new page. The link on the
> AxiomContributions has been automatically updated.
> 

This sound like work for Perl WW::Mechanize module.  However, since
you have direct access to the machine there should be easier way
to submit pages.  Note: I never used Mechanize module.  Since
I may need it for other purposes I am willing to try mass upload
using it (assuming you have no easier way).

> > During that time the new site will be more or less broken, so many
> > users will try to use the old site -- since only old site will
> > be "complete".
> 
> A wiki web site is never "complete". It is there to be changed,
> updated and extended as time and motivation allow.
>

Yesterday contents page of the new site contained 74 positions,
while contens page of old site had 913 positions -- that is large
difference.
 
> > Similarly links will continue to point to the old site.  Another problem
> > is that users may come to the old place and add content there --
> > migrating additions will cause extra trouble.
> >
> 
> We can easily disable updates to the old site and direct the user to
> the new site in the resulting error message page.
> 
> > I would suggest to migrate content as much as possible in automatic
> > way.
> 
> Because of the change in the underlying software I do not know any
> easy way to accomplish this sort of automatic migration for the Axiom
> wiki site. I have already done as much automatic migration to the
> Axiom portal site as possible using the ZSyncer tool. If you have some
> ideas about how to do more automatic migration I would be very
> interested in this.
>

I have no experience with Zwiki.  But I would be very disappointed if
Zwiki does not allow easy batch import from external source.

> > Once the new site is fully functional I would made first
> > stage of transition:
> 
> I do not know what you mean by "fully functional" except if you refer
> to content as we discussed above.

Yes.

> >  More precisely:
> > -- bugzilla is more restrictive when comes to edits, for example
> >    for normal users is append-only and does not allow unautorized
> >    changes to metadata (bug classification)
> 
> Why do you think that is important? Do you expect such changes?
>

I think it is important to store _exactly_ the report: frequently
little details does not mater, but sometimes give very important
clue.  I saw report which looked like somebody later edited them
and reports were it was hard to distinguish what original reporter
wrote and what later folks added.  Which means that in _all_
cases there is danger that report was changed.  I guess one can
trace history of the page to check this, but it seems much
simpler to use append-only mode.
 
Concering metadata: there is a lot of bogus metadata in current
IssueTracker.  Part may be due to simple errors, but it seems
that wandals frequently change metadata.  I would say that
anuthorised people have no business changing metadata and
that maintaining metadata is less work than correctiong wrong
changes. 

> > -- IssueTracker shows Axiom output as images which is unsearchable,
> >    does not work on text terminal and may hide some important
> >    information
> >
> 
> If desired Axiom output can be displayed in text form by including the commands:
> 
> )set output tex off
> )set output algebra on
> 

But that means that I would have to edit original report.  Beside
extra effort I would like to keep original report "as is".

BTW:  I _definitely_ prefer to store output of orignal report to
recreating it on page change.  Note that storing output avoids
all tricky issues with changing versions.

> But I do not understand why you would wish to use a "text terminal".
> 

I _use_ "text terminal" -- that is just personal preference.

> > I belive that common bug tracker for all Axiom forks would be good.
> > In the past Tim said that he does not want FriCAS bugs in Axiom bug
> > tracker, so FriCAS bug tracker was created.  Certainly, common
> > bug tracker make sense only if one can restrict view so that
> > only bugs reported against given fork are visible.  Technically,
> > this should be not a problem...
> >
> 
> There are many good alternatives when it comes to bug tracking. For
> example the Sage project is using the Trac system.
> 
> http://trac.edgewall.org
> 
> that includes it's own integrated wiki and interface to subversion.
> 
> Do you think we should try to operate something like this as a common
> bug tracker for all the Axiom versions/forks?
> 

I have no experience with Trac.  I really have no strong preference
for specific software.  I mentioned Bugzilla because it is known
and works "good enough".  I belive that changing IssueTracker in
specific aspect I mentioned would not be very hard.  So, now
it is mostly question what other versions want.

\start
Date: 05 Nov 2007 10:06:09 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: Axiom Wiki and Portal are moving

Dear Bill, *

a short answer, since I'm rather busy...

> > fixed in Axiom
> > fixed in FriCAS
> > fixed in OpenAxiom

> That is a good suggestion. I think we can easily implement that.

 [...]

> I propose the following syntax:
> 
>   \begin{axiom}[open-axiom]
>   ...
>   \end{axiom}
> 
> Perhaps we could also support some standard versions, e.g.
> 
>   \begin{axiom}[fricas,1.1]
>   ...
>   \end{axiom}
> 
> Here [...] is an optional parameter. {axiom} by itself would refer to one of
> the three versions of axiom (no guarantee which one).  {axiom}[open-axiom]
> would refer to the most recently installed version of open-axiom, etc.

great!

> The problem with the usual "cut-and-paste" method is that I have not found
> any way to transfer the status and classification field information. Only the
> text content of the page is visible. Of course it would be possible to set
> the fields later, but we are talking about nearly 300 pages.

I think that would not be too bad, since status is already slightly outdated
for some bugs and some flavours of axiom, and the classification scheme could
maybe be simplified.

> An alternative that I haven't checked is using "External Edit". I do
> not have the external edit feature enabled on my workstation so I
> cannot easily check. Martin, I think you do use this right? 

Not anymore, sorry.

Apart from that, I strongly support Waldek's view of making a more or less
identical copy first, and polish later - time and interest permitting.

Also, I would very much like to see the old wiki read only meanwhile.

I won't have any time for serious axiom stuff for a while.  And even then, I'd
prefer to work on the species project.  But the wiki cannot wait for such a
long time, it is used by too many people!

A final suggestion: would it be possible to map

    http://axiom-wiki.newsynthesis.org

to

    http://axiom.newsynthesis.org

I need short names for the next axiom workshop :-)

\start
Date: Mon, 5 Nov 2007 10:38:30 -0400
From: Bill Page
To: Martin Rubey
Subject: Re: Axiom Wiki and Portal are moving

On 05 Nov 2007 10:06:09 +0100, Martin Rubey wrote:
> Dear Bill, *
>
> a short answer, since I'm rather busy...
>

Busy is good. :-)

> >
> > Perhaps we could also support some standard versions, e.g.
> >
> >   \begin{axiom}[fricas,1.1]
> >   ...
> >   \end{axiom}
> >
> > Here [...] is an optional parameter. {axiom} by itself would refer to
> > one of the three versions of axiom (no guarantee which one).
> >  {axiom}[open-axiom] would refer to the most recently installed
> > version of open-axiom, etc.
>
> great!
>

Ok, but it will take me some time to get around to implementing this.

> > The problem with the usual "cut-and-paste" method is that I have not
> > found any way to transfer the status and classification field information.
> > Only the text content of the page is visible. Of course it would be
> > possible to set the fields later, but we are talking about nearly 300
> > pages.
>
> I think that would not be too bad, since status is already slightly outdated
> for some bugs and some flavours of axiom, and the classification scheme
> could maybe be simplified.

I think that is true. The trouble of course is that we apparently do
not have anyone with enough time and interest to actually do the
checking of the status and copying of the details.

>
> > An alternative that I haven't checked is using "External Edit". I do
> > not have the external edit feature enabled on my workstation so I
> > cannot easily check. Martin, I think you do use this right?
>
> Not anymore, sorry.
>
> Apart from that, I strongly support Waldek's view of making a more
> or less identical copy first, and polish later - time and interest
> permitting.
>

I would have made an identical copy if it had been easy and did not
conflict with the desire to upgrade the software. I considered that
the software upgrade had to have priority because the newer version of
ZWiki is much more spam-resistant than the old one, plus now that we
are up-to-date with a standard version of ZWiki without any serious
customization, it will be easily remain current.

I still have not heard any convincing reason from either you or Waldek
why you think copy the entire contents of the old site is important.
As for "polishing later", given the past history of this web site and
the number and kind of past contributions I am quite certain that
later would equate with never in this case. :-( It seems that no one
has either the time or the interest even to copy a few selected pages.

Given that almost all of the visitors to the site are there only to
read about Axiom, I think the quality of the pages is of much greater
importance than the quantity.

Also although I would not want to presume on how he should spend his
time on Axiom, I think it would be a serious waste of Waldek's time to
hack together a Perl script just to do a dumb-and-blind copy of the
old contents to the new. Since the entire application is written in
Python, if any new code was to be written for this purpuse it would
make better sense to actually use Python. Further, there already is a
very good program (ZSyncer) whose sole purpose is to make it easy to
keep two or more websites in synchronized by copying pages in both
directions as needed. (We used this program to keep the axiom.risc
site synchronized with the axiom-developer site before the computer at
Risc had to be re-built.) Unfortunately this program is not capable of
dealing with the change in the page type metadata between the old and
new ZWiki versions. *If* I was motivated to try to copying everything
from the old to new sites, then I would probably devote the effort to
solving this problem by modifying ZSyncer.

> Also, I would very much like to see the old wiki read only meanwhile.
>

I'll make this change now, but of course the rate of change of the
site is very very low in any case.

> I won't have any time for serious axiom stuff for a while.  And even then,
> I'd prefer to work on the species project.  But the wiki cannot wait for such
> a long time, it is used by too many people!
>

I guess that is a problem. I also do not have enough time and would
now prefer to use the time I do have available for Axiom actually
using Axiom for my research. We badly need someone new to come along
who has some interested in the web sites.

> A final suggestion: would it be possible to map
>
>     http://axiom-wiki.newsynthesis.org
>
> to
>
>     http://axiom.newsynthesis.org
>
> I need short names for the next axiom workshop :-)
>

The url

  http://axiom.newsynthesis.org

already exists and points to a provisional site-summary page with
links to both axiom-wiki and axiom-portal as well as the main pages
for the forks of Axiom. Rather than making 'axiom.newsythesis.org'
point to the same place as 'axiom-wiki' I would be happy for
suggestions on how to improve this page.

About the next axiom workshop: Is there anything planned to coincide
with the upcoming ISSAC meeting (July 2008?) at Risc? At the last
Aldor workshop there were some tentative plans to schedule the next
Aldor workshop to occur at this time and place. I will be coming to
this meeting if at all possible, so perhaps we will finally meet in
person. :-)

\start
Date: Mon, 5 Nov 2007 12:31:18 -0400
From: Bill Page
To: Tim Daly
Subject: Re: wiki.axiom-developer.org

On 11/1/07, Tim Daly wrote:
> ...
> In the interest of keeping things running we can point the names
> you need to the new server location and continue to use
> wiki.axiom-developer.org and portal.axiom-developer.org.
> Feel free to change the httpd.conf file to forward-point.
> Thus Martin's references should continue to function.
>

Ok, I can do that in the near future. It is probably possible to do
this without involving the Apache configuration files by making a
CNAME entry in the DNS server for the 'axiom-developer.org' domain. If
you would rather do that and no longer have the server involved at
all, just let me know. To make a CNAME entry you would need to contact
whoever sold you the 'axiom-developer.org' domain name.

As we have discussed on this list, not all of the pages have been
copied from the old site to the new. Personally I do not think this is
a problem but both Waldek and Martin have argued that all existing
pages should be copied. We have not determined who (if anyone) is
actually prepared to do the work to make this happen. So I guess at
some point we should just decide to "pull the plug" and the issue will
be gone...

> The server costs have been rising due to the huge data loads on the
> machine. I need to reduce that monthly outlay so I plan to strip most
> of the non-essential data. Most of the data costs are associated with
> the wiki, the portal, and your home directory.

I certainly understand your desire to reduce the operating costs but I
think that it is no longer true that most of the costs are associated
with the wiki, portal and the '/home/page' directory. I have
eliminated everything from the server that is not absolutely necessary
to continue normal operation of the wiki and portal applications and
now the usage is significantly less than other projects on the server
as the following commands show:

  du -s -k /home/* | sort -n
  du -s -k /var/zope | sort -n

> It is costing me several thousand dollars a year to maintain that server
> at the present time and the costs have risen every month. At the
> current rate of rise the server will cost me about $5000./yr within a
> year. I need to reduce this cost considerably.

I hope my lastest effort to clean things up has helped reduce the
cost. I also found a lot of unnecessary wasted space in the /tmp
directory that seemed related to the operation of the wiki site. The
'df' command now shows total disk utilization at 48% of the available
storage. I am not sure whether you pay for actual usage or for
maintaining the total available figure. If it is the latter, then
perhaps you should contact the company that operates the server and
ask that the total available be reduced.

I do not have any plans to do anything on this server that will
increase the storage requirement. When you decide that it is necessary
to completely eliminate the wiki and portal applications from the
server that will free another 4.2 Gbytes of storage.

> Thus, I've asked you to find another server and William Stein has
> been kind enough to host your effort.
>

No problem. Nothing lasts for ever. Thanks for providing the
opportunity for me to contribute to Axiom in this way for the last 3
years.

\start
Date: Mon, 05 Nov 2007 18:01:01 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom Wiki and Portal are moving

> About the next axiom workshop: Is there anything planned to coincide 
> with the upcoming ISSAC meeting (July 2008?) at Risc?

No, not coinciding. But there are plans to have a

   Aldor & Axiom Workshop 2008

during the RISC-Summer at July 24-26, i.e. right after ISSAC.

\start
Date: Mon, 5 Nov 2007 12:19:58 -0500
From: Alfredo Portes
To: Bill Page
Subject: re: wiki.axiom-developer.org

> I certainly understand your desire to reduce the operating costs but I
> think that it is no longer true that most of the costs are associated
> with the wiki, portal and the '/home/page' directory. I have
> eliminated everything from the server that is not absolutely necessary
> to continue normal operation of the wiki and portal applications and
> now the usage is significantly less than other projects on the server
> as the following commands show:
>
>   du -s -k /home/* | sort -n
>   du -s -k /var/zope | sort -n

I have deleted old iso files of Doyen, and left just the most recent
one together
with some of the packages necessary to build it. The iso is 686 M and the total
for the /home/alfredo directory is now: 823 M.

\start
Date: 12 Nov 2007 08:23:32 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: wiki.axiom-developer.org

It seems that the old wiki is down.  Did we loose IssueTracker now?

\start
Date: Mon, 12 Nov 2007 07:24:12 -0500
From: Bill Page
To: Martin Rubey
Subject: Re: wiki.axiom-developer.org

There is some problem right now (cause unknown) with Apache on the
axiom-developer.org server. But the wiki itself is not down. You can
access it directly via:

http://axiom-developer.org:8080/mathaction

I'll try to get some time later today to find the problem with Apache.

Regards,
Bill Page.

On 12 Nov 2007 08:23:32 +0100, Martin Rubey wrote:
> It seems that the old wiki is down.  Did we loose IssueTracker now?
>
> Martin

\start
Date: Fri, 16 Nov 2007 22:48:16 -0500
From: Tim Daly
To: Alfredo Portes, Arthur Ralfs
Subject: newhyper.pamphlet

A new version of newhyper.pamphlet is checked in.
It implements rootpage -> topics -> numbers -> Cardinal Numbers

\start
Date: Sat, 17 Nov 2007 20:40:01 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: bug 7014: mathml parsing bug

)set out mathml on
z:=continuedFraction(3,repeating [1], repeating [3,6])

gives the correct answer and then fails with:

 >> System error:
 Cannot take first of an empty list

\start
Date: Sat, 17 Nov 2007 22:13:22 -0800
From: Arthur Ralfs
To: Tim Daly
Subject: Re: bug 7014: mathml parsing bug

Tim Daly wrote:
> Arthur,
>
> )set out mathml on
> z:=continuedFraction(3,repeating [1], repeating [3,6])
>
> gives the correct answer and then fails with:
>
>  >> System error:
>  Cannot take first of an empty list
>
> Tim
>
>   
Thanks Tim, I'll look into that as soon as I can, which unfortunately
will not be right away.

\start
Date: Sun, 18 Nov 2007 14:59:03 -0600
From: Tim Daly
To: list
Subject: AMS Notices: Open Source Mathematical Software
Cc: William Stein, David Joyner, Paul Zimmermann

David Joyner and William Stein published an opinion piece in the
AMS Notices raising (yet again) the issue of mathematical results
that depend on closed source symbolic mathematics. They would like
to see open source efforts funded.
<http://www.ams.org/notices/200710/tx071001279.pdf>

They raise the issue (raised here many times in the past) about 
funding open source mathematical software. SAGE is a university
based project and has a funding model that NSF recognizes. Axiom
and other projects don't fit any model and neither the NSF nor
INRIA is able (as far as I know from direct discussions) to 
consider funding open source projects like Axiom, which are not
supported by standard institutions, such as Universities.

My direct discussions with the NSF, on several occasions, raises the
point that the NSF claims that it does not fund projects which compete
with commercial software. This position is frustrating on several points.

First, the NSF funds the purchase of commercial software at universities.
Thus they explicity fund software that competes with open source. 

Second, (as I understand it) SAGE is an effort to create an open source
competitor to the current closed source systems. I applaud their efforts
and think this is very valuable. However, I'm not sure how much funding
they can get from the NSF with such commercially-competitive goals.

Third, even if the NSF funded SAGE, how would those funds benefit the
various subprojects like Axiom? Open source is mostly volunteer work
done in "spare time". While it is amusing to daydream of being paid to
develop open source computational mathematics on a full time basis, it
seems unlikely that this could lead to more than just small
grants. The expertise and continuity needed to do research work
requires longer term funding.

Fourth, most of the work on open source projects like Axiom is 
multi-national. I don't see that INRIA and NSF have a joint-funding
model. How could a project like Axiom give grants to people in France
out of NSF funds (or INRIA-funded U.S. workers)? In my experience,
this usually involved "visiting scientist" arrangements but open
source has no place to visit besides a website.

Fifth, Axiom is NOT intended to compete with software like Mathematica
or Maple. Axiom's goals are long term scientific research ideas, such
as proving the algorithms correct, documenting the algorithms, following
a strong mathematical basis for the structure of the algebra hierarchy,
etc. None of these goals compete with MMA or Maple. The NSF is intended
to fund this kinds of scientific research but apparently cannot.

Sixth, computational mathematics, which currently rests on closed
source commercial efforts, will eventually suffer from a massive
"black hole" once the current software dies. Suppose Wolfram Research
and Maplesoft go out of business. That might seem unlikely but there
are very few companies that last more than 50 years. Since software is
now considered an asset it cannot be simply given away. (Even if the
software was opened-sourced it is poorly documented according to
people who know the source).  We could have the situation like
Macsyma, where the company folded and the source code is never
released. Is this what the NSF sees as the correct long term basis for
a fundamental science like computational mathematics?

Seventh, if not funding the work directly, isn't it possible to at least
fund things like an 'Axiom workshop' so that open source developers could
have their travel and lodging paid for by grants? Face-to-face meetings
would greatly help the development work.

I could go on but I will stop here. 

Axiom is basic science and has long term plans to be the foundation
of open, provably correct, computational mathematics. Sadly, I feel
that funding is only likely after the fact. Oh well. The work continues.

\start
Date: Sun, 18 Nov 2007 15:01:51 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: bug 7015: display of hex digits is wrong in mathml

Arthur,

hex(10) shows up as 
  A
in axiom but shows up as
  #\A
in mathml.

\start
Date: Sun, 18 Nov 2007 13:32:03 -0800
From: William Stein
To: Tim Daly
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

On Nov 18, 2007 12:59 PM,  Tim Daly wrote:
> David Joyner and William Stein published an opinion piece in the
> AMS Notices raising (yet again) the issue of mathematical results
> that depend on closed source symbolic mathematics. They would like
> to see open source efforts funded.
> <http://www.ams.org/notices/200710/tx071001279.pdf>

Hi, thanks for reading our short opinion and pointing out our opinion
piece on axiom-developer for discussion, and thanks even more for
formulating your thoughts about it.

> They raise the issue (raised here many times in the past) about
> funding open source mathematical software. SAGE is a university
> based project and has a funding model that NSF recognizes. Axiom
> and other projects don't fit any model and neither the NSF nor
> INRIA is able (as far as I know from direct discussions) to
> consider funding open source projects like Axiom, which are not
> supported by standard institutions, such as Universities.
>
> My direct discussions with the NSF, on several occasions, raises the
> point that the NSF claims that it does not fund projects which compete
> with commercial software. This position is frustrating on several points.

It's tricky how Sage gets any funding from NSF.  I've spent countless painful
hours writing the applications -- some of which were rejected -- and some
that have got some funding, so maybe I'll comment.
To date NSF funding for Sage has meant:

    * specific funding to get undergraduates involved in research with
       faculty, which just happens to involve using and improving sage,
    * hardware -- the sage.math.washington.edu computer, whose primary
      purpose is research, but which also gets used a lot by sage developers,
    * conference and workshop support.
    * a 50% postdoc -- Clement Pernet.

The postdoc is by far the single biggest chunk of funding for Sage
from the NSF.  This, as you say, fits very much into the academic
context.  What made hiring him palatable to NSF is that Clement Pernet
is doing very interesting cutting edge work on exact linear algebra
and publishes papers about this.  Thus hiring him supports the NSF
mission in fundamental research.  It just happens he will also do work
that will improve Sage as well.  So far NSF has never given us blanket
money "for Sage", yet.  I wish they would, but I don't really see that
as being likely.  Much more likely is that they fund specific research
projects, which have improving open source mathematical software as a
pleasant side effect.  More examples below.

It's worth mentioning that NSF has funded Macaulay2 a lot over the years...

By the way, I was recently at an NSF workshop, and I got the strong
impression that NSF doesn't really "like" funding the purchases of
commercial software very much.  Also, some NSF programs will in
practice actually reject proposals that say they won't publish the
software that comes out of their work as open source... I had the
impression that there is a new sort of grass roots movement by actual
mathematicians that advise NSF toward supporting open source.  This
was very surprising to me, but it's actually what appears to be
happening, very slowly but surely.  This is good news for us.

> First, the NSF funds the purchase of commercial software at universities.
> Thus they explicity fund software that competes with open source.
>
> Second, (as I understand it) SAGE is an effort to create an open source
> competitor to the current closed source systems.

You are correct.  That is our primary goal, though I much prefer the word
"alternative" to "competitor": "provide a viable alternative to Ma*..."

> I applaud their efforts
> and think this is very valuable. However, I'm not sure how much funding
> they can get from the NSF with such commercially-competitive goals.

I think we can get a drop in the bucket, but it is an important one.
It will take other funding sources besides NSF, or funding other
projects that just happen to have a positive impact on open source
software, to really accomplish what we want.  For example, I recently
applied with several people for a big "FRG" (focused research grant)
on L-functions and modular forms -- if it were funded it would advance
number theory research, but it would also have as a side effect
advancing open source mathematical software.  And there are other
funding source, e.g., tax-free donations, which do help, and have
directly benefited sage already.

> Third, even if the NSF funded SAGE, how would those funds benefit the
> various subprojects like Axiom? Open source is mostly volunteer work
> done in "spare time". While it is amusing to daydream of being paid to
> develop open source computational mathematics on a full time basis, it
> seems unlikely that this could lead to more than just small
> grants. The expertise and continuity needed to do research work
> requires longer term funding.

Great questions and comments.  There aren't easy answers.
One possibility is selling "support"... which could bring in
money to support people who are out of country.

> Fourth, most of the work on open source projects like Axiom is
> multi-national. I don't see that INRIA and NSF have a joint-funding
> model. How could a project like Axiom give grants to people in France
> out of NSF funds (or INRIA-funded U.S. workers)? In my experience,
> this usually involved "visiting scientist" arrangements but open
> source has no place to visit besides a website.

Indeed, I absolutely can't use my NSF funds (for Sage) to pay people in Europe.
This has caused some frustration, but it's the way it is.

> Fifth, Axiom is NOT intended to compete with software like Mathematica
> or Maple. Axiom's goals are long term scientific research ideas, such
> as proving the algorithms correct, documenting the algorithms, following
> a strong mathematical basis for the structure of the algebra hierarchy,
> etc. None of these goals compete with MMA or Maple. The NSF is intended
> to fund this kinds of scientific research but apparently cannot.

It's good that the Axiom goals are so nicely complementary to Sage's goals,
instead of competing with them.

> Sixth, computational mathematics, which currently rests on closed
> source commercial efforts, will eventually suffer from a massive
> "black hole" once the current software dies. Suppose Wolfram Research
> and Maplesoft go out of business. That might seem unlikely but there
> are very few companies that last more than 50 years. Since software is
> now considered an asset it cannot be simply given away. (Even if the
> software was opened-sourced it is poorly documented according to
> people who know the source).  We could have the situation like
> Macsyma, where the company folded and the source code is never
> released. Is this what the NSF sees as the correct long term basis for
> a fundamental science like computational mathematics?

I think you're right to be worried about exactly these things.  Some
people in my research area (number theory / arithmetic geometry) are
worried about this right now in the context of Magma, whose longterm
future is hazy at present.  There are actually many examples like this
already, e.g., Mupad doesn't seem to be doing so well commercially,
and maybe researchers who have written a lot of mupad code aren't so
happy about this...

> Seventh, if not funding the work directly, isn't it possible to at least
> fund things like an 'Axiom workshop' so that open source developers could
> have their travel and lodging paid for by grants? Face-to-face meetings
> would greatly help the development work.

Workshops are a great thing to fund.  Particularly good is choosing a
specific research topic and doing the workshop on that.  E.g., I think
there was an Axiom Combinatorics workshop last summer, which is good.
IPAM (which is funded by NSF) is hosting a Sage Combinatorics workshop
in February, which they are funding.

\start
Date: Sun, 18 Nov 2007 18:49:16 -0500
From: Tim Daly
To: William Stein
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

William,

One possible other source for funding is NIST (although the year that
I thought to apply they only had funding for prior project, no new
money available). 

An outstanding problem is that we have many different computer algebra
and symbolic computation systems that compute different answers to the
same problem. Sometimes these answers are equivalent but it takes a
great deal of work to show that.

I've advocated, and done some work on, CATS (computer algebra test
suite). The idea is to categorize (similar to the NIST numeric math
classification) and standardize a set of symbolic problems and their
mathematical solutions. These problems would be chosen to highlight
behavior (e.g. branch cuts, simplifications, boundary conditions) in a
class of problems. Each system could then provide solutions to this
standard set. Thus there would be the beginnings of the idea that you
could expect the same results (within simplification) on any of the
available systems. In the ideal case such tests would also document
the algorithm(s) that solves the problem.

NIST seems to me to be the ideal funding source for such a suite.

Note that the test suite is applicable to both open source and
commercial efforts. 

In particular, since SAGE has many daughter systems it seems that 
you are in the ideal position to build a catalog of such tests.
The test problems would all provide hand-solved answers as well
as the results from each daughter subsystem.

Further, since each area of classification would require an expert
to propose and document the problems it seems to be the ideal 
project for widespread grant-based funding.

The end result would be an Abramowitz & Stegun style document that
was machine readable and freely available. Each project (e.g. MMA,
Maple, Axiom, etc) would post their results. 

Axiom has groups of such tests in its regression test suite already.

\start
Date: Sun, 18 Nov 2007 18:51:08 -0500
From: Tim Daly
To: Paul Zimmermann
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: William Stein, David Joyner

>> Third, even if the NSF funded SAGE, how would those funds benefit the
>> various subprojects like Axiom?
>
>let me give my opinion on that specific point. As a developer of two
>"subprojects" used by SAGE, I can say that the SAGE developers do a
>tremendous work in porting, testing, reporting bugs and even patches
>to "upstream" developers. This saves a lot of time to the subproject
>developers, and helps a lot in improving the quality of those subprojects.

While I agree that participation in Sage is a good idea and a source
of testing, I was asking about how the funding of Sage would benefit
projects like Axiom? How might we pay a developer to expand on 
symbolic summation code?

\start
Date: Sun, 18 Nov 2007 14:53:20 -0800
From: William Stein
To: Tim Daly
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

On Nov 18, 2007 3:49 PM, Tim Daly wrote:
> One possible other source for funding is NIST (although the year that
> I thought to apply they only had funding for prior project, no new
> money available).
>
> An outstanding problem is that we have many different computer algebra
> and symbolic computation systems that compute different answers to the
> same problem. Sometimes these answers are equivalent but it takes a
> great deal of work to show that.
>
> I've advocated, and done some work on, CATS (computer algebra test
> suite). The idea is to categorize (similar to the NIST numeric math
> classification) and standardize a set of symbolic problems and their
> mathematical solutions. These problems would be chosen to highlight
> behavior (e.g. branch cuts, simplifications, boundary conditions) in a
> class of problems. Each system could then provide solutions to this
> standard set. Thus there would be the beginnings of the idea that you
> could expect the same results (within simplification) on any of the
> available systems. In the ideal case such tests would also document
> the algorithm(s) that solves the problem.
>
> NIST seems to me to be the ideal funding source for such a suite.
>
> Note that the test suite is applicable to both open source and
> commercial efforts.
>
> In particular, since SAGE has many daughter systems it seems that
> you are in the ideal position to build a catalog of such tests.
> The test problems would all provide hand-solved answers as well
> as the results from each daughter subsystem.
>
> Further, since each area of classification would require an expert
> to propose and document the problems it seems to be the ideal
> project for widespread grant-based funding.
>
> The end result would be an Abramowitz & Stegun style document that
> was machine readable and freely available. Each project (e.g. MMA,
> Maple, Axiom, etc) would post their results.

Actually NIST already has been working on an " Abramowitz & Stegun
style document " for the last decade.  I had a long talk on Friday in
my office with the guy who started that effort a decade ago...  It's
actually very exciting, and I do think there is some possibility for
something like you're describing above, maybe more in the context of
the CDI initiative at NSF.

\start
Date: Sun, 18 Nov 2007 19:24:57 -0500
From: Tim Daly
To: William Stein
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann,, David Joyner

William,

>Actually NIST already has been working on an " Abramowitz & Stegun
>style document "
>for the last decade.  I had a long talk on Friday in my office with the
>guy who started that effort a decade ago...  It's actually very exciting,
>and I do think there is some possibility for something like you're describing
>above, maybe more in the context of the CDI initiative at NSF.

I'm familiar with the A&S document but it is not properly focused to
work as a reasonable computer algebra test suite (CATS). It does not
categorize problems based on their computational math aspects and it
does not focus on providing branch-cut, boundary cases, etc. that 
would be needed to highlight the behavior of computational math systems. 
Also missing is the textual analysis of the problem and solution.

For example, it would be useful to see a discussion of sine or square
root with regard to branch cuts, simplifications, extended fields,
etc. I've seen discussions of the numeric aspects of computing the
sine in the last decimal place or choice of polynomials but I've not
seen the equivalent discussions with respect to the symbolic aspects
such as simplifications.

In addition, A&S introduces problems that I have no idea how to
solve symbolically. It would be useful to have citations to papers
that provide the underlying algorithms.

A&S might be too ambitious. Perhaps we should think in terms of
Spiegel's (Schaum's Outlines) Mathematical Handbook. Indeed, I've
spent some time with this book in developing the latest Axiom tests
and found mistakes in some of the problem answers from the book.
The analysis is really important.

The fundamental goal would be to ensure that the mathematical
results from various systems (and later releases) at least conform
to some independently verified acceptable standard of results.

Seems like a NIST (or possibly a CDI/NSF) proposal to me.

While I am at Carnegie-Mellon University, I'm not associated with
any group that does computational mathematics so I couldn't justify
such a proposal.

\start
Date: Sun, 18 Nov 2007 18:36:39 -0600
From: Tim Daly
To: list
Subject: David Parnas on Specifications

from <http://dlweinreb.wordpress.com>

David Parnas (Univ of Limerick) is cited by Dan Weinreb as advocating

 He advocates much more precise and specific documentation, kept up
 to date, to the point where if someone asks a question about the
 software, a programmer would go to the documentation rather than
 the code to answer the question. If finally turns out that he wants
 extremely precise specs written in a mathematical notation, ...

Since he's clearly singing my song I wanted to record this comment.
I'd like to see Axiom documented to this level. I think it is vitally
important for the long term survival of the system.

\start
Date: Sun, 18 Nov 2007 17:15:49 -0800
From: Ed Borasky
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

William Stein wrote:
> On Nov 18, 2007 12:59 PM,  Tim Daly wrote:
>> Sixth, computational mathematics, which currently rests on closed
>> source commercial efforts, will eventually suffer from a massive
>> "black hole" once the current software dies. Suppose Wolfram Research
>> and Maplesoft go out of business. That might seem unlikely but there
>> are very few companies that last more than 50 years. Since software is
>> now considered an asset it cannot be simply given away. (Even if the
>> software was opened-sourced it is poorly documented according to
>> people who know the source).  We could have the situation like
>> Macsyma, where the company folded and the source code is never
>> released. Is this what the NSF sees as the correct long term basis for
>> a fundamental science like computational mathematics?
> 
> I think you're right to be worried about exactly these things.    Some people
> in my research area (number theory / arithmetic geometry) are
> worried about this right now in the context of Magma, whose longterm future is
> hazy at present.   There are actually many examples like this already, e.g.,
> Mupad doesn't seem to be doing so well commercially, and maybe
> researchers who have written a lot of mupad code aren't so happy about this...

Another one ... Texas Instruments has discontinued Derive. They do have 
some kind of replacement, but their marketing seems to be only to the 
SAT-prep and educational institution arena, not professional working 
mathematicians. They're actually very close to refusing to sell a 
one-off to someone. I can't say I disagree with their approach -- after 
all, they have stockholders -- but I think there is a real risk to all 
of the closed-source math software.

Then again, the open-source alternatives are certainly "good enough" for 
what I need to do, and the handwriting is on the wall for some closed 
source packages. About all it takes for an open-source package to be 
competitive these days is a "native" (non-Cygwin) Windows port. But I 
don't do the high-end PhD research, either.

\start
Date: Sun, 18 Nov 2007 21:48:59 -0600
From: Tim Daly
To: list
Subject: 20071118.01.tpd.patch

fix [Ring, SetCategory] (7011), [Integer,Float] (7010,209)
=====================================================================
diff --git a/changelog b/changelog
index 74bd7c2..430c68f 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,4 @@
+20071101 tpd src/interp/i-output.boot fix bugs 7010 (209), 7011
 20071019 acr src/interp/http.lisp use new return values
 20071019 acr src/algebra/axserver.spad use new return values
 20071014 acr src/algebra/axserver.spad use getContentType(pathvar)
diff --git a/src/interp/i-output.boot.pamphlet b/src/interp/i-output.boot.pamphlet
index b1066aa..af6ead2 100644
--- a/src/interp/i-output.boot.pamphlet
+++ b/src/interp/i-output.boot.pamphlet
@@ -1389,8 +1389,9 @@ output(expr,domain) ==
       mathprintWithNumber x
     if $texFormat     then texFormat x
     if $mathmlFormat  then mathmlFormat x
-  (FUNCTIONP(opOf domain)) and
-    (printfun := compiledLookup("<<",'(TextWriter TextWriter $), evalDomain domain))
+  (FUNCTIONP(opOf domain)) and (not (SYMBOLP(opOf domain))) and
+    (printfun := _
+      compiledLookup("<<",'(TextWriter TextWriter $), evalDomain domain))
        and (textwrit := compiledLookup("print", '($), TextWriter())) =>
      sayMSGNT [:bright '"AXIOM-XL",'"output:   "]
      SPADCALL(SPADCALL textwrit, expr, printfun)



\start
Date: Mon, 19 Nov 2007 01:35:40 -0500
From: Tim Daly
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, William Stein, David Joyner

I had an offline discussion with management at Texas Instruments
about Derive. I'm concerned that this historically interesting
piece of software is simply going to disappear once TI decides
they no longer want to support the CAS business. 

I have asked them to build a "deadman" clause into the handling of
the Derive source code so it could be released when it was no longer
of interest. 

The lisp source code is no longer used. All work is in C++.

Unfortunately the end result of several months of discussion with TI
was that the request for release and the request for a "deadman"
clause were both refused.

It seems to me that the calculator business will eventually die off.
I have not used a calculator in many years. Given the falling price
and increasing power of PCs, I can't help but believe that the days
of the calculator are numbered. And, like Macsyma on Symbolics
machines, Derive is going to disappear forever.

It looks like we've lost another great CAS to the corporate blackhole.

A similar fate for Mathematica or Maple will leave a huge hole in
computational mathematics worldwide.

\start
Date: Mon, 19 Nov 2007 02:58:52 -0500
From: Tim Daly
To: Casey Cunningham
Subject: Re: 

>    I recently installed fedora 6 and was looking to install AXIOM, to use 
>along with David Cox book on undergraduate algebraic geometry. On your page
> you have a link to Axiom Binary Downloads where you list fedora 6, but thi
>s is a dead page. My first question is if this page is supposed to be opera
>tional? Also, the latest version I can find on sourceforge is for fedora 4.
> Am I alright just installing this version?

I have compiled and uploaded a version of Axiom for fedora5 and fedora6.
The source and binaries are at:
<http://daly.axiom-developer.org/axiombinary/index.html>

Note that these are the silver (latest changes) versions.

The upload is rather slow so give it an hour or so (It is now 2am EST).

\start
Date: Sun, 18 Nov 2007 23:24:35 +0100
From: Paul Zimmermann
To: Tim Daly
Subject: Re: AMS Notices: Open Source Mathematical Software
Cc: William Stein, David Joyner

       Dear Tim,

> Third, even if the NSF funded SAGE, how would those funds benefit the
> various subprojects like Axiom?

let me give my opinion on that specific point. As a developer of two
"subprojects" used by SAGE, I can say that the SAGE developers do a
tremendous work in porting, testing, reporting bugs and even patches
to "upstream" developers. This saves a lot of time to the subproject
developers, and helps a lot in improving the quality of those subprojects.

\start
Date: Tue, 20 Nov 2007 00:27:29 -0600
From: Tim Daly
To: list
Subject: 20071119.01.tpd.patch

This patch adds fedora6, fedora7, and fedora8 stanza.
This is the final patch of the november release

===============================================================
diff --git a/Makefile.pamphlet b/Makefile.pamphlet
index 9579f8f..9603823 100644
--- a/Makefile.pamphlet
+++ b/Makefile.pamphlet
@@ -1343,6 +1343,231 @@ all: rootdirs noweb srcsetup lspdir srcdir
 <<clean>>
 
 @
+\subsection{Makefile.fedora6}
+On Fedora Core 6 we cannot use the line
+\begin{verbatim}
+  ${XLIB}/libXpm.a
+\end{verbatim}
+to link to the Xpm libraries. Instead We need to use
+\begin{verbatim}
+  -l Xpm
+\end{verbatim}
+These are added onto the end of the LDF variable.
+
+Annoyingly enough it seems that GCL uses a default extension of .lsp
+rather than .lisp so we add the [[LISP]] variable here. We need to
+depend on the default extension behavior because the system build
+will load either the interpreted or compiled form of a file depending
+on which is available. This varies at different stages of the build.
+
+It turns out that the standard GCL OPTS does not compile with the
+GCL 2.6.8pre version. We changed it from 
+\begin{verbatim}
+@<<GCLOPTS>>
+\end{verbatim}
+to read
+\begin{verbatim}
+@<<GCLOPTS-LOCBFD>>
+\end{verbatim}
+
+GCL-2.6.8pre2 will not build successfully on fedora core 6
+so we need to downgrade the GCLVERSION.
+<<Makefile.fedora6>>=
+#GCLVERSION=gcl-2.6.8pre
+# System dependent Makefile for the Intel/Linux platform
+# Platform variable
+PLF=LINUXplatform
+# C compiler flags
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+# Loader flags
+LDF=" -L/usr/X11R6/lib -l Xpm "
+# C compiler to use
+CC=gcc 
+AWK=gawk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+# where the libXpm.a library lives
+XLIB=/usr/X11R6/lib
+<<GCLOPTS-LOCBFD>>
+<<SRCDIRS>>
+PATCH=patch
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
+    LISP=${LISP} DAASE=${DAASE} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    SRCDIRS=${SRCDIRS} PATCH=${PATCH}
+
+all: rootdirs noweb srcsetup lspdir srcdir
+	@echo 45 Makefile.linux called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
+\subsection{Makefile.fedora7}
+On Fedora Core 7 we cannot use the line
+\begin{verbatim}
+  ${XLIB}/libXpm.a
+\end{verbatim}
+to link to the Xpm libraries. Instead We need to use
+\begin{verbatim}
+  -l Xpm
+\end{verbatim}
+These are added onto the end of the LDF variable.
+
+Annoyingly enough it seems that GCL uses a default extension of .lsp
+rather than .lisp so we add the [[LISP]] variable here. We need to
+depend on the default extension behavior because the system build
+will load either the interpreted or compiled form of a file depending
+on which is available. This varies at different stages of the build.
+
+It turns out that the standard GCL OPTS does not compile with the
+GCL 2.6.8pre version. We changed it from 
+\begin{verbatim}
+@<<GCLOPTS>>
+\end{verbatim}
+to read
+\begin{verbatim}
+@<<GCLOPTS-LOCBFD>>
+\end{verbatim}
+
+GCL-2.6.8pre2 will not build successfully on fedora core 7
+so we need to downgrade the GCLVERSION.
+<<Makefile.fedora7>>=
+#GCLVERSION=gcl-2.6.8pre
+# System dependent Makefile for the Intel/Linux platform
+# Platform variable
+PLF=LINUXplatform
+# C compiler flags
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+# Loader flags
+LDF=" -L/usr/X11R6/lib -l Xpm "
+# C compiler to use
+CC=gcc 
+AWK=gawk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+# where the libXpm.a library lives
+XLIB=/usr/X11R6/lib
+<<GCLOPTS-LOCBFD>>
+<<SRCDIRS>>
+PATCH=patch
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
+    LISP=${LISP} DAASE=${DAASE} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    SRCDIRS=${SRCDIRS} PATCH=${PATCH}
+
+all: rootdirs noweb srcsetup lspdir srcdir
+	@echo 45 Makefile.linux called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
+\subsection{Makefile.fedora8}
+On Fedora Core 8 we cannot use the line
+\begin{verbatim}
+  ${XLIB}/libXpm.a
+\end{verbatim}
+to link to the Xpm libraries. Instead We need to use
+\begin{verbatim}
+  -l Xpm
+\end{verbatim}
+These are added onto the end of the LDF variable.
+
+Annoyingly enough it seems that GCL uses a default extension of .lsp
+rather than .lisp so we add the [[LISP]] variable here. We need to
+depend on the default extension behavior because the system build
+will load either the interpreted or compiled form of a file depending
+on which is available. This varies at different stages of the build.
+
+It turns out that the standard GCL OPTS does not compile with the
+GCL 2.6.8pre version. We changed it from 
+\begin{verbatim}
+@<<GCLOPTS>>
+\end{verbatim}
+to read
+\begin{verbatim}
+@<<GCLOPTS-LOCBFD>>
+\end{verbatim}
+
+GCL-2.6.8pre2 will not build successfully on fedora core 8
+so we need to downgrade the GCLVERSION.
+<<Makefile.fedora8>>=
+#GCLVERSION=gcl-2.6.8pre
+# System dependent Makefile for the Intel/Linux platform
+# Platform variable
+PLF=LINUXplatform
+# C compiler flags
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+# Loader flags
+LDF=" -L/usr/X11R6/lib -l Xpm "
+# C compiler to use
+CC=gcc 
+AWK=gawk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+# where the libXpm.a library lives
+XLIB=/usr/X11R6/lib
+<<GCLOPTS-LOCBFD>>
+<<SRCDIRS>>
+PATCH=patch
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
+    LISP=${LISP} DAASE=${DAASE} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    SRCDIRS=${SRCDIRS} PATCH=${PATCH}
+
+all: rootdirs noweb srcsetup lspdir srcdir
+	@echo 45 Makefile.linux called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
 \subsection{Makefile.gentoo}
 Annoyingly enough it seems that GCL uses a default extension of .lsp
 rather than .lisp so we add the [[LISP]] variable here. We need to
diff --git a/changelog b/changelog
index 430c68f..8e672f7 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,4 @@
+20071119 tpd Makefile.pamphlet add fedora6,7,8 stanzas
 20071101 tpd src/interp/i-output.boot fix bugs 7010 (209), 7011
 20071019 acr src/interp/http.lisp use new return values
 20071019 acr src/algebra/axserver.spad use new return values

\start
Date: Thu, 22 Nov 2007 15:57:45 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: bug 7016 mathml display of %%var is wrong

Arthur,

zerosOf(y**4+1,y)
definingPolynomial %y1
        2
   %%var +1

but mathml gives:
      2
   var +1

somebody ate the %%.

\start
Date: Thu, 22 Nov 2007 14:43:16 -0800
From: Arthur Ralfs
To: Tim Daly
Subject: Re: bug 7016 mathml display of %%var is wrong

Tim Daly wrote:
> Arthur,
>
> zerosOf(y**4+1,y)
> definingPolynomial %y1
>         2
>    %%var +1
>
> but mathml gives:
>       2
>    var +1
>
> somebody ate the %%.

Tim,

Keep 'em coming.  I'm hoping I'll have time to do a revision of the
mathml package when I'm on vacation in a couple of weeks.

\start
Date: Thu, 22 Nov 2007 23:41:45 -0600
From: Tim Daly
To: Alfredo Portes, Arthur Ralfs
Subject: newhyper.pamphlet

Another version is checked in. It features:
   topics -> Numbers
   topics -> Polynomials
   topics -> MIT 18.085 Mathematical Methods course notes
     (This is a new section. I'm taking the MIT course online
      and working my course notes up into topics pages)

\start
Date: Fri, 23 Nov 2007 15:32:53 -0600
From: Tim Daly
To: list
Subject: November 2007 release

Summary: November 2007 release

All of the golden sources are up to date.
  savannah.nongnu.org/projects/axiom CVS
  sourceforge.net/projects/axiom CVS
  arch@axiom-developer.org ARCH (axiom--main--1--patch-54)
  git@axiom-developer.org GIT
  

ADD NEW CREDITS
  New patches were posted by Arthur and Alfredo so their tlas were
  added to the changelog

20071001 acr Arthur Ralfs
20070914 jap Jose Alfredo Portes


PORT TO DIFFERENT SYSTEMS
  As part of the new axiom website there is a binary release page.
  The stanzas for these supported systems were added.

20071119 tpd Makefile.pamphlet add fedora6,7,8 stanzas


NEW Axiom WEBSITE: http://axiom-developer.org STARTED.
  The new Axiom website (currently at axiom.axiom-developer.org)
  has been started. It will include the binary release page.


REMOVE OLD REGRESSION SYSTEM
  The previous regression test system was removed. A new combined
  regression test and help documentation system was built to replace
  this mechanism.

20070901 tpd src/input/Makefile remove ALGEBRA variable
20070901 tpd src/algebra/perm.spad remove TEST mechanism
20070901 tpd src/algebra/view2d.spad remove TEST mechanism
20070901 tpd src/algebra/fr.spad remove TEST mechanism


FIX BOOK DOCUMENTATION
  Minor typos have been discovered in the book during documentation.

20070905 tpd src/doc/book remove duplicate upperCase, lowerCase typo
20070903 tpd src/doc/bookvol4 fix typos
20070902 tpd src/doc/book MultiSet -> Multiset
20080829 tpd src/doc/book.pamphlet correct typo


FIX BUGS
  Various bugs have been found and fixed.

20071101 tpd src/interp/i-output.boot fix bugs 7010 (209), 7011
20070920 tpd src/input/Makefile add bug101.input regression test
20070920 tpd src/input/bug101.input test laplace(log(z),z,w) bug 101
20070920 wxh src/algebra/laplace.spad fix laplace(log(z),z,w) bug 101
20070916 tpd src/input/Makefile add bug103.input regression test
20070916 tpd src/input/bug103.input test solve(z=z,z) bug fix
20070916 tpd src/algebra/polycat.spad solve(z=z,z) bug fix
20070916 tpd src/algebra/catdef.spad add zero? to exquo
20070915 tpd merge bug100 branch
20070915 tpd src/input/Makefile add bug100.input regression test
20070915 tpd src/input/bug100.input test integrate((z^a+1)^b,z) infinite loop
20070915 wxh src/algebra/intef.spad fix integrate((z^a+1)^b,z) infinite loop
20070915 tpd src/algebra/carten minor edit for regression cleanup
20070914 wxh src/hyper/hyper fix bad bracing of )hd change
20070914 tpd src/algebra/fraction.spad remove double )spool command
20070914 tpd src/algebra/kl.spad remove double )spool command
20070914 tpd src/algebra/lindep.spad remove double )spool command
20070914 tpd src/algebra/radix.spad remove double )spool command


ENABLE DYNAMIC RESTART OF HYPERDOC
  Hyperdoc can now be started dynamically or restarted if killed.

20070914 jap adapt changes for )hd restart to Axiom sources
20070914 wxh src/sman/bookvol6 enable restart of hyperdoc with )hd
20070914 wxh src/include/sman.h1 enable restart of hyperdoc with )hd
20070914 wxh src/hyper/hyper enable restart of hyperdoc with )hd


SET UP THE NEW FIREFOX BASED HYPERDOC
  Hyperdoc is going away. A new version of hyperdoc is being built
  which uses html/javascript/mathml. These files change the interpreter
  and algebra to support the new hyperdoc machinery.

20071019 acr src/interp/http.lisp use new return values
20071019 acr src/algebra/axserver.spad use new return values
20071014 acr src/algebra/axserver.spad use getContentType(pathvar)
20071013 acr license/license.ralfs license rewrite
20071013 acr src/interp/http.lisp faster page service
20071013 acr src/algebra/axserver.spad faster page service
20071001 tpd src/algebra/exposed.lisp add (|AxiomServer| . AXSERV) to basic
20071001 tpd src/algebra/Makefile add axserver.spad
20071001 acr src/algebra/axserver.spad axserver socket connection code
20071001 tpd src/interp/Makefile add http.lisp
20071001 acr src/interp/http.lisp axserver socket connection code
20071001 acr license/license.ralfs added


REGRESSION TEST CALCULUS
  A new regression test suite for calculus is being built. The first
  of these files has been added to the system.

20070913 tpd src/input/Makefile schaum1.input added
20070913 tpd src/input/schaum1.input added


REGRESSION TEST ORDINARY DIFFERENTIAL EQUATIONS
  A regression test suite for ordinary differential equations was built. 

20071005 tpd src/input/Makefile kamke7.input regression test added
20071005 tpd src/input/kamke7.input ODE regression test added
20071005 tpd src/input/Makefile kamke6.input regression test added
20071005 tpd src/input/kamke6.input ODE regression test added
20071005 tpd src/input/Makefile kamke5.input regression test added
20071005 tpd src/input/kamke5.input ODE regression test added
20071005 tpd src/input/Makefile kamke4.input regression test added
20071005 tpd src/input/kamke4.input ODE regression test added
20071005 tpd src/input/Makefile kamke3.input regression test added
20071005 tpd src/input/kamke3.input ODE regression test added
20071004 tpd src/input/Makefile kamke2.input regression test added
20071004 tpd src/input/kamke2.input ODE regression test added
20071004 tpd src/input/Makefile kamke1.input regression test added
20071004 tpd src/input/kamke1.input ODE regression test added
20071004 tpd src/input/Makefile kamke0.input regression test added
20071004 tpd src/input/kamke0.input ODE regression test added


REGRESSION TEST PFAFFIAN
  Martin added the pfaffian regression test. It was added and removed
  due to documentation license issues. New documentation is being written.

20070929 tpd src/input/Makefile pfaffian regression test removed
20070929 tpd src/input/pfaffian.input regression test removed
20070927 tpd src/input/Makefile pfaffian regression test added 
20070927 mxr src/input/pfaffian.input regression test added 


ADD PORTIONS OF THE GUESS PACKAGE
  The newton.spad file is actually part of the fffg.spad file so it
  was removed. The very top level spad functions in GUESS still do
  not work properly.

20070909 tpd src/algebra/newton.spad included in fffg.spad
20070909 tpd src/algebra/Makefile remove newton.spad (duplicate)


FIX BUILD PROCESS
  The build process was not properly suppressing output by default.

20070907 tpd src/algebra/acplot.spad fix PlaneAlgebraicCurvePlot.help NOISE
20070907 tpd src/algebra/Makefile make regression respect NOISE variable
20070907 tpd src/input/Makefile make regression respect NOISE variable


FIX INSTALL PROCESS
  The install process had a bug.

20070906 tpd Makefile int/sman/axiom command to target command for install
20070906 tpd src/sman/Makefile copy axiom command to int


ADD ALDOR RELEASE
  The aldor release has been added to zips. It will soon be part of
  the build mechanism but separately maintained like GCL.

20070901 tpd zips/aldor.20070901.tgz add pdf documentation
20070901 tpd zips/aldor.20070901.tgz added


ADD )HELP FACILITY
  The )help facility was recovered. The documentation is now integrated
  into the spad files and used both for help documentation and algebra
  regression testing. 

20070902 tpd src/doc/Makefile document how to add help files
20070902 tpd src/algebra/Makefile document how to add help files
20070906 tpd merge help files branch
20070906 tpd src/doc/spadhelp add ZeroDimensionalSolvePackage
20070906 tpd src/algebra/Makefile add ZeroDimensionalSolvePackage.help 
20070906 tpd src/algebra/zerodim.spad add ZeroDimensionalSolvePackage.help
20070906 tpd src/algebra/zerodim.spad ZeroDimensionalSolvePackage.input
20070906 tpd src/doc/spadhelp add XPolynomialRing
20070906 tpd src/algebra/Makefile add XPolynomialRing.help 
20070906 tpd src/algebra/xpoly.spad add XPolynomialRing.help (XPR)
20070906 tpd src/algebra/xpoly.spad XPolynomialRing.input
20070906 tpd src/doc/spadhelp add XPolynomial
20070906 tpd src/algebra/Makefile add XPolynomial.help 
20070906 tpd src/algebra/xpoly.spad add XPolynomial.help (XPOLY)
20070906 tpd src/algebra/xpoly.spad XPolynomial.input
20070906 tpd src/doc/spadhelp add XPBWPolynomial
20070906 tpd src/algebra/Makefile add XPBWPolynomial.help 
20070906 tpd src/algebra/xlpoly.spad add XPBWPolynomial.help (XPBWPOLY)
20070906 tpd src/algebra/xlpoly.spad XPBWPolynomial.input
20070905 tpd src/doc/spadhelp add WuWenTsunTriangularSet
20070905 tpd src/algebra/Makefile add WuWenTsunTriangularSet.help 
20070905 tpd src/algebra/triset.spad add WuWenTsunTriangularSet.help (WUTSET)
20070905 tpd src/algebra/triset.spad WuWenTsunTriangularSet.input
20070905 tpd src/doc/spadhelp add Void
20070905 tpd src/algebra/Makefile add Void.help 
20070905 tpd src/algebra/void.spad add Void.help (VOID)
20070905 tpd src/algebra/void.spad Void.input
20070905 tpd src/doc/spadhelp add Vector
20070905 tpd src/algebra/Makefile add Vector.help 
20070905 tpd src/algebra/vector.spad add Vector.help (Vector)
20070905 tpd src/algebra/vector.spad Vector.input
20070905 tpd src/doc/spadhelp add UniversalSegment
20070905 tpd src/algebra/Makefile add UniversalSegment.help 
20070905 tpd src/algebra/seg.spad add UniversalSegment.help (UNISEG)
20070905 tpd src/algebra/seg.spad UniversalSegment.input
20070905 tpd src/doc/spadhelp add UnivariatePolynomial
20070905 tpd src/algebra/Makefile add UnivariatePolynomial.help 
20070905 tpd src/algebra/poly.spad add UnivariatePolynomial.help (UP)
20070905 tpd src/algebra/poly.spad UnivariatePolynomial.input
20070905 tpd src/doc/spadhelp add TwoDimensionalArray
20070905 tpd src/algebra/Makefile add TwoDimensionalArray.help 
20070905 tpd src/algebra/array2.spad add TwoDimensionalArray.help (ARRAY2)
20070905 tpd src/algebra/array2.spad TwoDimensionalArray.input
20070905 tpd src/doc/spadhelp add TextFile
20070905 tpd src/algebra/Makefile add TextFile.help 
20070905 tpd src/algebra/files.spad add TextFile.help (TEXTFILE)
20070905 tpd src/algebra/files.spad TextFile.input
20070905 tpd src/doc/spadhelp add Table
20070905 tpd src/algebra/Makefile add Table.help 
20070905 tpd src/algebra/table.spad add Table.help (TABLE)
20070905 tpd src/algebra/table.spad Table.input
20070905 tpd src/doc/spadhelp add StringTable
20070905 tpd src/algebra/Makefile add StringTable.help 
20070905 tpd src/algebra/table.spad add StringTable.help (STRTBL)
20070905 tpd src/algebra/table.spad StringTable.input
20070905 tpd src/doc/spadhelp add String
20070905 tpd src/algebra/Makefile add String.help 
20070905 tpd src/algebra/stream.spad add String.help (STRING)
20070905 tpd src/algebra/stream.spad String.input
20070905 tpd src/doc/spadhelp add Stream
20070905 tpd src/algebra/Makefile add Stream.help 
20070905 tpd src/algebra/stream.spad add Stream.help (STREAM)
20070905 tpd src/algebra/stream.spad Stream.input
20070905 tpd src/doc/spadhelp add SquareFreeRegularTriangularSet
20070905 tpd src/algebra/Makefile add SquareFreeRegularTriangularSet.help 
20070905 tpd src/algebra/sregset.spad add SquareFreeRegularTriangularSet.help
20070905 tpd src/algebra/sregset.spad SquareFreeRegularTriangularSet.input
20070905 tpd src/doc/spadhelp add SquareMatrix
20070905 tpd src/algebra/Makefile add SquareMatrix.help 
20070905 tpd src/algebra/matrix.spad add SquareMatrix.help (SQMATRIX)
20070905 tpd src/algebra/matrix.spad SquareMatrix.input
20070905 tpd src/doc/spadhelp add SparseTable
20070905 tpd src/algebra/Makefile add SparseTable.help 
20070905 tpd src/algebra/table.spad add SparseTable.help (STBL)
20070905 tpd src/algebra/table.spad SparseTable.input
20070905 tpd src/doc/spadhelp add SingleInteger
20070905 tpd src/algebra/Makefile add SingleInteger.help 
20070905 tpd src/algebra/si.spad add SingleInteger.help (SINT)
20070905 tpd src/algebra/si.spad SingleInteger.input
20070905 tpd src/doc/spadhelp add Set
20070905 tpd src/algebra/Makefile add Set.help 
20070905 tpd src/algebra/sets.spad add Set.help (SET)
20070905 tpd src/algebra/sets.spad Set.input
20070905 tpd src/doc/spadhelp add SegmentBinding
20070905 tpd src/algebra/Makefile add SegmentBinding.help 
20070905 tpd src/algebra/seg.spad add SegmentBinding.help (SEGBIND)
20070905 tpd src/algebra/seg.spad SegmentBinding.input
20070905 tpd src/doc/spadhelp add Segment
20070905 tpd src/algebra/Makefile add Segment.help 
20070905 tpd src/algebra/seg.spad add Segment.help (SEG)
20070905 tpd src/algebra/seg.spad Segment.input
20070905 tpd src/algebra/integer.spad update RomanNumeral.help (ROMAN)
20070905 tpd src/algebra/integer.spad update RomanNumeral.input
20070904 tpd src/doc/spadhelp add RegularTriangularSet
20070904 tpd src/algebra/Makefile add RegularTriangularSet.help 
20070904 tpd src/algebra/regset.spad add RegularTriangularSet.help (REGSET)
20070904 tpd src/algebra/regset.spad RegularTriangularSet.input
20070904 tpd src/doc/spadhelp add RealClosure
20070904 tpd src/algebra/Makefile add RealClosure.help 
20070904 tpd src/algebra/reclos.spad add RealClosure.help (RECLOS)
20070904 tpd src/algebra/reclos.spad RealClosure.input
20070904 tpd src/doc/spadhelp add RadixExpansion
20070904 tpd src/algebra/Makefile add RadixExpansion.help 
20070904 tpd src/algebra/radix.spad add RadixExpansion.help (RADIX)
20070904 tpd src/algebra/radix.spad RadixExpansion.input
20070903 tpd src/doc/spadhelp add Polynomial
20070903 tpd src/algebra/Makefile add Polynomial.help 
20070903 tpd src/algebra/multpoly.spad add Polynomial.help (POLY)
20070903 tpd src/algebra/multpoly.spad Polynomial.input
20070903 tpd src/doc/spadhelp add Permanent
20070903 tpd src/algebra/Makefile add Permanent.help 
20070903 tpd src/algebra/perman.spad add Permanent.help (PERMAN)
20070903 tpd src/algebra/perman.spad Permanent.input
20070903 tpd src/doc/spadhelp add PartialFraction
20070903 tpd src/algebra/Makefile add PartialFraction.help 
20070903 tpd src/algebra/pfr.spad add PartialFraction.help (PFR)
20070903 tpd src/algebra/pfr.spad PartialFraction.input
20070903 tpd src/doc/spadhelp add OrderlyDifferentialPolynomial
20070903 tpd src/algebra/Makefile add OrderlyDifferentialPolynomial.help 
20070903 tpd src/algebra/dpolcat.spad add OrderlyDifferentialPolynomial (ODPOL)
20070903 tpd src/algebra/dpolcat.spad OrderlyDifferentialPolynomial.input
20070903 tpd src/doc/spadhelp add OrderedVariableList
20070903 tpd src/algebra/Makefile add OrderedVariableList.help 
20070903 tpd src/algebra/variable.spad add OrderedVariableList.help (OVAR)
20070903 tpd src/algebra/variable.spad OrderedVariableList.input
20070903 tpd src/doc/spadhelp add Operator
20070903 tpd src/algebra/Makefile add Operator.help 
20070903 tpd src/algebra/opalg.spad add Operator.help (OP)
20070903 tpd src/algebra/opalg.spad Operator.input
20070903 tpd src/algebra/radix.spad fix typos in help file
20070903 tpd src/algebra/integer.spad fix typos in help file
20070902 tpd src/doc/spadhelp add OneDimensionalArray
20070902 tpd src/algebra/Makefile add OneDimensionalArray.help 
20070902 tpd src/algebra/array1.spad add OneDimensionalArray.help (ARRAY1)
20070902 tpd src/algebra/array1.spad OneDimensionalArray.input
20070902 tpd src/doc/spadhelp add Octonion
20070902 tpd src/algebra/Makefile add Octonion.help 
20070902 tpd src/algebra/oct.spad add Octonion.help (OCT)
20070902 tpd src/algebra/oct.spad Octonion.input
20070902 tpd src/doc/spadhelp add None
20070902 tpd src/algebra/Makefile add None.help 
20070902 tpd src/algebra/any.spad add None.help (NONE)
20070902 tpd src/algebra/any.spad None.input
20070902 tpd src/doc/spadhelp add MultivariatePolynomial
20070902 tpd src/algebra/Makefile add MultivariatePolynomial.help 
20070902 tpd src/algebra/multpoly.spad add MultivariatePolynomial.help (MPOLY)
20070902 tpd src/algebra/multpoly.spad MultivariatePolynomial.input
20070902 tpd src/doc/spadhelp add Multiset
20070902 tpd src/algebra/Makefile add Multiset.help 
20070902 tpd src/algebra/mset.spad add Multiset.help (MSET)
20070902 tpd src/algebra/mset.spad Multiset.input
20070902 tpd src/doc/spadhelp add Matrix
20070902 tpd src/algebra/Makefile add Matrix.help 
20070902 tpd src/algebra/matrix.spad add Matrix.help (MATRIX)
20070902 tpd src/algebra/matrix.spad Matrix.input
20070902 tpd src/doc/spadhelp add MappingPackage3
20070902 tpd src/algebra/Makefile add MappingPackage3.help 
20070902 tpd src/algebra/mappkg.spad add MappingPackage3.help (MAPPKG3)
20070902 tpd src/algebra/mappkg.spad MappingPackage3.input
20070902 tpd src/doc/spadhelp add MappingPackage2
20070902 tpd src/algebra/Makefile add MappingPackage2.help 
20070902 tpd src/algebra/mappkg.spad add MappingPackage2.help (MAPPKG2)
20070902 tpd src/algebra/mappkg.spad MappingPackage2.input
20070902 tpd src/doc/spadhelp add MappingPackage1
20070902 tpd src/algebra/Makefile add MappingPackage1.help 
20070902 tpd src/algebra/mappkg.spad add MappingPackage1.help (MAPPKG1)
20070902 tpd src/algebra/mappkg.spad MappingPackage1.input
20070902 tpd src/doc/spadhelp add MakeFunction
20070902 tpd src/algebra/Makefile add MakeFunction.help 
20070902 tpd src/algebra/mkfunc.spad add MakeFunction.help (MKFUNC)
20070902 tpd src/algebra/mkfunc.spad MakeFunction.input
20070902 tpd src/algebra/view2d.spad fix typos in help file
20070902 tpd src/algebra/files.spad fix typos in help file
20070902 tpd src/algebra/acplot.spad fix typos in help file
20070902 tpd src/doc/spadhelp add Magma
20070902 tpd src/algebra/Makefile add Magma.help 
20070902 tpd src/algebra/xlpoly.spad add Magma.help (MAGMA)
20070902 tpd src/algebra/xlpoly.spad Magma.input
20070902 tpd src/doc/spadhelp add LyndonWord
20070902 tpd src/algebra/Makefile add LyndonWord.help 
20070902 tpd src/algebra/xlpoly.spad add LyndonWord.help (LWORD)
20070902 tpd src/algebra/xlpoly.spad LyndonWord.input
20070902 tpd src/doc/spadhelp add List
20070902 tpd src/algebra/Makefile add List.help 
20070902 tpd src/algebra/list.spad add List.help (LIST)
20070902 tpd src/algebra/list.spad List.input
20070901 tpd src/doc/spadhelp add Permutation
20070901 tpd src/algebra/Makefile add Permutation.help 
20070901 tpd src/algebra/acplot.spad add Permutation.help (PERM)
20070901 tpd src/algebra/acplot.spad Permutation.input
20070901 tpd src/doc/spadhelp add TwoDimensionalViewport
20070901 tpd src/algebra/Makefile add TwoDimensionalViewport.help
20070901 tpd src/algebra/view2d.spad add TwoDimensionalViewport.help (VIEW2D)
20070901 tpd src/doc/spadhelp add PlaneAlgebraicCurvePlot
20070901 tpd src/algebra/Makefile add PlaneAlgebraicCurvePlot.help 
20070901 tpd src/algebra/acplot.spad add PlaneAlgebraicCurvePlot.help (ACPLOT)
20070901 tpd src/algebra/acplot.spad PlaneAlgebraicCurvePlot.input
20070901 tpd src/doc/spadhelp add RealSolvePackage
20070901 tpd src/algebra/Makefile add RealSolvePackage.help 
20070901 tpd src/algebra/acplot.spad add RealSolvePackage.help (REALSOLV)
20070901 tpd src/algebra/acplot.spad RealSolvePackage.input
20070830 tpd src/doc/spadhelp add LinearOrdinaryDifferentialOperator2
20070830 tpd src/algebra/Makefile add LinearOrdinaryDifferentialOperator2.help 
20070830 tpd src/algebra/lodo.spad add LinearOrdinaryDifferentialOperator2.help
20070830 tpd src/algebra/lodo.spad LinearOrdinaryDifferentialOperator2.input
20070830 tpd src/doc/spadhelp add LinearOrdinaryDifferentialOperator1
20070830 tpd src/algebra/Makefile add LinearOrdinaryDifferentialOperator1.help 
20070830 tpd src/algebra/lodo.spad add LinearOrdinaryDifferentialOperator1.help
20070830 tpd src/algebra/lodo.spad LinearOrdinaryDifferentialOperator1.input
20070830 tpd src/doc/spadhelp add LinearOrdinaryDifferentialOperator
20070830 tpd src/algebra/Makefile add LinearOrdinaryDifferentialOperator.help 
20070830 tpd src/algebra/lodo.spad add LinearOrdinaryDifferentialOperator.help
20070830 tpd src/algebra/lodo.spad add LinearOrdinaryDifferentialOperator.input
20070830 tpd src/doc/spadhelp add LiePolynomial
20070830 tpd src/algebra/Makefile add LiePolynomial.help 
20070830 tpd src/algebra/xlpoly.spad add LiePolynomial.help (LPOLY)
20070830 tpd src/algebra/xlpoly.spad add LiePolynomial.input
20070830 tpd src/doc/spadhelp add LieExponentials
20070830 tpd src/algebra/Makefile add LieExponentials.help 
20070830 tpd src/algebra/xlpoly.spad add LieExponentials.help (LEXP)
20070830 tpd src/algebra/xlpoly.spad add LieExponentials.input
20070830 tpd src/doc/spadhelp add Library
20070830 tpd src/algebra/Makefile add Library.help 
20070830 tpd src/algebra/files.spad add Library.help (LIB)
20070830 tpd src/algebra/files.spad add Library.input
20070830 tpd src/doc/spadhelp add LexTriangularPackage
20070830 tpd src/algebra/Makefile add LexTriangularPackage.help 
20070830 tpd src/algebra/zerodim.spad add LexTriangularPackage.help (LEXTRIPK)
20070830 tpd src/algebra/zerodim.spad add LexTriangularPackage.input
20070830 tpd src/doc/spadhelp add KeyedAccessFile
20070830 tpd src/algebra/Makefile add KeyedAccessFile.help 
20070830 tpd src/algebra/numtheor.spad add KeyedAccessFile.help (KAFILE)
20070830 tpd src/algebra/numtheor.spad add KeyedAccessFile.input
20070830 tpd src/doc/spadhelp add Kernel
20070830 tpd src/algebra/Makefile add Kernel.help 
20070830 tpd src/algebra/numtheor.spad add Kernel.help (KERNEL)
20070830 tpd src/algebra/numtheor.spad add Kernel.input
20070830 tpd src/doc/spadhelp add IntegerNumberTheoryFunctions
20070830 tpd src/algebra/Makefile add IntegerNumberTheoryFunctions.help 
20070830 tpd src/algebra/numtheor.spad add IntegerNumberTheoryFunctions.help
20070830 tpd src/algebra/numtheor.spad add IntegerNumberTheoryFunctions.input
20070830 tpd src/doc/spadhelp add IntegerLinearDependence
20070830 tpd src/algebra/Makefile add IntegerLinearDependence.help 
20070830 tpd src/algebra/lindep.spad add IntegerLinearDependence.help (ZLINDEP)
20070830 tpd src/algebra/lindep.spad add IntegerLinearDependence.input
20070830 tpd src/doc/spadhelp add RomanNumeral
20070830 tpd src/algebra/Makefile add RomanNumeral.help 
20070830 tpd src/algebra/integer.spad add RomanNumeral.help (ROMAN)
20070830 tpd src/algebra/integer.spad add RomanNumeral.input
20070830 tpd src/doc/spadhelp add Integer
20070830 tpd src/algebra/Makefile add Integer.help 
20070830 tpd src/algebra/integer.spad add Integer.help (INT)
20070830 tpd src/algebra/integer.spad add Integer.input
20070830 tpd src/doc/spadhelp add HexadecimalExpansion
20070830 tpd src/algebra/Makefile add HexadecimalExpansion.help 
20070830 tpd src/algebra/radix.spad add HexadecimalExpansion.help (HEXADEC)
20070830 tpd src/algebra/radix.spad add HexadecimalExpansion.input
20070829 tpd src/doc/spadhelp add Heap
20070829 tpd src/algebra/Makefile add Heap.help 
20070829 tpd src/algebra/bags.spad add Heap.help (FR)
20070829 tpd src/algebra/bags.spad add Heap.input
20070829 tpd src/doc/spadhelp add GroebnerFactorizationPackage
20070829 tpd src/algebra/Makefile add GroebnerFactorizationPackage.help 
20070829 tpd src/algebra/fparfrac.spad add GroebnerFactorizationPackage.help
20070829 tpd src/algebra/fparfrac.spad add GroebnerFactorizationPackage.input
20070829 tpd src/doc/spadhelp add GeneralSparseTable
20070829 tpd src/algebra/Makefile add GeneralSparseTable.help 
20070829 tpd src/algebra/table.spad add GeneralSparseTable.help (GSTBL)
20070829 tpd src/algebra/table.spad add GeneralSparseTable.input 
20070829 tpd src/doc/spadhelp add FullPartialFractionExpansion
20070829 tpd src/algebra/Makefile add FullPartialFractionExpansion.help 
20070829 tpd src/algebra/fparfrac.spad add FullPartialFractionExpansion.help
20070829 tpd src/algebra/fparfrac.spad add FullPartialFractionExpansion.input
20070829 tpd src/doc/spadhelp add Fraction
20070829 tpd src/algebra/Makefile add Fraction.help 
20070829 tpd src/algebra/fraction.spad add Fraction.help (FR)
20070829 tpd src/algebra/fraction.spad add Fraction.input
20070829 tpd src/doc/spadhelp add Float
20070829 tpd src/algebra/Makefile add Float.help 
20070829 tpd src/algebra/float.spad add Float.help (FLOAT)
20070829 tpd src/algebra/float.spad add Float.input
20070828 tpd src/doc/spadhelp add FlexibleArray
20070828 tpd src/algebra/Makefile add FlexibleArray.help 
20070828 tpd src/algebra/array1.spad add FlexibleArray.help (FARRAY)
20070828 tpd src/algebra/array1.spad add FlexibleArray.input
20070827 tpd src/doc/spadhelp add FileName
20070827 tpd src/algebra/Makefile add FileName.help 
20070827 tpd src/algebra/fname.spad add FileName.help (FNAME)
20070827 tpd src/algebra/fname.spad add FileName.input
20070827 tpd src/doc/spadhelp add File
20070827 tpd src/algebra/Makefile add File.help 
20070827 tpd src/algebra/files.spad add File.help (FILE)
20070827 tpd src/algebra/files.spad add File.input
20070827 tpd src/doc/spadhelp add FactoredFunctions2
20070827 tpd src/algebra/Makefile add FactoredFunctions2.help 
20070827 tpd src/algebra/fr.spad add FactoredFunctions2.help (FR2)
20070827 tpd src/algebra/fr.spad add FactoredFunctions2.input
20070827 tpd src/doc/spadhelp add Factored
20070827 tpd src/algebra/Makefile add Factored.help 
20070827 tpd src/algebra/fr.spad add Factored.help (FR)
20070827 tpd src/algebra/fr.spad add Factored.input

\start
Date: Sat, 24 Nov 2007 00:53:12 -0800
From: Ed Borasky
To: Tim Daly
Subject: Re: November 2007 release 

Tim Daly wrote:
> Summary: November 2007 release
> 
> All of the golden sources are up to date.
>   savannah.nongnu.org/projects/axiom CVS
>   sourceforge.net/projects/axiom CVS
>   arch@axiom-developer.org ARCH (axiom--main--1--patch-54)
>   git@axiom-developer.org GIT
>   
> 
> ADD NEW CREDITS
>   New patches were posted by Arthur and Alfredo so their tlas were
>   added to the changelog
> 
> 20071001 acr Arthur Ralfs
> 20070914 jap Jose Alfredo Portes
> 
> 
> PORT TO DIFFERENT SYSTEMS
>   As part of the new axiom website there is a binary release page.
>   The stanzas for these supported systems were added.
> 
> 20071119 tpd Makefile.pamphlet add fedora6,7,8 stanzas
> 
> 
> NEW Axiom WEBSITE: http://axiom-developer.org STARTED.
>   The new Axiom website (currently at axiom.axiom-developer.org)
>   has been started. It will include the binary release page.

[snip]

Are there source tarballs of the Golden source?

\start
Date: Sat, 24 Nov 2007 12:58:54 -0600
From: Tim Daly
To: Ed Borasky
Subject: November 2007 source tarball

Follow the src link at <http://daly.axiom-developer.org/axiombinary>
or you can download the tarball directly from
<http://daly.axiom-developer.org/axiombinary/silver-nov2007-src.tgz>

These will be moved and maintained in the future at
<http://axiom-developer.org> or
<http://axiom.axiom-developer.org>
as soon as the new website details get settled.


\start
Date: Sat, 24 Nov 2007 17:58:16 -0500
From: Bill Page
To: list, 
Subject: Axiom Wiki and Axiom Portal

Dear Axiom Fans,

The move of the Axiom Wiki and the Axiom Portal that was announced
last month is now nearly complete. Monday, November 26 is the official
date for the release of the new Axiom Wiki:

  http://axiom-wiki.newsynthesis.org

and the new Axiom Portal

  http://axiom-portal.newsynthesis.org

which is now hosted on the Sage server operated by William Stein at
the University of Washington. On Monday the old urls:

  http://wiki.axiom-developer.org      ** obsolete **

and

  http://portal.axiom-developer.org   **obsolete **

will be automatically re-directed to the new sites. Later that week,
all wiki and portal files will be removed from the axiom-developer.org
server. Tim Daly has plans that he will announce separately for
re-allocating resources on this server to focus on the goals of the
original Axiom project.

The new site is intended to support all three Axiom-related projects
(the original project plus OpenAxiom and the FriCAS forks), as well as
Aldor as a library compiler for Axiom. In addition to Axiom the wiki
and portal include interfaces for Reduce, Maxima and Sage. It also
supports pages containing noweb literate programs (pamphlets) and
graphics generated by graphviz.

All bug reports and issues from the old wiki site have been
transferred to the new site and an updated version of the customized
Topic navigation has been implemented at the new site (left sidebar).
The only feature that has not (yet) been implemented at the new site
is the point-and-click assistant extension of the edit and comment
forms. I am not certain whether this feature is really desirable since
in increases the size and there for the rendering time of every page
on the site. I would be glad to receive opinions about this.

If find any of your favorite pages from the old site are missing at
the new site, there is still time to transfer the page source from old
to the new. If you need help with doing this just let me know. Some of
the pages on the new axiom-wiki site do not yet reflect the current
state of the Axiom-related projects. Your help in updating the pages
at the new axiom-wiki site would be greatly appreciated.

If your were registered as a user of the old Axiom Portal site, your
account has *not* been automatically transferred to the new site. If
you have some files or other content that you wish to preserve and
transfer to the new site, please register at the new site:

  http://axiom-portal.newsynthesis.org

and if necessary ask me for help in transferring the content.

\start
Date: 25 Nov 2007 08:19:09 +0100
From: Martin Rubey
To: list
Subject: Re:  Axiom Wiki and Axiom Portal

Bill Page writes:

> All bug reports and issues from the old wiki site have been
> transferred to the new site and an updated version of the customized
> Topic navigation has been implemented at the new site (left sidebar).

Bill, you are a hero!

> The only feature that has not (yet) been implemented at the new site is the
> point-and-click assistant extension of the edit and comment forms. I am not
> certain whether this feature is really desirable since in increases the size
> and there for the rendering time of every page on the site. I would be glad
> to receive opinions about this.

I never used it that one.

\start
Date: Sun, 25 Nov 2007 01:26:26 -0600
From: Tim Daly
To: Arthur Ralfs, Alfredo Portes
Subject: newhyper.pamphlet

I finished the specific polynomial types which completes the
topics->polynomial pages. I also added the complete glossary.
It is checked in.

\start
Date: 25 Nov 2007 11:28:11 +0100
From: Martin Rubey
To: list
Subject: Bug in parallel iteration

Dear all,

I just found a *very* annoying bug in axiom's handling of parallel iteration:

-------------------------------------------------------------------------------
(1) -> [[i,j] for i in 1..10 | odd? i for j in 1..10]

   (1) [[1,1],[3,3],[5,5],[7,7],[9,9]]
-------------------------------------------------------------------------------

(the result is the same in SPAD, i.e., compiled)

instead of

-------------------------------------------------------------------------------
%1 >> #include "aldor"
                                           Comp: 170 msec, Interp: 50 msec
%2 >> #include "aldorinterp"
                                           Comp: 80 msec, Interp: 0 msec
%3 >> import from Integer, List Integer, List List Integer
                                           Comp: 60 msec, Interp: 0 msec
%4 >> [[i,j] for i in 1..10 | odd? i for j in 1..10]
[[1,1],[3,2],[5,3],[7,4],[9,5]] @ List(List(AldorInteger))
                                           Comp: 10 msec, Interp: 340 msec
-------------------------------------------------------------------------------

I insist on calling this a bug, *not* because of my personal preference of
aldor semantics, but because axiom wastes an opportunity here, since the result
given by axiom is quite useless.

It seems that axiom applies the "such-that" clause to all iterators, rather
than only to the iterator after which it comes.  To be fair, aldor has a
similar problem: it applies the "such-that" clause to *all* iterators before,
with no way to group iterators:

-------------------------------------------------------------------------------
%5 >> [[i,j] for i in 1..10 for j in 1..10 | odd? i]
[[1,1],[3,3],[5,5],[7,7],[9,9]] @ List(List(AldorInteger))
                                           Comp: 10 msec, Interp: 40 msec
%6 >> [[i,j] for i in 1..10 | odd? i for j in 1..10 | even? j]
[[3,2],[7,4]] @ List(List(AldorInteger))
                                           Comp: 10 msec, Interp: 40 msec
-------------------------------------------------------------------------------

I would have thought that parenthesis or braces would group iterators, but they
yield syntax errors instead.

Any hope?  I.e., what I want is:

* group iterators with parens or braces
* apply such-that clauses to all iterators that come before, and are in the
  same group

\start
Date: 25 Nov 2007 09:41:56 -0600
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Bug in parallel iteration

Martin Rubey writes:

| Dear all,
| 
| I just found a *very* annoying bug in axiom's handling of parallel iteration:
| 
| -------------------------------------------------------------------------------
| (1) -> [[i,j] for i in 1..10 | odd? i for j in 1..10]
| 
|    (1) [[1,1],[3,3],[5,5],[7,7],[9,9]]
| -------------------------------------------------------------------------------

[...]

| It seems that axiom applies the "such-that" clause to all iterators, rather
| than only to the iterator after which it comes.

That is what the documentation says, see the Axiom Book pages 127, 129.

You may want to lobby for changing a documented behaviour (thus
breaking codes written with that specification in mind), but I'm not
sure calling it  bug is an effective way to achieve that goal.

\start
Date: Sun, 25 Nov 2007 12:41:19 -0500
From: William Sit
To: Martin Rubey
Subject: Re: Bug in parallel iteration

Dear Martin:

Your request seems to me to be one for syntactic sugar. Is 
it that difficult to use:

(1) -> [[i,j] for i in [i1 for i1 in 1..10 | odd? i1] for 
j in [j1 for j1 in 1..10 | even? j1]]

    (1)  [[1,2],[3,4],[5,6],[7,8],[9,10]]
                     Type: List List PositiveInteger

Parallel iteration is supposed to iterate over lists of 
same length and "1..10 | odd? i" does not form a list 
correctly, while "i in 1..10 | odd? i" preceded by "for" 
is not correct syntax. If there were to be a bug, it would 
be that neither Axiom nor Aldor reported a syntax error.


William

On 25 Nov 2007 11:28:11 +0100
  Martin Rubey wrote:
>Dear all,
>
>I just found a *very* annoying bug in axiom's handling of 
>parallel iteration:
>
>-------------------------------------------------------------------------------
>(1) -> [[i,j] for i in 1..10 | odd? i for j in 1..10]
>
>    (1) [[1,1],[3,3],[5,5],[7,7],[9,9]]
>-------------------------------------------------------------------------------
>
>(the result is the same in SPAD, i.e., compiled)
>
>instead of
>
>-------------------------------------------------------------------------------
>%1 >> #include "aldor"
>                                            Comp: 170 
>msec, Interp: 50 msec
>%2 >> #include "aldorinterp"
>                                            Comp: 80 
>msec, Interp: 0 msec
>%3 >> import from Integer, List Integer, List List 
>Integer
>                                            Comp: 60 
>msec, Interp: 0 msec
>%4 >> [[i,j] for i in 1..10 | odd? i for j in 1..10]
>[[1,1],[3,2],[5,3],[7,4],[9,5]] @ 
>List(List(AldorInteger))
>                                            Comp: 10 
>msec, Interp: 340 msec
>-------------------------------------------------------------------------------
>
>I insist on calling this a bug, *not* because of my 
>personal preference of
>aldor semantics, but because axiom wastes an opportunity 
>here, since the result
>given by axiom is quite useless.
>
>It seems that axiom applies the "such-that" clause to all 
>iterators, rather
>than only to the iterator after which it comes.  To be 
>fair, aldor has a
>similar problem: it applies the "such-that" clause to 
>*all* iterators before,
>with no way to group iterators:
>
>-------------------------------------------------------------------------------
>%5 >> [[i,j] for i in 1..10 for j in 1..10 | odd? i]
>[[1,1],[3,3],[5,5],[7,7],[9,9]] @ 
>List(List(AldorInteger))
>                                            Comp: 10 
>msec, Interp: 40 msec
>%6 >> [[i,j] for i in 1..10 | odd? i for j in 1..10 | 
>even? j]
>[[3,2],[7,4]] @ List(List(AldorInteger))
>                                            Comp: 10 
>msec, Interp: 40 msec
>-------------------------------------------------------------------------------
>
>I would have thought that parenthesis or braces would 
>group iterators, but they
>yield syntax errors instead.
>
>Any hope?  I.e., what I want is:
>
>* group iterators with parens or braces
>* apply such-that clauses to all iterators that come 
>before, and are in the
>   same group

\start
Date: Sun, 25 Nov 2007 17:14:19 -0500
From: Cliff Yapp
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

>> Third, even if the NSF funded SAGE, how would those funds benefit the
>> various subprojects like Axiom? Open source is mostly volunteer work
>> done in "spare time". While it is amusing to daydream of being paid to
>> develop open source computational mathematics on a full time basis, it
>> seems unlikely that this could lead to more than just small
>> grants. The expertise and continuity needed to do research work
>> requires longer term funding.
> 
> Great questions and comments.  There aren't easy answers.
> One possibility is selling "support"... which could bring in
> money to support people who are out of country.

One possibility I've wondered about for a while would be getting a
number of colleges to simultaneously agree to pool small amounts of
money into an effort to support a couple of developers working on these
programs - i.e. spreading the cost over many institutions rather than
just having one or two carry all of the cost.  Start up a small
nonprofit or some such to serve as the organization in question.  Surely
if grant money can sometimes pay for commercial software it could go to
pay for such an arrangement, particularly if the software was all
guaranteed to be open.

Is this something someone could set up with any hope of success?

\start
Date: Sun, 25 Nov 2007 16:58:05 -0800
From: William Stein
To: Cliff Yapp
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

On Nov 25, 2007 2:14 PM, Cliff Yapp wrote:
> >> Third, even if the NSF funded SAGE, how would those funds benefit the
> >> various subprojects like Axiom? Open source is mostly volunteer work
> >> done in "spare time". While it is amusing to daydream of being paid to
> >> develop open source computational mathematics on a full time basis, it
> >> seems unlikely that this could lead to more than just small
> >> grants. The expertise and continuity needed to do research work
> >> requires longer term funding.
> >
> > Great questions and comments.  There aren't easy answers.
> > One possibility is selling "support"... which could bring in
> > money to support people who are out of country.
>
> One possibility I've wondered about for a while would be getting a
> number of colleges to simultaneously agree to pool small amounts of
> money into an effort to support a couple of developers working on these
> programs - i.e. spreading the cost over many institutions rather than
> just having one or two carry all of the cost.  Start up a small
> nonprofit or some such to serve as the organization in question.  Surely
> if grant money can sometimes pay for commercial software it could go to
> pay for such an arrangement, particularly if the software was all
> guaranteed to be open.
>
> Is this something someone could set up with any hope of success?

I think something like this could be successful.  Actually, Magma has
been a very successful example of almost exactly this during the last
10 years.   They are a nonprofit, they get a pool of small amounts
of money from a few hundred (?) sites, and as a result hire about
5-10 fulltime people per year to work on Magma.   The only difference
is that Magma is not open.  But it is a useful successful real-life
example, which
should not be ignored:
  http://magma.maths.usyd.edu.au/magma/

\start
Date: Sun, 25 Nov 2007 22:54:03 -0500
From: Tim Daly
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

>> >> Third, even if the NSF funded SAGE, how would those funds benefit the
>> >> various subprojects like Axiom? Open source is mostly volunteer work
>> >> done in "spare time". While it is amusing to daydream of being paid to
>> >> develop open source computational mathematics on a full time basis, it
>> >> seems unlikely that this could lead to more than just small
>> >> grants. The expertise and continuity needed to do research work
>> >> requires longer term funding.
>> >
>> > Great questions and comments.  There aren't easy answers.
>> > One possibility is selling "support"... which could bring in
>> > money to support people who are out of country.
>>
>> One possibility I've wondered about for a while would be getting a
>> number of colleges to simultaneously agree to pool small amounts of
>> money into an effort to support a couple of developers working on these
>> programs - i.e. spreading the cost over many institutions rather than
>> just having one or two carry all of the cost.  Start up a small
>> nonprofit or some such to serve as the organization in question.  Surely
>> if grant money can sometimes pay for commercial software it could go to
>> pay for such an arrangement, particularly if the software was all
>> guaranteed to be open.
>>
>> Is this something someone could set up with any hope of success?
>
>I think something like this could be successful.  Actually, Magma has
>been a very successful example of almost exactly this during the last
>10 years.   They are a nonprofit, they get a pool of small amounts
>of money from a few hundred (?) sites, and as a result hire about
>5-10 fulltime people per year to work on Magma.   The only difference
>is that Magma is not open.  But it is a useful successful real-life
>example, which
>should not be ignored:
>  http://magma.maths.usyd.edu.au/magma/


My experience at schools has been that money is a scarce and very 
closely guarded resource. At one school, over 50% of the grant money
disappeared into the "overhead" at the provost office before the
money ever appeared.

Either the initial grant had principal investigators at different
schools (or one of the PIs moved), or a visiting scientist arrangement
allowed someone on leave to join the project for a while, otherwise
I don't recall other arrangements. However, my experience is quite
limited.

On the federal front, I believe the funding organizations are only
capable of making grants to other organizations that have departments
that handle funds, requiring the overhead. But giving money to open
source is like giving money to the homeless. Even though 100% of it
will go to support direct needs, it appears to disappear.

Corporate funding has mostly (except TI?) shifted to more dedicated
businesses (eg. Wolfram, Maplesoft, etc.) and I've already mentioned
that I believe these will end. The question is, what will replace
them and how will computational mathematics be impacted?



I am of two minds about the whole funding issue.

On the one hand, funding would make it possible to concentrate
completely on the research and development of the code and community.
Given that Axiom has a 30 year horizon this would allow deep planning,
a stronger theoretical basis, and more functionality.

On the other hand, money has strings. And these strings almost always
lack long-term visions, focusing on the quarterly and yearly reports.
Given that Axiom has a 30 year horizon this would be disruptive.

Considering both sides, it seems that disruptive funding is the
greater danger to the long term survival.  In the long run, it's not
the funding that matters. It's the work.

--------------------------------------------------------------------
What would you do if you were not paid to do it?
That's what you are. -- Tim Daly

\start
Date: Sun, 25 Nov 2007 19:49:50 -0800
From: William Stein
To: Tim Daly
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: David Joyner, Paul Zimmermann

On Nov 25, 2007 7:54 PM, Tim Daly wrote:
> >> >> Third, even if the NSF funded SAGE, how would those funds benefit the
> >> >> various subprojects like Axiom? Open source is mostly volunteer work
> >> >> done in "spare time". While it is amusing to daydream of being paid to
> >> >> develop open source computational mathematics on a full time basis, it
> >> >> seems unlikely that this could lead to more than just small
> >> >> grants. The expertise and continuity needed to do research work
> >> >> requires longer term funding.
> >> >
> >> > Great questions and comments.  There aren't easy answers.
> >> > One possibility is selling "support"... which could bring in
> >> > money to support people who are out of country.
> >>
> >> One possibility I've wondered about for a while would be getting a
> >> number of colleges to simultaneously agree to pool small amounts of
> >> money into an effort to support a couple of developers working on these
> >> programs - i.e. spreading the cost over many institutions rather than
> >> just having one or two carry all of the cost.  Start up a small
> >> nonprofit or some such to serve as the organization in question.  Surely
> >> if grant money can sometimes pay for commercial software it could go to
> >> pay for such an arrangement, particularly if the software was all
> >> guaranteed to be open.
> >>
> >> Is this something someone could set up with any hope of success?
> >
> >I think something like this could be successful.  Actually, Magma has
> >been a very successful example of almost exactly this during the last
> >10 years.   They are a nonprofit, they get a pool of small amounts
> >of money from a few hundred (?) sites, and as a result hire about
> >5-10 fulltime people per year to work on Magma.   The only difference
> >is that Magma is not open.  But it is a useful successful real-life
> >example, which
> >should not be ignored:
> >  http://magma.maths.usyd.edu.au/magma/
>
>
> My experience at schools has been that money is a scarce and very
> closely guarded resource.

Yep.  But schools do buy software... (they really don't like to so
much but they do it).

>  At one school, over 50% of the grant money
> disappeared into the "overhead" at the provost office before the
> money ever appeared.

At every university I have taught at (UCSD, Harvard, Washington), the
overhead that the university gets on any grant money I have is about 55%.
That is, if I would like to receive $1000 from the NSF, then the NSF has
to give me $1550.  This additional $550 is used by the university to pay
support staff, build buildings, roads, whatever.   The overhead rate varies
from university to university, since it is negotiated with the NSF.

> Either the initial grant had principal investigators at different
> schools (or one of the PIs moved), or a visiting scientist arrangement
> allowed someone on leave to join the project for a while, otherwise
> I don't recall other arrangements. However, my experience is quite
> limited.

I'm not sure what you're saying here, but at least with NSF funds
a researcher can pay any US citizen (or person with a soc security
number) working anywhere in the US
some money to work on a project with me.   They don't have to be
officially listed on a grant application or at my university.     That said,
the grant budget would have to list that somebody somewhere would
be getting paid by the grant to do the specified work (one can't
spend NSF money they've received on anything they want -- it has
to be explicitly budgeted first).

> On the federal front, I believe the funding organizations are only
> capable of making grants to other organizations that have departments
> that handle funds, requiring the overhead.

I think that's correct.

> But giving money to open
> source is like giving money to the homeless. Even though 100% of it
> will go to support direct needs, it appears to disappear.

I'm not sure I follow.

In any case, here is a very concrete example of the NSF funding open source:

http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0713225

The money will go to pay for a postdoc for three years at UW (Clement Pernet
for the first 2 years), whose main work will be on open source software.
(I can't emphasize how much work it was to get the above grant...)

> Corporate funding has mostly (except TI?) shifted to more dedicated
> businesses (eg. Wolfram, Maplesoft, etc.) and I've already mentioned
> that I believe these will end. The question is, what will replace
> them and how will computational mathematics be impacted?

I have no idea.  I look forward to any thoughts you might have on this.
I have basically had no successful experience getting any funding for
open source math software from corporate sources.  That's where you've
done much better than me -- getting Scratchpad opened is in itself
getting a lot of "funding" in some sense.

> I am of two minds about the whole funding issue.
>
> On the one hand, funding would make it possible to concentrate
> completely on the research and development of the code and community.
> Given that Axiom has a 30 year horizon this would allow deep planning,
> a stronger theoretical basis, and more functionality.

Just out of curiosity does Axiom always have a 30 year horizon, or does
it become a 20 year horizon at some point?

\start
Date: 25 Nov 2007 23:18:53 -0600
From: Gabriel Dos Reis
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

William Stein writes:

[...]

| Just out of curiosity does Axiom always have a 30 year horizon, or does
| it become a 20 year horizon at some point?

I think it always has 30 years horizon -- the horizon doesn't move ;-)

\start
Date: Mon, 26 Nov 2007 03:20:30 -0500
From: Tim Daly
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

> >> >> Third, even if the NSF funded SAGE, how would those funds benefit the
...[snip]...
>> Either the initial grant had principal investigators at different
>> schools (or one of the PIs moved), or a visiting scientist arrangement
>> allowed someone on leave to join the project for a while, otherwise
>> I don't recall other arrangements. However, my experience is quite
>> limited.
>
>I'm not sure what you're saying here, but at least with NSF funds
>a researcher can pay any US citizen (or person with a soc security
>number) working anywhere in the US
>some money to work on a project with me.   They don't have to be
>officially listed on a grant application or at my university.     That said,
>the grant budget would have to list that somebody somewhere would
>be getting paid by the grant to do the specified work (one can't
>spend NSF money they've received on anything they want -- it has
>to be explicitly budgeted first).

I know that we hired students to do work. At CCNY there was an open
source lab and we hired two people to work on Doyen. But student
labor is not "any U.S. citizen". It really falls partially under the
mandate of the University and was not hard to justify. 

At IBM we had a specific contract with William Schelter to develop
a version of AKCL that supported Axiom. I'm not sure that it would
have been possible to do that under an NSF contract, although you 
know more about that than I do.

I don't see how Sage could hire someone to develop a better
symbolic summation package for Axiom (although I'd be most happy
to discover that it could be done).



>> But giving money to open
>> source is like giving money to the homeless. Even though 100% of it
>> will go to support direct needs, it appears to disappear.
>
>I'm not sure I follow.
>
>In any case, here is a very concrete example of the NSF funding open source:
>
>http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0713225
>
>The money will go to pay for a postdoc for three years at UW (Clement Pernet
>for the first 2 years), whose main work will be on open source software.
>(I can't emphasize how much work it was to get the above grant...)

Again, this tends to fall into the NSF-University tangle. If Clement
were hired to sit at home and develop open source software without
the association to UW I'm not sure the grant would have passed muster.
I admit I don't know the details.

The fact that he is working on open source is incidental, in my view.
NSF work is government work and is supposed to be freely available
since it is paid for by tax money.

The distinction I'm trying to draw here is that there is a difference
between doing NSF work that is open sourced and doing open source work
that is NSF funded. The former is simply a side-effect of the proposal.
The latter is fundamental.

So getting an NSF grant to develop software for a project and then
opening the source (see Magnus, one of my sourceforge projects) is
perfectly reasonable. It happens often. Indeed Macsyma was started
that way, as near as I understand it. I can see where Sage could
be funded under this model.

But doing open source (that is, non-university, non-commercial,
privately-supported) prior to the grant and getting continued work
funded is unknown to me. I see that Axiom falls under this model.
(Curiously, (D)ARPA and NSF funded Axiom when it was at IBM, which
presumably had slightly more financial resources than me.)





>> Corporate funding has mostly (except TI?) shifted to more dedicated
>> businesses (eg. Wolfram, Maplesoft, etc.) and I've already mentioned
>> that I believe these will end. The question is, what will replace
>> them and how will computational mathematics be impacted?
>
>I have no idea.  I look forward to any thoughts you might have on this.
>I have basically had no successful experience getting any funding for
>open source math software from corporate sources.  That's where you've
>done much better than me -- getting Scratchpad opened is in itself
>getting a lot of "funding" in some sense.

My efforts in open sourcing Axiom would never have amounted to anything
without Mike Dewar and the other people at NAG. Discussions with Dick
Jenks and others leads me to believe that Axiom costs somewhere in the
range of $40 Million and several hundred man-years (sorry, Brooks) to
develop. Although it is a "sunk cost" at this point it still deserves
to be further developed.

I have had discussions with people from IBM about funding Axiom but
nothing has come of it. IBM doesn't do research anymore. (I used to be
at IBM research and still have friends there).  It does some strange
form of job-shop-consulting where the researcher has to earn enough to
justify his short term value. If Axiom were funded by IBM it would have
to become a product which would eventually put it on the very path
that will kill other computational mathematics products.

I also had discussions with TI to try to keep Derive's lisp code from
the corporate software deathbed but that failed. I think we can safely
assume that Derive will go the way of Macsyma, sad to say.





For planning assumptions, lets look out 30 years. At that point all
of the previous (and some of the current) crop of computational 
mathematics people will have retired into management or something.
Wolfram's family might wish to "cash out" and "monetize" the company.
Maplesoft might have gone public and had a stock failure. In all,
50 years is a long time for any company to survive, especially on a
single product. The loss of both MMA and Maple will leave a hole
in computational mathematics.

How do we prepare to deal with such a future event? 

We need to raise our standards. At the moment computational mathematics
seems to me to be a mixture of 18th century hand-waving-proofs and 1960s
"whew, got it to work!" software hacking. That was fine during the last
30 years as the whole subject went thru birth pangs. But now is the time
to make this more of a science.

To me that means that we need to classify, standardize, and organize
the subject. 

We need to have NIST-like categories that cover various domains.
The CATS test suite (along the lines of Abramowitz & Stegun) would
have a wide range of problems sets with standard answers, specific
behavior on branch cuts, boundary cases, etc. This would enable 
everyone to "substitute" one CAS for another with some confidence
that they get reasonable answers. This is clearly not in the best
interest of commercial systems but is clearly in the best interest
of CAS users and of the science.

We need to develop well-documented, executable descriptions of each
algorithm. One of the key goals of the Axiom project is to document
the current algorithms in such a way that you can read and understand
the algorithm without looking at the code. And you can look at the
code and see exactly how and why it executes the described algorithm.
Almost all current CAS code just shows blocks of code with hardly
even a comment or literature reference. Even if you are an expert
in the subject it is nearly impossible to read someone else's code.
I spent a long time trying to document Magnus algorithms (work in
infinite group theory) among the people who wrote the code and it
was not fruitful. See Christian Queinnec's "Lisp In Small Pieces"
(ISBN 0-521-54566-8) or Knuth's "TeX, The Program" (ISBN 0-201-13437-3)
which I am using a "intellectual role models", as the kind of minimum
standard level of documentation.


We need well-documented, executable literature.  It should be possible
to select a technical paper from this year's CAS conference that
describes something like an enhanced symbolic summation algorithm,
drag-and-drop that paper onto an existing system, and have the
documentation and code immediately available. Code is the only
"proof" that the algorithm in the paper is really an advance. 
And the paper should include information about algorithm complexity,
theoretical details, etc. 

We need to change our standards for publication.  Five page papers in
a conference are an artifact of publishing limitations and need to be
overcome. I did the first two CDs available with ISSAC and there is
plenty of room.  And the ideas of "plagerizing" need to be adapted to
allow someone to take my paper, improve the algorithm, and republish
the paper with a better, modified analysis. We do this all the time
with code.  In Axiom's distribution is a file
(src/doc/primesp.spad.pamphlet) based on the paper "Primes is in P" by
Agrawal, Kayal, and Saxena (used with permission) that is intended to
be developed into an example of such a drag-and-drop, full analysis
paper. Carlo Traverso (Univ. of Pisa) and I have been trying to
develop a journal that would host such literate documents.

We need a fully developed, human readable (ala Knuth), executable
"document" that IS a computer algebra system. A CAS which conforms to
documented and accepted standards and can have sections dynamically
updated with new, better algorithms and analysis would go a long way
toward making computational mathematics more of a science. 
Contributions to such a system immediately benefit everyone.

This is mathematics, after all. So we need proven systems. We need to
decorate the Axiom hierarchy with theorems and proofs. And this is
computer science, after all.  So we need to derive the time and space
complexity bounds. We need to think about, research, and develop the
theory and machinery to automate some of this analysis. Surely this
will be "expected and required standards" 30 years from now,
especially if we set (and struggle to meet) the standards now.
CAS is the only area I know where the results will always be correct
and valuable (unlike, say, MS Word documents) so it is worth the
effort to do it right.



I believe that if such a system were available now there would be
much less incentive for Universities to use closed source software.
And, by implication, more work (more science) would be done using
open software as a base. Eventually the loss of commercial versions
that don't meet these standards would become a non-issue. Directly
competing with heavily financed commercial systems cannot win and
ultimately leads the science in the wrong long term direction.

At least that's the vision.




>> I am of two minds about the whole funding issue.
>>
>> On the one hand, funding would make it possible to concentrate
>> completely on the research and development of the code and community.
>> Given that Axiom has a 30 year horizon this would allow deep planning,
>> a stronger theoretical basis, and more functionality.
>
>Just out of curiosity does Axiom always have a 30 year horizon, or does
>it become a 20 year horizon at some point?

Given the large cost (e.g. $40 Million (although given the U.S. dollar
that's not going to be much :-) ) and time (100s of man-years, see the
axiom credit list) it is unlikely that we are going to develop whole
new CAS systems as complex as Axiom from scratch. Thus we need to
build on what exists. And we need to build for the long term.

The 30 year horizon is a philosophy, not a timeline. In fact, it is 
intended to suggest raising our eyes away from the short-term thinking
(e.g. competition with commercial software) and orient the discussion
to the long term science. Computational mathematics is a new area but
it is certainly here for the long haul.

So "The 30 year horizon" is a sort of Zeno's game. You may get half
way there but you'll never actually get all the way there. I intended
the slogan to inspire, not limit.

\start
Date: Sun, 25 Nov 2007 23:45:02 -0800
From: William Stein
To: Tim Daly
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: David Joyner, Paul Zimmermann

On Nov 26, 2007 12:20 AM, Tim Daly wrote:
> > >> >> Third, even if the NSF funded SAGE, how would those funds benefit the
> ...[snip]...
> >> Either the initial grant had principal investigators at different
> >> schools (or one of the PIs moved), or a visiting scientist arrangement
> >> allowed someone on leave to join the project for a while, otherwise
> >> I don't recall other arrangements. However, my experience is quite
> >> limited.
> >
> >I'm not sure what you're saying here, but at least with NSF funds
> >a researcher can pay any US citizen (or person with a soc security
> >number) working anywhere in the US
> >some money to work on a project with me.   They don't have to be
> >officially listed on a grant application or at my university.     That said,
> >the grant budget would have to list that somebody somewhere would
> >be getting paid by the grant to do the specified work (one can't
> >spend NSF money they've received on anything they want -- it has
> >to be explicitly budgeted first).
>
> I know that we hired students to do work. At CCNY there was an open
> source lab and we hired two people to work on Doyen. But student
> labor is not "any U.S. citizen". It really falls partially under the
> mandate of the University and was not hard to justify.

Yes, I could hire students as long as they are students at the university.
I was just pointing out that it's also possible to pay non-students.

> At IBM we had a specific contract with William Schelter to develop
> a version of AKCL that supported Axiom. I'm not sure that it would
> have been possible to do that under an NSF contract, although you
> know more about that than I do.

I don't know either.

> >> But giving money to open
> >> source is like giving money to the homeless. Even though 100% of it
> >> will go to support direct needs, it appears to disappear.
> >
> >I'm not sure I follow.
> >
> >In any case, here is a very concrete example of the NSF funding open source:
> >
> >http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=0713225
> >
> >The money will go to pay for a postdoc for three years at UW (Clement Pernet
> >for the first 2 years), whose main work will be on open source software.
> >(I can't emphasize how much work it was to get the above grant...)
>
> Again, this tends to fall into the NSF-University tangle. If Clement
> were hired to sit at home and develop open source software without
> the association to UW I'm not sure the grant would have passed muster.
> I admit I don't know the details.

This is solidly in the "NSF-University tangle".  In fact, a critical component
is that Clement will be a research postdoc at the university, contribute
to the research environment there, write papers, etc.   The NSF really
cared about all that.

> The fact that he is working on open source is incidental, in my view.
> NSF work is government work and is supposed to be freely available
> since it is paid for by tax money.

Unfortunately, that's not at all how things actually work though.
Researchers funded by *NSF grants* are usually under no obligation
to make their work freely available.   I probably wish something more
like this were the case, but it isn't in general.  That's just the current
reality of how things work.

> The distinction I'm trying to draw here is that there is a difference
> between doing NSF work that is open sourced and doing open source work
> that is NSF funded. The former is simply a side-effect of the proposal.
> The latter is fundamental.

I view the Sage postdoc, i.e., what I linked to above, as the latter.  It
was NSF funding a proposal specifically to support some open source
software development.  I'm very appreciate to them for being open
minded and funding it.  The abstract for the award says: "This project
involves creating open source mathematical software that plays a key
roll in research in cryptography, number theory, geometry, and other
area. It promotes the progress of science by making many highly
optimized research-oriented algorithms widely available, and making it
easy to simultaneously create and work with objects defined in almost
any mathematical software package. This project also stimulates new
forms of collaboration between researchers in diverse areas of
mathematics, and between undegraduates, graduate students, and
professors. "

> So getting an NSF grant to develop software for a project and then
> opening the source (see Magnus, one of my sourceforge projects) is
> perfectly reasonable. It happens often. Indeed Macsyma was started
> that way, as near as I understand it. I can see where Sage could
> be funded under this model.
>
> But doing open source (that is, non-university, non-commercial,
> privately-supported) prior to the grant and getting continued work
> funded is unknown to me. I see that Axiom falls under this model.
> (Curiously, (D)ARPA and NSF funded Axiom when it was at IBM, which
> presumably had slightly more financial resources than me.)

I don't know of anything like that either.

...

> For planning assumptions, lets look out 30 years. At that point all
> of the previous (and some of the current) crop of computational
> mathematics people will have retired into management or something.
> Wolfram's family might wish to "cash out" and "monetize" the company.
> Maplesoft might have gone public and had a stock failure. In all,
> 50 years is a long time for any company to survive, especially on a
> single product. The loss of both MMA and Maple will leave a hole
> in computational mathematics.
>
> How do we prepare to deal with such a future event?
>
> We need to raise our standards. At the moment computational mathematics
> seems to me to be a mixture of 18th century hand-waving-proofs and 1960s
> "whew, got it to work!" software hacking. That was fine during the last
> 30 years as the whole subject went thru birth pangs. But now is the time
> to make this more of a science.

I agree; that's sort of what I David and I were trying to say in the
AMS opinion piece.

> To me that means that we need to classify, standardize, and organize
> the subject.
>
> We need to have NIST-like categories that cover various domains.
> The CATS test suite (along the lines of Abramowitz & Stegun) would
> have a wide range of problems sets with standard answers, specific
> behavior on branch cuts, boundary cases, etc. This would enable
> everyone to "substitute" one CAS for another with some confidence
> that they get reasonable answers. This is clearly not in the best
> interest of commercial systems but is clearly in the best interest
> of CAS users and of the science.
[...]
>
> We need well-documented, executable literature.  It should be possible
> to select a technical paper from this year's CAS conference that
[...]

I think we have pretty different visions for what we want to do with respect
to open source mathematics software.    That's probably
because my horizon is maybe 1 year (if that) and yours is 30 years.

> I believe that if such a system were available now there would be
> much less incentive for Universities to use closed source software.
> And, by implication, more work (more science) would be done using
> open software as a base. Eventually the loss of commercial versions
> that don't meet these standards would become a non-issue. Directly
> competing with heavily financed commercial systems cannot win and
> ultimately leads the science in the wrong long term direction.

Well I'm trying to directly compete with heavily financed commercial
systems.  I think you are wrong that one cannot win.  Linux, Firefox,
OpenOffice, etc., are all examples of direct competition with heavily
financed commercial systems, where they have all won, at least
where "win" means establish a large solid user base and be a viable
alternative to MS Windows, MS Internet Explorer, and MS Office.
There is nothing particularly special about mathematics software that
makes it winning in a similar sense impossible, as much as Wolfram
would argue that (as he often used to do in interviews I've read online).

> >Just out of curiosity does Axiom always have a 30 year horizon, or does
> >it become a 20 year horizon at some point?
>
> Given the large cost (e.g. $40 Million (although given the U.S. dollar
> that's not going to be much :-) ) and time (100s of man-years, see the
> axiom credit list) it is unlikely that we are going to develop whole
> new CAS systems as complex as Axiom from scratch. Thus we need to
> build on what exists. And we need to build for the long term.
>
> The 30 year horizon is a philosophy, not a timeline. In fact, it is
> intended to suggest raising our eyes away from the short-term thinking
> (e.g. competition with commercial software) and orient the discussion
> to the long term science. Computational mathematics is a new area but
> it is certainly here for the long haul.
>
> So "The 30 year horizon" is a sort of Zeno's game. You may get half
> way there but you'll never actually get all the way there. I intended
> the slogan to inspire, not limit.

OK, thanks for clarifying that.   I guess it's exactly intended as a
counterbalance
to my whole approach to mathematical software since I'm primarily
interested in "short-term thinking (e.g. competition with commercial software)".

\start
Date: Mon, 26 Nov 2007 07:10:28 -0800
From: Ed Borasky
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

William Stein wrote:
> Well I'm trying to directly compete with heavily financed commercial
> systems.  I think you are wrong that one cannot win.  Linux, Firefox,
> OpenOffice, etc., are all examples of direct competition with heavily
> financed commercial systems, where they have all won, at least
> where "win" means establish a large solid user base and be a viable
> alternative to MS Windows, MS Internet Explorer, and MS Office.

Well ... if you mean "*Red Hat* Linux has won a significant market share 
in servers", I agree. However, I don't think as a user that either 
Firefox or OpenOffice are of sufficient quality or maturity to be used 
on a Windows desktop, and I don't consider what they have accomplished 
to be a "win". They just aren't viable alternatives for anything but 
casual home use. I use them on Linux because they are there, but they 
aren't on my Windows desktop at work and probably never will be.

I *might* be able to get Axiom there briefly, but more than likely I 
would be told that I didn't need it and that if I did need a math 
package, that I needed to write a cost justification and do competitive 
bids for a commercial package. That's just the way the corporate world 
works.

> There is nothing particularly special about mathematics software that
> makes it winning in a similar sense impossible, as much as Wolfram
> would argue that (as he often used to do in interviews I've read online).

I disagree. Mathematics software is the most difficult software to 
write, and it's market is very limited. And *symbolic* mathematics 
software / theorem proving are more difficult to write than numeric 
software. I've never used Mathematica, and only briefly used Maple, so I 
can't really compare either of them with Axiom in the same sense as I 
compared OpenOffice with Microsoft Office, Firefox with Internet 
Explorer, or the Linux desktop with the Windows desktop in the context 
of a corporate workstation. But again, I'm guessing that people who can 
cost-justify Mathematica or Maple will keep them in business and "winning."

\start
Date: Mon, 26 Nov 2007 11:33:10 -0500
From: Doug Stewart
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: William Stein, Paul Zimmermann, David Joyner

Ed Borasky wrote:
> William Stein wrote:
>> Well I'm trying to directly compete with heavily financed commercial
>> systems.  I think you are wrong that one cannot win.  Linux, Firefox,
>> OpenOffice, etc., are all examples of direct competition with heavily
>> financed commercial systems, where they have all won, at least
>> where "win" means establish a large solid user base and be a viable
>> alternative to MS Windows, MS Internet Explorer, and MS Office.
>
> Well ... if you mean "*Red Hat* Linux has won a significant market 
> share in servers", I agree. However, I don't think as a user that 
> either Firefox or OpenOffice are of sufficient quality or maturity to 
> be used on a Windows desktop, and I don't consider what they have 
> accomplished to be a "win". They just aren't viable alternatives for 
> anything but casual home use. I use them on Linux because they are 
> there, but they aren't on my Windows desktop at work and probably 
> never will be.
I disagree with you on the statement
" I don't think as a user that either Firefox or OpenOffice are of 
sufficient quality or maturity to be used on a Windows desktop"

I won't use anything else!
Doug Stewart

\start
Date: Mon, 26 Nov 2007 13:01:33 -0500
From: Tim Daly
To: William Stein, Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

==> Tim Daly writes
>> I believe that if such a system were available now there would be
>> much less incentive for Universities to use closed source software.
>> And, by implication, more work (more science) would be done using
>> open software as a base. Eventually the loss of commercial versions
>> that don't meet these standards would become a non-issue. Directly
>> competing with heavily financed commercial systems cannot win and
>> ultimately leads the science in the wrong long term direction.


==> William Stein writes:
>Well I'm trying to directly compete with heavily financed commercial
>systems.  I think you are wrong that one cannot win.  Linux, Firefox,
>OpenOffice, etc., are all examples of direct competition with heavily
>financed commercial systems, where they have all won, at least
>where "win" means establish a large solid user base and be a viable
>alternative to MS Windows, MS Internet Explorer, and MS Office.
>There is nothing particularly special about mathematics software that
>makes it winning in a similar sense impossible, as much as Wolfram
>would argue that (as he often used to do in interviews I've read online).
>
>OK, thanks for clarifying that.  I guess it's exactly intended as a
>counterbalance to my whole approach to mathematical software since I'm
>primarily interested in "short-term thinking (e.g. competition with
>commercial software)".


==> Ed Borasky writes:
>Well ... if you mean "*Red Hat* Linux has won a significant market share 
>in servers", I agree. However, I don't think as a user that either 
>Firefox or OpenOffice are of sufficient quality or maturity to be used 
>on a Windows desktop, and I don't consider what they have accomplished 
>to be a "win". They just aren't viable alternatives for anything but 
>casual home use. I use them on Linux because they are there, but they 
>aren't on my Windows desktop at work and probably never will be.
>
>I *might* be able to get Axiom there briefly, but more than likely I 
>would be told that I didn't need it and that if I did need a math 
>package, that I needed to write a cost justification and do competitive 
>bids for a commercial package. That's just the way the corporate world 
>works.
>
>> There is nothing particularly special about mathematics software that
>> makes it winning in a similar sense impossible, as much as Wolfram
>> would argue that (as he often used to do in interviews I've read online).
>
>I disagree. Mathematics software is the most difficult software to 
>write, and it's market is very limited. And *symbolic* mathematics 
>software / theorem proving are more difficult to write than numeric 
>software. I've never used Mathematica, and only briefly used Maple, so I 
>can't really compare either of them with Axiom in the same sense as I 
>compared OpenOffice with Microsoft Office, Firefox with Internet 
>Explorer, or the Linux desktop with the Windows desktop in the context 
>of a corporate workstation. But again, I'm guessing that people who can 
>cost-justify Mathematica or Maple will keep them in business and "winning."


Clearly you've not studied your "Art of War" by Sun Tsu. :-)
I paraphrase:

The best way to win the (commercial) war is not to fight it.
A good general wins without fighting. Picture the whole game as
a fight on a large, open field with you facing the 3 Ms, MMA,
Maple, Matlab.

A frontal attack against a strongly held point never wins.  You are
trying a direct head-to-head competition against a well financed,
heavily backed position. As Ed points out, even if you *could* match
the 3Ms point for point in the usual checklist feature game there are
still forces which make it difficult, if not impossible, for people to
use your software. You plan to march onto the field of battle,
confront the enemy strength-to-strengh, and win by force of arms. 
That's not strategic thinking, and clearly not a successful strategy.

You let the enemy define your tactics.  That is, if MMA develops a new
parallel matrix multiply (opening a new wing of the battle), you must
turn to confront this and apply effort to develop a similar checklist
point. Since they are larger, faster, and better financed it is
unlikely that you can match them continuously on every point. Linux
plays this game, and loses, on the desktop. That's not strategic
thinking, and clearly not a successful strategy.

You train recruits for your enemy. Because you fight the same battle
on the same turf with the same tactics, the people you lose to industry
are perfectly trained to compete against you. Thus the person who
writes the great new prototype harmonic analysis software for his
thesis (giving you a new checklist point nobody competes with), then
this same person is perfect for the 3Ms to hire. In fact, the best use
of his talent would be to develop a better version of his thesis work
and add it as a new, better checklist feature point. Thus, you trained
and financed your enemy. That's not strategic thinking, and clearly
not a successful strategy.

You give away your material freely to your enemy. Because you work in
open source and you encourage publication of your work the enemy can
see everything. But the publications are tiny (5 pages) and the thesis
work is obscure so it will take much time to convert this into a
useful "product". The 3Ms have the idea, the time, and the money.  You
gave it all to them because you published the idea, trained the
people, and bought 3M's software "for the department". That's not
strategic thinking, and clearly not a successful strategy.

You let the enemy use your own strength against you. What's to stop
the 3Ms from becoming useable with the Sage front end? How hard would
it be for them to define "plug-ins" that either use the MMA workbook
browser or the full Maple engine? If mathml allows one to transfer
(content-free) equations from one system to another, cannot one of
those systems be one of the 3Ms?  Thus they gut your whole system.
They can make the claim that they "work with Sage" which allows them
to sell licenses to locations where you've "won". That's not strategic
thinking, and clearly not a successful strategy.

I don't know why you've chosen to benefit the enemy but I can't prevent it.

I could go on but Tsu's book is small, cheap, and widely available.





I also would like to replace these commercial systems with open
systems.  (Actually, I'd like to replace commerce with science.)
However, my plan is to change the war so that the 3Ms cannot compete
and their field of battle, which they strongly hold, is irrelevant. By
redefining what the "best of breed" systems mean, and by defining them
so that commercial systems cannot compete, the battle is won without a
fight.

Commercial systems cannot compete against a fully documented, literate
system. They cannot compete in proving their software is correct if they
cannot show the software. They cannot compete if there are standards 
that every system must meet in order to ensure that ANY system can be
used that fulfills the standard.

Clearly, systems that are fully documented, literate, proven, and
standards-conforming are "best of breed". And they also happened to
be "open" but that's just a required fact, not a feature.

A frontal attack against a strongly held point never wins. But I don't
plan to attack. I have redefined the fight so they can't compete.

You let the enemy define your tactics. But I don't care about their
tactics. I can't prevent short term wins. But battles do not decide
the outcome of wars. 

You train recruits for your enemy. Training people to write fully
literate papers that just drag-and-drop means that they are trained
to publish everything which is a skill that the 3Ms can't use. By
training them to use, modify, and enhance each other's work and build 
on prior science the 3Ms have to worry about huge legal issues whereas
you can just ask me for permission to use (or collaborate with me) on
a new "release" of my literate paper and algorithm.

You give away your material freely to your enemy. But of what use is
conforming to a standard that allows any system to replace any other?
This cannot benefit the 3Ms. And what use is a proof since they cannot
SHOW the code necessary to support the proof? And what use is a thesis
that can be "drag-and-dropped" onto an open system? It already works
and can be quickly enhanced whereas the 3Ms need to rewrite it.

You let the enemy use your own strength against you. The Axiom front
end is the same as the Axiom back end. It's all "of a piece" so that
viewing the documentation and the code are all a single thing. When
you read the documentation like a book (ala Knuth or Queinnec) you
learn the whole system. The 3Ms cannot do this. And Axiom equations
need to carry the type because that's where the meaning is. Thus
mathml isn't a reasonable transfer mechanism and cannot be trojaned.

I could go on but Tsu's book is small, cheap, and widely available.



The 30 year horizon seems like an impossible dream goal. Read Sun Tsu.
It is clear that the fight with the 3Ms will last at least 30 years no
matter what strategy is used. But the strategy you've chosen actually
works for them and against you. My strategy makes the 3Ms useless toys. 

Raise your eyes to the 30 year horizon. 
Choose a winning strategy. Follow it.

\start
Date: Mon, 26 Nov 2007 09:12:49 -0800
From: Arthur Ralfs
To: list
Subject: re: AMS Notices: Open Source Mathematical Software

Ed Borasky wrote:
>
> Well ... if you mean "*Red Hat* Linux has won a significant market
> share in servers", I agree. However, I don't think as a user that
> either Firefox or OpenOffice are of sufficient quality or maturity to
> be used on a Windows desktop, and I don't consider what they have
> accomplished to be a "win". They just aren't viable alternatives for
> anything but casual home use. I use them on Linux because they are
> there, but they aren't on my Windows desktop at work and probably
> never will be.
>
Do you mean to say that you think IE is better than Firefox?  Hard to
imagine.

\start
Date: Mon, 26 Nov 2007 12:53:25 -0500
From: Bill Page
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software

On 11/26/07, Ed Borasky wrote:
> ...
> Well ... if you mean "*Red Hat* Linux has won a significant market
> share in servers", I agree. However, I don't think as a user that either
> Firefox or OpenOffice are of sufficient quality or maturity to be used
> on a Windows desktop, and I don't consider what they have
> accomplished to be a "win". They just aren't viable alternatives for
> anything but casual home use. I use them on Linux because they
> are there, but they aren't on my Windows desktop at work and
> probably never will be.
> ...

I cannot imagine how you could reach that conclusion. As a user of
both Microsoft products and FireFox and OpenOffice on Windows in a
production work environment I consider OpenOffice and FireFox very
clearly superior to what Microsoft produces.

\start
Date: Mon, 26 Nov 2007 12:14:47 -0800
From: William Stein
To: Tim Daly
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner, Dennis Stein

On Nov 26, 2007 10:01 AM, Tim Daly wrote:
> ==> Ed Borasky writes:

> >> There is nothing particularly special about mathematics software that
> >> makes it winning in a similar sense impossible, as much as Wolfram
> >> would argue that (as he often used to do in interviews I've read online).
> >
> >I disagree. Mathematics software is the most difficult software to
> >write, and it's market is very limited. And *symbolic* mathematics
> >software / theorem proving are more difficult to write than numeric
> >software. I've never used Mathematica, and only briefly used Maple, so I
> >can't really compare either of them with Axiom in the same sense as I
> >compared OpenOffice with Microsoft Office, Firefox with Internet
> >Explorer, or the Linux desktop with the Windows desktop in the context
> >of a corporate workstation. But again, I'm guessing that people who can
> >cost-justify Mathematica or Maple will keep them in business and "winning."

Mathematical software is indeed difficult to write.  You're right --
what I hope to accomplish with the Sage project is impossible.  I
don't care; I'm going to do it anyways.

> Clearly you've not studied your "Art of War" by Sun Tsu. :-)

Actually I have.   Evidently my interpretation of it is much different
than yours.

> A frontal attack against a strongly held point never wins.  You are
> trying a direct head-to-head competition against a well financed,
> heavily backed position. As Ed points out, even if you *could* match
> the 3Ms point for point in the usual checklist feature game there are
> still forces which make it difficult, if not impossible, for people to
> use your software. You plan to march onto the field of battle,
> confront the enemy strength-to-strengh, and win by force of arms.
> That's not strategic thinking, and clearly not a successful strategy.
>
> You let the enemy define your tactics.  That is, if MMA develops a new
> parallel matrix multiply (opening a new wing of the battle), you must
> turn to confront this and apply effort to develop a similar checklist
> point. Since they are larger, faster, and better financed it is
> unlikely that you can match them continuously on every point. Linux
> plays this game, and loses, on the desktop. That's not strategic
> thinking, and clearly not a successful strategy.
>
> You train recruits for your enemy. Because you fight the same battle
> on the same turf with the same tactics, the people you lose to industry
> are perfectly trained to compete against you. Thus the person who
> writes the great new prototype harmonic analysis software for his
> thesis (giving you a new checklist point nobody competes with), then
> this same person is perfect for the 3Ms to hire. In fact, the best use
> of his talent would be to develop a better version of his thesis work
> and add it as a new, better checklist feature point. Thus, you trained
> and financed your enemy. That's not strategic thinking, and clearly
> not a successful strategy.
>
> You give away your material freely to your enemy. Because you work in
> open source and you encourage publication of your work the enemy can
> see everything. But the publications are tiny (5 pages) and the thesis
> work is obscure so it will take much time to convert this into a
> useful "product". The 3Ms have the idea, the time, and the money.  You
> gave it all to them because you published the idea, trained the
> people, and bought 3M's software "for the department". That's not
> strategic thinking, and clearly not a successful strategy.
>
> You let the enemy use your own strength against you. What's to stop
> the 3Ms from becoming useable with the Sage front end?

Nothing.  In fact, one of the main features of the Sage front end
already is that it can be used with the 4Ms (don't dismiss Magma,
which belongs in there -- it's very good quality commercial software).

>  How hard would
> it be for them to define "plug-ins" that either use the MMA workbook
> browser or the full Maple engine?

Trivial, since we already do that.

> If mathml allows one to transfer
> (content-free) equations from one system to another, cannot one of
> those systems be one of the 3Ms?

Yes.

> Thus they gut your whole system.

No they don't.  Sage is GPL'd.  Any improvements or changes they make
to Sage must be given back.

> They can make the claim that they "work with Sage" which allows them
> to sell licenses to locations where you've "won". That's not strategic
> thinking, and clearly not a successful strategy.
> I don't know why you've chosen to benefit the enemy
> but I can't prevent it.

True, you can't.  But honestly I really don't see the 4M's as the
enemy.  They are four high quality valuable tools for mathematical
computation.  I love mathematics and doing computation in the context
of mathematics, and at some level I really like using any mathematical
software.  With Sage I want to provide a viable free open source
alternative, not put the 4M's out of business.  Software is not a zero
sum game.  Especially in research that relies on computation -- trying
to find the right conjecture -- it can be quite valuable to compare
output produced by several different programs.

> I also would like to replace these commercial systems with open
> systems.  (Actually, I'd like to replace commerce with science.)
> However, my plan is to change the war so that the 3Ms cannot compete
> and their field of battle, which they strongly hold, is irrelevant. By
> redefining what the "best of breed" systems mean, and by defining them
> so that commercial systems cannot compete, the battle is won without a
> fight.
>
> Commercial systems cannot compete against a fully documented, literate
> system. They cannot compete in proving their software is correct if they
> cannot show the software. They cannot compete if there are standards
> that every system must meet in order to ensure that ANY system can be
> used that fulfills the standard.
> Clearly, systems that are fully documented, literate, proven, and
> standards-conforming are "best of breed". And they also happened to
> be "open" but that's just a required fact, not a feature.

Whether or not a system can compete is determined by what actual real
people really want and can afford when teaching or doing research.
It's not at all clear to me that actual research mathematicians, teachers
and engineers  want what you're describing above more than the
other options they will have available.  In fact, I think it highly unlikely.

> A frontal attack against a strongly held point never wins. But I don't
> plan to attack. I have redefined the fight so they can't compete.
>
> You let the enemy define your tactics. But I don't care about their
> tactics. I can't prevent short term wins. But battles do not decide
> the outcome of wars.
>
> You train recruits for your enemy. Training people to write fully
> literate papers that just drag-and-drop means that they are trained
> to publish everything which is a skill that the 3Ms can't use. By
> training them to use, modify, and enhance each other's work and build
> on prior science the 3Ms have to worry about huge legal issues whereas
> you can just ask me for permission to use (or collaborate with me) on
> a new "release" of my literate paper and algorithm.
>
> You give away your material freely to your enemy. But of what use is
> conforming to a standard that allows any system to replace any other?
> This cannot benefit the 3Ms. And what use is a proof since they cannot
> SHOW the code necessary to support the proof? And what use is a thesis
> that can be "drag-and-dropped" onto an open system? It already works
> and can be quickly enhanced whereas the 3Ms need to rewrite it.
>
> You let the enemy use your own strength against you. The Axiom front
> end is the same as the Axiom back end. It's all "of a piece" so that
> viewing the documentation and the code are all a single thing. When
> you read the documentation like a book (ala Knuth or Queinnec) you
> learn the whole system. The 3Ms cannot do this. And Axiom equations
> need to carry the type because that's where the meaning is. Thus
> mathml isn't a reasonable transfer mechanism and cannot be trojaned.
>
> I could go on but Tsu's book is small, cheap, and widely available.
>
>
>
> The 30 year horizon seems like an impossible dream goal. Read Sun Tsu.
> It is clear that the fight with the 3Ms will last at least 30 years no
> matter what strategy is used. But the strategy you've chosen actually
> works for them and against you. My strategy makes the 3Ms useless toys.

You're right, the strategy I'm using may benefit the 4M's.  That
doesn't bother me at all, since my first allegiance is to mathematics
and mathematical research, and I think having more options and more
support for mathematical software tools is a plus for mathematics,
even if some of them are commercial.  I'm just going to try to make
sure at least one of the tools is simultaneous open and free, and can
do what everyday people need.  For way too long it's been an
embarrassment to "pure" mathematics that we don't have such software
yet.  Also, it is bad for mathematics that it is difficult for the
4M's plus other systems like Axiom to work together -- one of the
three main goals for Sage is to make such cooperation much easier,
because that benefits mathematics as a whole.

\start
Date: Mon, 26 Nov 2007 12:24:27 -0800
From: Ed Borasky
To: Arthur Ralfs
Subject: re: AMS Notices: Open Source Mathematical Software

Arthur Ralfs wrote:
> Ed Borasky wrote:
>> Well ... if you mean "*Red Hat* Linux has won a significant market
>> share in servers", I agree. However, I don't think as a user that
>> either Firefox or OpenOffice are of sufficient quality or maturity to
>> be used on a Windows desktop, and I don't consider what they have
>> accomplished to be a "win". They just aren't viable alternatives for
>> anything but casual home use. I use them on Linux because they are
>> there, but they aren't on my Windows desktop at work and probably
>> never will be.
>>
> Do you mean to say that you think IE is better than Firefox?  Hard to
> imagine.

I'm saying:

1. Firefox is *not* better than IE 7 on the Windows platform for any 
reasonable definition of "better". In particular, the hype about Firefox 
being more secure than IE is unsubstantiated and cannot in fact be 
proven or falsified.

2. In a corporation or other accountability hierarchy, people aren't 
always free to experiment with potential improvements. In fact, the 
epidemic of malware, cyber-terrorism and other things of that ilk have 
led to very restrictive IT policies. Even if Firefox were better than 
IE, it would still face an uphill battle in this arena.

Are you saying that OpenOffice is "better" than Microsoft Office on any 
dimension other than price? :)

\start
Date: Mon, 26 Nov 2007 12:38:47 -0800
From: Ed Borasky
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner, Dennis Stein

William Stein wrote:

> Whether or not a system can compete is determined by what actual real
> people really want and can afford when teaching or doing research.
> It's not at all clear to me that actual research mathematicians, teachers
> and engineers  want what you're describing above more than the
> other options they will have available.  In fact, I think it highly unlikely.

I can tell you what I want, but it's not something I think I'll ever see 
in my lifetime. I want a system that makes my research understandable as 
well as provably correct. I view what computational math will be in 20 - 
30 years, assuming that the hardware keeps on its present growth path, 
as the ability to solve larger problems of the same kind we solve now.

As I already noted, I haven't used Mathematica at all and Maple only 
briefly in the context of paid work. I have, however, used Excel, 
Minitab, and R extensively there, and will be moving on to SPSS in the 
near future. None of these tools, with the possible exception of R, 
really cater to the concepts of "literate programming", or, as the R 
people call it, "reproducible research". The point, however, is that a 
reproducible research "compendium" or literate program has to be 
readable and understood by the people who pay the bills.

\start
Date: Mon, 26 Nov 2007 15:49:30 -0500
From: Bill Page
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software

On 11/26/07, Ed Borasky Ed Borasky wrote:
>
> I'm saying:
>
> 1. Firefox is *not* better than IE 7 on the Windows platform for any
> reasonable definition of "better". In particular, the hype about Firefox
> being more secure than IE is unsubstantiated and cannot in fact be
> proven or falsified.
>

I disagree. I am not interested in security when I use a web browser.
I am interested in performance, compatibility and convenience. I think
Firefox is superior to IE 7 in all these respects. Security at the
level of the web browser is too late.

> 2. In a corporation or other accountability hierarchy, people aren't
> always free to experiment with potential improvements. In fact, the
> epidemic of malware, cyber-terrorism and other things of that ilk
> have led to very restrictive IT policies. Even if Firefox were better
> than IE, it would still face an uphill battle in this arena.
>

I think it is only short-sighted IT policies that lead to this situation.

> Are you saying that OpenOffice is "better" than Microsoft Office on any
> dimension other than price? :)
>

Yes. In our office we often use OpenOffice/StarOffice just to
"clean-up" documents created using Microsoft Word users. Where
possible I encourage people to use OpenOffice but most users are very
very conservative and will only use what they think they already know.

\start
Date: Mon, 26 Nov 2007 13:25:01 -0800
From: Arthur Ralfs
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software


Ed Borasky wrote:
> Arthur Ralfs wrote:
>> Ed Borasky wrote:
>>> Well ... if you mean "*Red Hat* Linux has won a significant market
>>> share in servers", I agree. However, I don't think as a user that
>>> either Firefox or OpenOffice are of sufficient quality or maturity to
>>> be used on a Windows desktop, and I don't consider what they have
>>> accomplished to be a "win". They just aren't viable alternatives for
>>> anything but casual home use. I use them on Linux because they are
>>> there, but they aren't on my Windows desktop at work and probably
>>> never will be.
>>>
>> Do you mean to say that you think IE is better than Firefox?  Hard to
>> imagine.

>
> I'm saying:
>
> 1. Firefox is *not* better than IE 7 on the Windows platform for any
> reasonable definition of "better". In particular, the hype about
> Firefox being more secure than IE is unsubstantiated and cannot in
> fact be proven or falsified.
>
> 2. In a corporation or other accountability hierarchy, people aren't
> always free to experiment with potential improvements. In fact, the
> epidemic of malware, cyber-terrorism and other things of that ilk have
> led to very restrictive IT policies. Even if Firefox were better than
> IE, it would still face an uphill battle in this arena.
>
> Are you saying that OpenOffice is "better" than Microsoft Office on
> any dimension other than price? :)
>
No.  About the only time I use OpenOffice is to open an MS Office
document that somebody sends me.

\start
Date: Mon, 26 Nov 2007 13:55:50 -0800
From: Arthur Ralfs
To: Tim Daly
Subject: content mathml was re: AMS Notices: Open Source Mathematical Software

root wrote:
> You let the enemy use your own strength against you. The Axiom front
> end is the same as the Axiom back end. It's all "of a piece" so that
> viewing the documentation and the code are all a single thing. When
> you read the documentation like a book (ala Knuth or Queinnec) you
> learn the whole system. The 3Ms cannot do this. And Axiom equations
> need to carry the type because that's where the meaning is. Thus
> mathml isn't a reasonable transfer mechanism and cannot be trojaned.
>
>   
Tim,

I found your Sun Tsu analysis interesting.  I have been thinking that
I would eventually write a content mathml package for Axiom partly
because of discussions I've seen here.  However I have also wondered
"why bother, i.e. why not just let Axiom handle the semantics?"  Now
you've added a new (for me) slant.  Do you think content mathml would
amount to a Trojan horse?

\start
Date: Mon, 26 Nov 2007 18:21:49 -0500
From: Tim Daly
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner, Dennis Stein

...[snip]...
> True, you can't.    But honestly I really don't see the 4M's as the
> enemy.  

"Enemy" is used in the metaphorical sense. You have chosen these
systems to be "the competition", thus, the "enemy" in the
metaphor. That does not imply that the (n)Ms are evil in any way.
I quite like the fact that they are keeping these useful ideas alive.

The point I was trying to make is that what you choose as your strategy
defines everything. You've chosen the nMs as your "competition" and
that focus will shape your efforts. Unfortunately it appears to me
that your strategy cannot achieve the goals you set, only serving
to make the situation worse.

I've chosen to focus on building a "best of breed", fully literate,
proven system that can be easily extended with fully open literature
and conforms to a set of mathematically well-defined standards.
What the nMs actually do is of little interest. My goals are also
unachievable but I still find them of interest.

Either choice is fine. We're clearly not competing and I'll do 
everything I can to help Sage along. In fact, I'd really like it
if Sage tried to become literate.

>No they don't.  Sage is GPL'd.  Any improvements or changes they make
>to Sage must be given back.

They won't improve Sage, they will use Sage as a sales tool to find
people who might be interested in computational mathematics.

Sage is an excellent idea and may become the lingua-franca of CAS
systems. But vital sections of its capabilities will still be black
box since they are commercial. Your strategy is useful but won't ever
succeed in gaining on the competition since every "sale" you make
becomes another "prospect" for the nMs.

In fact, come to think of it, this might make a useful argument to
try to get corporate funding :-) "We're your best sales tool!"

>Whether or not a system can compete is determined by what actual real
>people really want and can afford when teaching or doing research.

Actually not. From my experience the nMs offer site licenses at 
Universities (and, I believe "all of France" in some cases). The 
"cost" is overhead (your 55%) and has nothing to do with what you
can afford. I'd bet you have MMA and/or Maple and you didn't spend
project funds on either one. The NSF, INRIA, and others cover it.
These are the same people who won't fund Axiom because "it competes
with commercial software". Which shows that they don't understand
that Axiom is NOT trying to compete; and that funding competition
to commercial software implies funding BOTH sides of the effort.

>It's not at all clear to me that actual research mathematicians,
>teachers and engineers want what you're describing above more than
>the other options they will have available.  In fact, I think it
>highly unlikely.

In the long term (think next century) does it benefit computational
mathematics if the fundamental algorithms are "black box"? It may
benefit teachers, engineers, and other professionals. But does it
benefit the computational science? How much damage will be done to
progress in the field as each "fundamental" commercial system
eventually dies on the corporate deathbed? Suppose someone creates a
closed, commercial, really fast Groebner basis algorithm, does not
publish the details, and then the code dies. It can happen. Macsyma
had some of the best algorithms and they are lost.

Way back in history there are stories of people who found algorithms
(can't remember any names now) but they didn't publish them. In order
to prove they had found one you sent them your problem and they sent
you a solution. How far would mathematics have developed if this 
practice still existed today? Well, I ask how far computational
mathematics will develop if we continue the same practice. Define
the practice as outside your interest and ignore those who do it.

Anyway, this is all "angels on pinheads" debate. 

The chances of funding Axiom are exactly equal to the chances of me
winning the lottery. I play the numbers 3 14 15 92 65 35 religiously :-)

I did appreciate your publication though. Hopefully someone will read
it and show up with funding for Sage.

\start
Date: Mon, 26 Nov 2007 18:36:56 -0500
From: Tim Daly
To: Arthur Ralfs
Subject: Re: content mathml was re: AMS Notices: Open Source Mathematical Software

>root wrote:
>> You let the enemy use your own strength against you. The Axiom front
>> end is the same as the Axiom back end. It's all "of a piece" so that
>> viewing the documentation and the code are all a single thing. When
>> you read the documentation like a book (ala Knuth or Queinnec) you
>> learn the whole system. The 3Ms cannot do this. And Axiom equations
>> need to carry the type because that's where the meaning is. Thus
>> mathml isn't a reasonable transfer mechanism and cannot be trojaned.

Arthur wrote:
>I found your Sun Tsu analysis interesting.  I have been thinking that
>I would eventually write a content mathml package for Axiom partly
>because of discussions I've seen here.  However I have also wondered
>"why bother, i.e. why not just let Axiom handle the semantics?"  Now
>you've added a new (for me) slant.  Do you think content mathml would
>amount to a Trojan horse?

I think that content mathml is a very difficult problem where a lot
of effort goes to die. 

Consider what it might mean to take the semantics of an expression 
in Axiom, box it up, export it, import it into nM, re-export it
to content mathml, and then re-import it into Axiom, whole and intact.

Expressions like E=MC^2 are icons. They have no meaning of themselves
and are just pictures to remind us of the meaning. All of the meaning
exists in the surrounding paragraphs. Most systems manipulate these
icons thinking they are doing mathematics. 

Axiom captures the semantics of an expression (or tries to) in the 
type information. Think of the type as the "paragraphs surrounding
the icon containing the meaning". Is 3 an integer or a number from
primeField(7)?

nM, and almost every other system, has no way to represent the
meaning. Content mathml tries to create these kinds of meaning
using external libraries. Unfortunately these get lost once the
expression is imported since the internals have no way to carry
the information around or keep it accurate.

At best I can see content mathml as a storage mechanism but I can
more easily do that in Axiom by writing out the lisp data structures.

Mike Dewar has done a lot of work in this area and might have more
well thought out opinions.

\start
Date: 26 Nov 2007 18:15:50 -0600
From: Gabriel Dos Reis
To: William Stein
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner, Dennis Stein

William Stein writes:

[...]

| You're right, the strategy I'm using may benefit the 4M's.  That
| doesn't bother me at all, since my first allegiance is to
| mathematics and mathematical research, and I think having more
| options and more support for mathematical software tools is a plus
| for mathematics, even if some of them are commercial.

Hear! Hear! Hear!

If the plan I'm flying is built based on simulations with commercial
mathematical software tools, I surely want them to be the best.

\start
Date: Mon, 26 Nov 2007 20:06:35 -0800
From: Ed Borasky
To: Tim Daly
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, William Stein, David Joyner, Dennis Stein

root wrote:
> The NSF, INRIA, and others cover it.
> These are the same people who won't fund Axiom because "it competes
> with commercial software". Which shows that they don't understand
> that Axiom is NOT trying to compete; and that funding competition
> to commercial software implies funding BOTH sides of the effort.

Ah, but given the difficulty of writing said software with any licensing 
scheme, whether it be closed-source commercial, "academic free but 
industrial users pay", GPL, BSD, MIT, etc., why would a non-profit 
organization like the NSF want to get dragged into licensing disputes, 
questions about tax exemptions, intellectual property battles, and other 
things that a society full of attorneys "features"? The world is 
littered with the corpses of organizations that sued other organizations 
bigger than they were. I don't know about INRIA, but I really doubt the 
NSF could withstand a lawsuit from Wolfram or Maplesoft.

> In the long term (think next century) does it benefit computational
> mathematics if the fundamental algorithms are "black box"?

Mathematics has a long history of independent discoveries by researchers 
working on different problems. Think of Gauss and Legendre, for example, 
and least squares. In other words, fundamental algorithms will get 
re-invented. The FFT is another example -- radio engineers were doing 
24-point DFTs using essentially the FFT algorithm long before Cooley and 
Tukey, and both Runge and Lanczos published equivalents.

> Suppose someone creates a
> closed, commercial, really fast Groebner basis algorithm, does not
> publish the details, and then the code dies. It can happen. Macsyma
> had some of the best algorithms and they are lost.

1. What do you think the real chances are of a "really fast Groebner 
basis algorithm" are? I'm by no means an expert, but I thought the 
computational complexity odds were heavily stacked against one.

2. What did Macsyma have that Vaxima and Maxima didn't/don't?
> 
> Way back in history there are stories of people who found algorithms
> (can't remember any names now) but they didn't publish them. In order
> to prove they had found one you sent them your problem and they sent
> you a solution. How far would mathematics have developed if this 
> practice still existed today?

I think I've made the case that they would get re-invented.

\start
Date: 26 Nov 2007 23:01:56 -0600
From: Gabriel Dos Reis
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, William Stein, David Joyner, Dennis Stein

Ed Borasky writes:

[...]

| > Suppose someone creates a
| > closed, commercial, really fast Groebner basis algorithm, does not
| > publish the details, and then the code dies. It can happen. Macsyma
| > had some of the best algorithms and they are lost.
| 
| 1. What do you think the real chances are of a "really fast Groebner
| basis algorithm" are? I'm by no means an expert, but I thought the
| computational complexity odds were heavily stacked against one.

Indeed.  There is an inherent complexity issue.  So what people do is
to optimize for certain classes of systems.  So, I don't know what
"really fast Groebner basis algorithm" could possibly mean.

\start
Date: Mon, 26 Nov 2007 20:53:37 -0800
From: William Stein
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Paul Zimmermann, David Joyner

On Nov 26, 2007 8:06 PM, Ed Borasky Ed Borasky wrote:
> root wrote:
> > The NSF, INRIA, and others cover it.
> > These are the same people who won't fund Axiom because "it competes
> > with commercial software". Which shows that they don't understand
> > that Axiom is NOT trying to compete; and that funding competition
> > to commercial software implies funding BOTH sides of the effort.
>
> Ah, but given the difficulty of writing said software with any licensing
> scheme, whether it be closed-source commercial, "academic free but
> industrial users pay", GPL, BSD, MIT, etc., why would a non-profit
> organization like the NSF want to get dragged into licensing disputes,
> questions about tax exemptions, intellectual property battles, and other
> things that a society full of attorneys "features"? The world is
> littered with the corpses of organizations that sued other organizations
> bigger than they were. I don't know about INRIA, but I really doubt the
> NSF could withstand a lawsuit from Wolfram or Maplesoft.

(1) The NSF does fund research that directly results in open source
mathematical software development.    They've funded Macaulay2,
they've funded me, and they've funded other scientists. NIH also
funds software development:
   http://grants.nih.gov/grants/guide/pa-files/par-05-057.html

(2) Regarding NSF withstanding a lawsuit -- I don't know.
NSF is a very powerful and impressive foundation.  They have
a 6 billion dollar annual budget:
   http://nsf.gov/about/congress/110/highlights/cu07_0308.jsp#final
compared to Mathematica which probably has maybe $150
million per year in revenue.

(3) People at the NSF do think about issues such as
"licensing disputes, questions about tax exemptions, intellectual
property battles, and other things", and take them seriously.

> > In the long term (think next century) does it benefit computational
> > mathematics if the fundamental algorithms are "black box"?
>
> Mathematics has a long history of independent discoveries by researchers
> working on different problems. Think of Gauss and Legendre, for example,
> and least squares. In other words, fundamental algorithms will get
> re-invented. The FFT is another example -- radio engineers were doing
> 24-point DFTs using essentially the FFT algorithm long before Cooley and
> Tukey, and both Runge and Lanczos published equivalents.

I think has a point; though there are examples like yours, there are also
many interesting powerful algorithms that do exist only in closed proprietary
software, and it could be a long time until they are rediscovered and
published.

> > Suppose someone creates a
> > closed, commercial, really fast Groebner basis algorithm, does not
> > publish the details, and then the code dies. It can happen. Macsyma
> > had some of the best algorithms and they are lost.
>
> 1. What do you think the real chances are of a "really fast Groebner
> basis algorithm" are? I'm by no means an expert, but I thought the
> computational complexity odds were heavily stacked against one.

Since "really fast" isn't well defined, I'll just give you a practical example
of exactly this.   For the last 5 years there have been exactly
two implementations of a "really fast Groebner basis algorithm", namely
F4 (and its variant F5).  One implementation is closed source and is
only available via purchasing Magma.  The other is closed source and
is only available via purchasing Maple.     The one in Magma took
Allan Steel (who is in my mind easily one of the top 5 mathematical
software coders in the world today) about 5 years to implement, even with
full access to all the papers that Faugere wrote on his algorithm.  The
one in Maple was implemented by Faugere, and is of course also closed
source.   There have been numerous (maybe a dozen?) attempts by
open source authors to implement a really usable F4, but nobody has
yet come close so far as I can tell.   (Ralf Phillip Weinmann is working
on a promising open source one right now, maybe...)

The F4 in Magma is really incredibly fast at many standard benchmark
problems.   See the timings here:
   http://magma.maths.usyd.edu.au/users/allan/gb/

\start
Date: Tue, 27 Nov 2007 11:47:20 +0100
From: Michel Lavaud
To: Gabriel Dos Reis
Subject: re: AMS Notices: Open Source Mathematical Software

> If the plane I'm flying is built based on simulations with commercial
> mathematical software tools, I surely want them to be the best.
>   
If the plane I'm flying is built based on simulations with commercial 
mathematical software tools, whose accuracy is guaranteed in the usual 
way, i.e. no guarantee at all except refund for the price of the 
software whatever consequences and it is forbidden to get the source 
code to check if it is correct -  then I will for sure take the next 
plane, if it has been built with free Open Source software :-)

One ought not to forget that some big catastrophes were the direct 
consequences of minute software errors, several in  rocket launchers 
(including crash of ArianeV),  a complete oil research platform that 
sunk into the sea, etc. and probably many others that were not detected 
because they used commercial (closed source) software so that nobody was 
able to detect a posteriori the origin of the catastrophe ("Pas vu, pas 
pris" - not seen, not caught)

I think that those who accept the use of commercial software in 
scientific work, are bringing  science 200 years backward, at the time 
when mathematicians were not too fond of rigorous proofs, and where 
Fermat (for example) could present an intuition of a result as a 
"theorem". If computers had existed at that time, we would have had 
maybe a "Fermat Software Corporation" that would have sold a software 
implementing instances of Fermat theorem, and all the research in 
connected fields  that has been done to prove Fermat's theorem in the 
last 200 years would never have been done and no more results 
discovered, because a real, complete proof would not be considered as a 
new result : indeed, if one accepts commercial software in scientific 
work, the logical answer to the submission of a complete proof of the 
underlying theorem is that "the result is already known since it is 
included in the Fermat software", and thus the complete, rogorous proof 
cannot be published in a scientific journal as a research result, since 
it is not considered as a new one. The same kind of argument coul be 
extended to the 4 color conjecture, the Poincare conjecture, etc. In the 
latter case, instead of providing a Fields medal to Perelman for the 
definitive proof, he would have get the answer " Hey you stupid, it's 
already known for 100 years !"

Suppose a scientist sends to a referee a theorem with no proof for a 
lemma ; if the referee asks for the proof and the scientist answers 
"well no, I will not give you the proof and if you try to find it, I 
will sue you because somebody could steal my result that is worth one 
million of dollars" then what ought to be the answer of the referee ? 
"Sorry sir, no proof, no publication" ? Or "Oh, yes you are right, if it 
is worth so many bucks, I cannot decently ask you to unveil your proof 
and compromise the selling of your result to a software corporation, and 
maybe endanger employments in it". ?

Personnally, I think the only valid, scientific way is the first one : 
any work proposed for publication that uses commercial software ought to 
be rejected by the referee, unless it says explicitly and honestly that 
it used commercial, non-provable software, so that another researcher 
can then improve on the article later, and publish another article using 
a completely Open Source software and provide a complete, rigorous, 
verifiable proof..

In my opinion, the real and only problem with funding Open Source 
software like Axiom (and Maxima, Lyx, TeXmacs etc. and all other OS 
software useful for scientific work) lies in the scientific community 
itself  : many scientists are not willing to accept the preceding 
argument (reject articles that use commercial software except if 
explicitly saying so), because either they are unaware of the problem, 
or more often they blind themselves with the argument "I am not a 
computer scientist, it's not my job, so  I just ask money to buy the 
software I need and I use the result", forgetting voluntarily that the 
cure to their incompetence in the subject is trivial : ask the 
collaboration of a computer scientist whose it is the job. The reason 
for this self-blinding lies (in my opinion) in the pressure for 
publishing the most possible (to increase fundings), that replaces more 
and more often the usual pressure for publishing the most rigorous 
results possible that used to be the norm in the refereeing system, and 
which is de facto loosening more and more by the acceptance of unproved 
results originating from commercial software. In short : if you publish 
with only your name, your publication index is higher than if you 
publish in collaboration with a computer scientist.

This trend is especially common among experimental scientists, for two 
reasons : first, they have lot of money so they can buy very expensive 
software, and second, there is an inherent uncertainty in experimental 
results, so they translate their tolerance to errors in experimental 
results toward tolerance to possible errors in commercial software, 
without realizing (or wanting to realize) that errors in experiment and 
software are of a complete different nature : error in an experimental 
measure is unavoidable and inherent to experimental work, while error in 
a software is completely avoidable since it is pure mathematics, 
expressed in a computer language instead of plain English.

The fact that the scientific community itself is responsible for the 
globally decreasing rigor in scientific articles, related to the use of 
commercial software, is well illustrated by remarks of somebody on this 
list (was it William Stein ?) who explained that NSF do not fund 
software that could compete with commercial software. The reviewers of 
NSF, who decide this policy, are scientists like us, but they are either 
blinded or bound by the ideology propagated by Friedmanian economists, 
that tells us that scientists must go closer and closer to enterprises 
to help them make more money. I think that, instead of listening to 
Milton Friedman (whose theories have proved to be excellent for wealthy 
people but catastrophic for others), they ought to go back to Adam 
Smith. One of his most famous phrases is that "it is not from the 
benevolence of the butcher, the brewer or the baker that we expect our 
dinner, but from their regard to their own interest". So, by applying 
this principle to the subset of scientists and entrepreneurs, we get : 
"it is not from the benevolence of the scientists that the entrepreneurs 
ought to expect their dinner, but from their regard to their own 
interest". In other terms, the best way, according to Adam Smith, for 
entrepreneurs to create new products is not to force scientists to 
imagine new products of a type pre-defined by the entrepreneur, but to 
let them do what interests them, and then look among the whole set of 
results obtained and pick those that can most readily be used to create 
new products.

And for products that incorporate software or use software to produce 
them (like planes :-) the Adam Smith point of view is that the most 
profitable way for entrepreneurs to build planes is to let scientists 
study them - and in particular make software - in their own way. And 
their own way for software is Open Source as explained above, except if 
one prefers to jump backward 200 years..

\start
Date: Mon, 26 Nov 2007 21:47:44 +0100
From: Paul Zimmermann
To: Tim Daly
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: William Stein, David Joyner

       Dear Tim,

I do not completely agree with the following:

> [...] The 3Ms have the idea, the time, and the money.  [...]

then how do you explain that both Mathematica, Maple and Magma use the
GNU MP library? Clearly the idea/time/money are not enough, even for
companies of 1000+ people, to compete with ***one*** specialist of his field.

\start
Date: Tue, 27 Nov 2007 09:33:31 +0100
From: Bertfried Fauser
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software

Hi,

is this kindergarden? or do we talk Axiom issues here? lol...

On Nov 26, 2007 9:24 PM, Ed Borasky Ed Borasky wrote:
> Arthur Ralfs wrote:
> > Ed Borasky wrote:
> >> Well ... if you mean "*Red Hat* Linux has won a significant market
> >> share in servers", I agree. However, I don't think as a user that
> >> either Firefox or OpenOffice are of sufficient quality or maturity to
> >> be used on a Windows desktop, and I don't consider what they have
> >> accomplished to be a "win". They just aren't viable alternatives for
> >> anything but casual home use. I use them on Linux because they are
> >> there, but they aren't on my Windows desktop at work and probably
> >> never will be.
> >>
> > Do you mean to say that you think IE is better than Firefox?  Hard to
> > imagine.
>
> I'm saying:
>
> 1. Firefox is *not* better than IE 7 on the Windows platform for any
> reasonable definition of "better". In particular, the hype about Firefox
> being more secure than IE is unsubstantiated and cannot in fact be
> proven or falsified.
>
> 2. In a corporation or other accountability hierarchy, people aren't
> always free to experiment with potential improvements. In fact, the
> epidemic of malware, cyber-terrorism and other things of that ilk have
> led to very restrictive IT policies. Even if Firefox were better than
> IE, it would still face an uphill battle in this arena.
>
> Are you saying that OpenOffice is "better" than Microsoft Office on any
> dimension other than price? :)

\start
Date: 27 Nov 2007 14:40:49 +0100
From: Martin Rubey
To: Bill Page
Subject: revert won't work, preview missing

Dear Bill!

Two problems with the new wiki:

* preview is missing from the comment boxes

* I cannot revert an edit (Site Error occurred).  Do I have to register to do
  so?  (might make sense)

\start
Date: Tue, 27 Nov 2007 10:16:23 -0500
From: Bill Page
To: Martin Rubey
Subject: Re: revert won't work, preview missing

Martin,

On 27 Nov 2007 14:40:49 +0100, you wrote:
>
> Two problems with the new wiki:
>
> * preview is missing from the comment boxes
>

This is another customization of ZWiki that has been lost in the move
from the old wiki software to the new. I will be working on adding
this feature soon.

> * I cannot revert an edit (Site Error occurred).

This is actually a bug in the ZWiki package relating to the page
rating functions. (def setVotes missing). I have fixed the bug and you
should now be able to revert changes. I will submit a patch to the
ZWiki developers.

Just in case other people do not yet know how to do this, let me
review the procedure for doing page reversion here:

1) Start by reviewing the edit history of the page. Click on the
history link at the upper left corner of the page. It looks like this:

                                   last edited _6 minutes_  ago by page

Click on _6 minutes_

2) You will see a list like this:

Edit history for SandBox7

[Return to page]

Version         Note Size Editor    Time
[8] reverted by page 2814 page      2007/11/27 06:50:06 GMT-8
[7] test revert      2845 page      2007/11/27 06:11:25 GMT-8
[6]                  2814 page      2007/11/26 19:22:13 GMT-8
[5]                  2812 page      2007/11/26 11:45:56 GMT-8
[4]                  2813 127.0.0.1 2007/11/26 08:53:45 GMT-8
[3]                  2803 127.0.0.1 2007/11/26 08:31:26 GMT-8
[2]                  2752 127.0.0.1 2007/11/26 08:21:29 GMT-8
[1] test eval Fra... 2640 2007/11/18 17:44:34 GMT-8

3) Click on the version number e.g. [7] to view a particular version
of a page. You will see something like this:

[Return to edit history]  [<<] 1 2 3 4 5 6 7 8 [>>]  [Revert to this version]
	
Editor: page
Time: 2007/11/27 06:11:25 GMT-8
Note: test revert
----------------------------------------------------------------
added:

... changes that resulted in this page from the previous verison
----------------------------------------------------------------
... old page contents ...

4) To revert the page to the version shown click on [Revert to this version]

5) Click the [<<] [>>] or a version number e.g. 6, to show another
version of the page.

> Do I have to register to do so?  (might make sense)
>

No, right now you do not have to register. So far I have left the new
wiki site open to anonymous edits. But I am monitoring all changes to
the site and if/when spam becomes a problem I will implement access
restrictions such as this to control the spam. In general since this
is a wiki I *do* want to keep it as open as possible.

In an open wiki the ability for users to revert changes (especially
malicious changes) is very important. You should not hesitate to use
this function if you think an improper change has been made to a page
or in the case of a simple error.

\start
Date: Tue, 27 Nov 2007 07:24:09 -0800
From: Ed Borasky
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software
Cc: Gabriel Dos Reis

Michel Lavaud wrote:
> 
>> If the plane I'm flying is built based on simulations with commercial
>> mathematical software tools, I surely want them to be the best.
>>   
> If the plane I'm flying is built based on simulations with commercial 
> mathematical software tools, whose accuracy is guaranteed in the usual 
> way, i.e. no guarantee at all except refund for the price of the 
> software whatever consequences and it is forbidden to get the source 
> code to check if it is correct -  then I will for sure take the next 
> plane, if it has been built with free Open Source software :-)

[snip]

I've heard this argument before -- it's fallacious on a number of 
levels, and I don't have time to dig into it right now. But I want to 
remind people that:

1. Aircraft used to be designed with slide rules and mechanical desk 
calculators. The equations involved are "open source" in the sense that 
everyone who is a professional aeronautical engineer learns them in 
college, knows them intimately. What today's computers allow us to do is 
build larger and more complex aviation systems that are more economical 
on fuel.

2. Very few aircraft crashes are caused by design flaws of any kind, and 
even fewer by incorrect software. Human error at the time of the flight 
and sabotage/terrorism/military actions are the two main causes of 
aircraft crashes. The only really blatant example of a design flaw 
causing aircraft crashes I can remember was the DeHavilland Comet. That 
was not a software flaw as far as I know -- I'm not even sure scientific 
computers were available outside of the military when the Comet was 
designed, and they would have been on the scale of a Von Neumann/IAS 
machine, or maybe an IBM 704, if they were.

\start
Date: Tue, 27 Nov 2007 09:44:58 -0600 (CST)
From: Gabriel Dos Reis
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software

On Tue, 27 Nov 2007, Michel Lavaud wrote:

[...]

| Personnally, I think the only valid, scientific way is the first one : any
| work proposed for publication that uses commercial software ought to be
| rejected by the referee, unless it says explicitly and honestly that it used
| commercial, non-provable software, so that another researcher can then improve
| on the article later, and publish another article using a completely Open
| Source software and provide a complete, rigorous, verifiable proof..

So, are you arguing for or a against

 # If the plane I'm flying is built based on simulations with commercial
 # mathematical software tools, I surely want them to be the best.

?

[...]

| This trend is especially common among experimental scientists, for two reasons
| : first, they have lot of money so they can buy very expensive software, and
| second, there is an inherent uncertainty in experimental results, so they
| translate their tolerance to errors in experimental results toward tolerance
| to possible errors in commercial software, without realizing (or wanting to
| realize) that errors in experiment and software are of a complete different
| nature : error in an experimental measure is unavoidable and inherent to
| experimental work, while error in a software is completely avoidable since it
| is pure mathematics, expressed in a computer language instead of plain
| English.

That may be the case.  In the interest of rigor and openness as you
promote, do you have data for that scenario we could all check so that
it does not appear to be a gratuitous anecdote?


| The fact that the scientific community itself is responsible for the globally
| decreasing rigor in scientific articles, related to the use of commercial
| software, is well illustrated by remarks of somebody on this list (was it
| William Stein ?) who explained that NSF do not fund software that could
| compete with commercial software.

I don't believe that remark came from William Stein -- whose SAGE project,
described as alternative to commercial mathematical software, has been
funded by NSF -- but maybe I'm not reading the same thread as you.

       http://www.sagemath.org/

\start
Date: Tue, 27 Nov 2007 20:00:30 +0100
From: Michel Lavaud
To: Ed Borasky
Subject: re: AMS Notices: Open Source Mathematical Software

Ed Borasky a =E9crit :

>> If the plane I'm flying is built based on simulations with commercial
>> mathematical software tools, whose accuracy is guaranteed in the
>> usual way, i.e. no guarantee at all except refund for the price of
>> the software whatever consequences and it is forbidden to get the
>> source code to check if it is correct -  then I will for sure take
>> the next plane, if it has been built with free Open Source software :-)

> [snip]
>
> I've heard this argument before -- it's fallacious on a number of
> levels, and I don't have time to dig into it right now.
Ah dear, you win, I confess I am unable to refute your argument. So,
after closed source programs, we have now closed source arguments! Very
clever. Can I buy a licence ? (Ok, just a joke:-))
> But I want to remind people that: 1. Aircraft used to be designed with
> slide rules and mechanical desk calculators. The equations involved
> are "open source" in the sense that everyone who is a professional
> aeronautical engineer learns them in college, knows them intimately.
> What today's computers allow us to do is build larger and more complex
> aviation systems that are more economical on fuel.
>
Yes of course, I don't deny the usefulness of computers for aviation. As
for "open source" equations : we inherited the old traditional
scientific way of not selling knowledge. In the new framework of
so-called "economy of knowledge" (which is, in my opinion, an oxymoron,
but that's another story), that promote to put property rights on
knowledge, this will not be the case any more. That's one of my points :
the trend (i.e. the derivative) is that the situation will go worse,
i.e. less and less "open source" equations, if we scientists do not stop
this trend by realizing that selling scientific software and more
generally selling knowledge is "tuer la poule aux oeufs d'or" (don't
know in English : "kill the hen with golden eggs"?)

>
> 2. Very few aircraft crashes are caused by design flaws of any kind,
> and even fewer by incorrect software. Human error at the time of the
> flight and sabotage/terrorism/military actions are the two main causes
> of aircraft crashes. The only really blatant example of a design flaw
> causing aircraft crashes I can remember was the DeHavilland Comet.
> That was not a software flaw as far as I know -- I'm not even sure
> scientific computers were available outside of the military when the
> Comet was designed, and they would have been on the scale of a Von
> Neumann/IAS machine, or maybe an IBM 704, if they were.
Yes, OK : in the times when computers were inexistant, I agree it is
highly improbable that plane crashes were caused by sofware errors :-)
However, in the times when they existed and were used, I would bet that
most numerical computations for planes were made in Fortran, and Fortran
is the exception :that confirms the rule : there are many free libraries
of subroutines in this language, and some (if not all ?) commercial
libraries of subroutines are sold with the source code. But maybe I'm
wrong ?

\start
Date: Tue, 27 Nov 2007 15:12:09 -0500
From: Tim Daly
To: Chris Arena
Subject: Re: problem with Axiom pages?

Chris,

>I was trying to get to the download page for Axiom from
>http://www.axiom-developer.org/, and get the
>Object not found!
>message when I try to go to the Download page.
>
>When I select "Home", I get a simple TOC for Axiom documentation.

The axiom site is currently in somewhat of a broken state. 
Source and binary downloads can be found at:

<http://daly.axiom-developer.org/axiombinary>

and don't hesitate to mention these things as I would never know
otherwise.

\start
Date: 27 Nov 2007 20:26:50 +0100
From: Martin Rubey
To: list
Subject: Link to new wiki

Dear maintainers in charge,

I would like to suggest that each one of you places a link to the new wiki home

  axiom-wiki.new-synthesis.org

on his projects homepage.  I believe that this would be a win for all of us.

\start
Date: 27 Nov 2007 13:55:58 -0600
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Link to new wiki

Martin Rubey writes:

| Dear maintainers in charge,
| 
| I would like to suggest that each one of you places a link to the new wiki home
| 
|   axiom-wiki.new-synthesis.org
| 
| on his projects homepage.  I believe that this would be a win for all of us.

That is easily solved: Bill has write priliege to OpenAxiom's web and
other stuff :-).  OpenAxiom's web files are in the repository.

\start
Date: Tue, 27 Nov 2007 14:50:55 -0500
From: Bill Page
To: Martin Rubey
Subject: Re:  Link to new wiki

On 27 Nov 2007 20:26:50 +0100, Martin Rubey wrote:
>
> Dear maintainers in charge,
>
> I would like to suggest that each one of you places a link to the new wiki home
>
>  axiom-wiki.new-synthesis.org
>
> on his projects homepage.  I believe that this would be a win for all of us.
>

Thanks, Martin. I think that is a very good idea, but please note the
correct url:

http://axiom-wiki.newsynthesis.org

'newsynthesis' is one word - there is no dash here. But there is a
dash in the axiom-wiki part. Sorry, 'newsynthesis' is a fixed name,
but I could add an alias for  'axiomwiki' if you think that would be a
good idea.

\start
Date: 27 Nov 2007 21:04:56 +0100
From: Martin Rubey
To: list
Subject: Re:  Re: Link to new wiki

Bill Page writes:

> 'newsynthesis' is one word 

oh sorry - I should have checked

> - there is no dash here. But there is a dash in the axiom-wiki part. Sorry,
> 'newsynthesis' is a fixed name, but I could add an alias for 'axiomwiki' if
> you think that would be a good idea.

No, I don't think so.  Although I do think that it should be
axiom.newsynthesis.org.  No need to rush, though, you answered that request
already some time ago.  When I have time, I'll invest a little in the wiki, and
make my suggestions then.

In any case, many many thanks Bill!

\start
Date: Tue, 27 Nov 2007 16:57:09 -0500
From: Bill Page
To: list
Subject: Re:  Re: Link to new wiki

On 27 Nov 2007 13:55:58 -0600, Gabriel Dos Reis wrote:
>
> Martin Rubey writes:
>
> | Dear maintainers in charge,
> |
> | I would like to suggest that each one of you places a link to the new wiki home
> |
> |   axiom-wiki.new-synthesis.org
> |
> | on his projects homepage.  I believe that this would be a win for all of us.
>
> That is easily solved: Bill has write priliege to OpenAxiom's web and
> other stuff :-).  OpenAxiom's web files are in the repository.
>

Gaby,

I could not find any documentation about how to update OpenAxiom's web
site but I commited the following change to the htdocs branch of the
repository. When/how does the page:

http://www.open-axiom.org/links.html

actually get updated?

Regards,
Bill Page.

---------- Forwarded message ----------
From: billpage@users.sourceforge.net <billpage@users.sourceforge.net>
Date: Nov 27, 2007 4:49 PM
Subject: [open-axiom-commit] SF.net SVN: open-axiom: [259] htdocs/links.html
To: open-axiom-commit@lists.sf.net


Revision: 259
          http://open-axiom.svn.sourceforge.net/open-axiom/?rev=259&view=rev
Author:   billpage
Date:     2007-11-27 13:49:09 -0800 (Tue, 27 Nov 2007)

Log Message:
-----------
links.html - Add Online Resources section and link to
             http://axiom-wiki.newsynthesis.org

Modified Paths:
--------------
    htdocs/links.html

Modified: htdocs/links.html
===================================================================
--- htdocs/links.html   2007-11-27 17:22:13 UTC (rev 258)
+++ htdocs/links.html   2007-11-27 21:49:09 UTC (rev 259)
@@ -71,6 +71,13 @@
     <li><a href="http://ecls.sf.net">ECL:</a> Embeddable Common Lisp</li>
   </ul>

+  <h3>Online Resources</h3>
+
+  <ul class="description">
+    <li><a href="http://axiom-wiki.newsynthesis.org">AxiomWiki:</a> Community
+        supported information and online access</li>
+  </ul>
+
 </div>

\start
Date: Wed, 28 Nov 2007 00:16:29 +0100
From: Michel Lavaud
To: Gabriel Dos Reis
Subject: re: AMS Notices: Open Source Mathematical Software

Gabriel Dos Reis a =E9crit :
> On Tue, 27 Nov 2007, Michel Lavaud wrote:
>
> [...]

> | Personnally, I think the only valid, scientific way is the first
> | one : any work proposed for publication that uses commercial
> | software ought to be rejected by the referee, unless it says
> | explicitly and honestly that it used commercial, non-provable
> | software, so that another researcher can then improve on the
> | article later, and publish another article using a completely Open
> | Source software and provide a complete, rigorous, verifiable
> | proof..

> So, are you arguing for or a against
>
>  # If the plane I'm flying is built based on simulations with commercial
>  # mathematical software tools, I surely want them to be the best.
>
> ?
>
  
I am not sure I understand the question, is it about your remark on
planes ? If yes, it was more of a joke because I assumed your remark was
too : was it not ? I would believe that big aviation companies use their
own software, so it is Open Source internally, even if it is not
published outside of the company. I assume that, if they use commercial
software, they use it only in drafts or for double-checing, and they use
their software for real definitive work ? My serious remarks were for
software used by academic scientists, not by engineers in big companies.
> [...]

> | This trend is especially common among experimental scientists, for
> | two reasons : first, they have lot of money so they can buy very
> | expensive software, and second, there is an inherent uncertainty
> | in experimental results, so they translate their tolerance to
> | errors in experimental results toward tolerance to possible errors
> | in commercial software, without realizing (or wanting to realize)
> | that errors in experiment and software are of a complete different
> | nature : error in an experimental measure is unavoidable and
> | inherent to experimental work, while error in a software is
> | completely avoidable since it is pure mathematics, expressed in a
> | computer language instead of plain English.

> That may be the case.  In the interest of rigor and openness as you
> promote, do you have data for that scenario we could all check so that
> it does not appear to be a gratuitous anecdote?
>
>  
Once again, I'm not sure I understand the question : which data would
you like that "all could check" ? Do you mean a table that would list
the number of licences of commercial softwares that were bought  in the
various laboratories of my university, with prices ? It probably could
be obtained, but I have not. All I can say is that, among physicists,
chemists and biologists I know, only a handful use free software, most
use commercial software under Windows, many use commercial software sold
with measurement apparatus, or sold by vendors of software that organise
journeys of formation and propose reduced prices for grouped commands.
Those colleagues I know who use CAS use Mathematica, several chemists
use very expensive software on workstations for representing molecules,
some biologists use expensive software to analyze data. I know only one
colleague who writes free software and distribute it on its web site.
Linux is popular only at the computation center.

\start
Date: 27 Nov 2007 18:41:44 -0600
From: Gabriel Dos Reis
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software

Michel Lavaud writes:

[...]

| > | This trend is especially common among experimental scientists,
| > | for two reasons : first, they have lot of money so they can buy
| > | very expensive software, and second, there is an inherent
| > | uncertainty in experimental results, so they translate their
| > | tolerance to errors in experimental results toward tolerance to
| > | possible errors in commercial software, without realizing (or
| > | wanting to realize) that errors in experiment and software are
| > | of a complete different nature : error in an experimental
| > | measure is unavoidable and inherent to experimental work, while
| > | error in a software is completely avoidable since it is pure
| > | mathematics, expressed in a computer language instead of plain
| > | English.

| > That may be the case.  In the interest of rigor and openness as you
| > promote, do you have data for that scenario we could all check so that
| > it does not appear to be a gratuitous anecdote?
| >
| >
| Once again, I'm not sure I understand the question : which data would
| you like that "all could check" ?

  # [...] so they translate their tolerance to errors in experimental
  # results toward tolerance to possible errors in commercial software

\start
Date: Tue, 27 Nov 2007 22:28:18 -0600
From: Tim Daly
To: Arthur Ralfs, Alfredo Portes
Subject: newhyper.pamphlet

New version checked in. Everything under Topics->Functions works.

\start
Date: 28 Nov 2007 08:53:56 +0100
From: Martin Rubey
To: Bill Page, Waldek Hebisch
Subject: members / parts of binarytrees

Dear all, especially Bill,

I'd need members$BinaryTree right now, did you supply a patch or did you only
notice?  (I guess the patch is not difficult, but still...)

\start
Date: Wed, 28 Nov 2007 11:41:24 +0100
From: Michel Lavaud
To: Gabriel Dos Reis
Subject: re: AMS Notices: Open Source Mathematical Software

Gabriel Dos Reis a =E9crit :
> Michel Lavaud writes:
>
>
> [...]

> | > | This trend is especially common among experimental scientists,
> | > | for two reasons : first, they have lot of money so they can
> | > | buy very expensive software, and second, there is an inherent
> | > | uncertainty in experimental results, so they translate their
> | > | tolerance to errors in experimental results toward tolerance
> | > | to possible errors in commercial software, without realizing
> | > | (or wanting to realize) that errors in experiment and software
> | > | are of a complete different nature : error in an experimental
> | > | measure is unavoidable and inherent to experimental work,
> | > | while error in a software is completely avoidable since it is
> | > | pure mathematics, expressed in a computer language instead of
> | > | plain English.

> | > That may be the case.  In the interest of rigor and openness as you
> | > promote, do you have data for that scenario we could all check so that
> | > it does not appear to be a gratuitous anecdote?
> | >
> | >
> | Once again, I'm not sure I understand the question : which data would
> | you like that "all could check" ?
>
>   # [...] so they translate their tolerance to errors in experimental
>   # results toward tolerance to possible errors in commercial software
>  
Ah, OK. You meant gratuitous interpretation, I suppose ? An
experimentalist has to be tolerant to errors because errors are inherent
to experiments. In particular, for him, a possible error in a program is
just one among _hundreds_ of other possible causes of errors. For a
mathematician, a possible error in a program used in an article is one
among _zero_ other possible errors (if his proof is correct, of course,
as also the proofs of theorems his article relies on).

\start
Date: Wed, 28 Nov 2007 05:09:58 -0600 (CST)
From: Gabriel Dos Reis
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software

On Wed, 28 Nov 2007, Michel Lavaud wrote:

| Gabriel Dos Reis a =E9crit :
| > Michel Lavaud writes:
| >
| >
| > [...]

| > | > | This trend is especially common among experimental
| > | > | scientists, for two reasons : first, they have lot of money
| > | > | so they can buy very expensive : software, and second, there
| > | > | is an inherent uncertainty in experimental results, so they
| > | > | translate their tolerance to errors in experimental results
| > | > | toward tolerance to possible errors in commercial software,
| > | > | without realizing (or wanting to realize) that errors in
| > | > | experiment and software are of a complete different nature :
| > | > | error in an experimental measure is unavoidable and inherent
| > | > | to experimental work, while error in a software is
| > | > | completely avoidable since it is pure mathematics, expressed
| > | > | in a computer language instead of plain English.

| > | > That may be the case.  In the interest of rigor and openness as you
| > | > promote, do you have data for that scenario we could all check so that
| > | > it does not appear to be a gratuitous anecdote?
| > | >
| > | >
| > | Once again, I'm not sure I understand the question : which data would
| > | you like that "all could check" ?
| >
| > # [...] so they translate their tolerance to errors in experimental
| > # results toward tolerance to possible errors in commercial software
| >  
| Ah, OK. You meant gratuitous interpretation, I suppose ?

Do you have factual data? 

\start
Date: Wed, 28 Nov 2007 12:16:17 +0100
From: Michel Lavaud
To: Gabriel Dos Reis, list
Subject: re: AMS Notices: Open Source Mathematical Software

Maybe it would be clearer to say "so they extend their tolerance" ? 
Sorry for my poor English :-(
>>
>>   # [...] so they translate their tolerance to errors in experimental
>>   # results toward tolerance to possible errors in commercial software
>>   
> Ah, OK. You meant gratuitous interpretation, I suppose ? An 
> experimentalist has to be tolerant to errors because errors are 
> inherent to experiments. In particular, for him, a possible error in a 
> program is just one among _hundreds_ of other possible causes of 
> errors. For a mathematician, a possible error in a program used in an 
> article is one among _zero_ other possible errors (if his proof is 
> correct, of course, as also the proofs of theorems his article relies 
> on).

\start
Date: Wed, 28 Nov 2007 13:09:43 +0100
From: Michel Lavaud
To: Gabriel Dos Reis, list
Subject: re: AMS Notices: Open Source Mathematical Software

> | > # [...] so they translate their tolerance to errors in experimental
> | > # results toward tolerance to possible errors in commercial software
> | >   
> | Ah, OK. You meant gratuitous interpretation, I suppose ? 
>
> Do you have factual data?  

Yes, cf the chapter on error bars, in any course of physics. They 
usually  include some examples of causes of experimental errors. For 
more practical examples, you can ask to any experimentalist which are 
the main causes of errors that he uses to determine the error bar on a 
particular result, in one of his experiments.

\start
Date: Wed, 28 Nov 2007 06:11:22 -0600 (CST)
From: Gabriel Dos Reis
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software

On Wed, 28 Nov 2007, Michel Lavaud wrote:

| 
| > | > # [...] so they translate their tolerance to errors in experimental
| > | > # results toward tolerance to possible errors in commercial software
| > | >   
| > | Ah, OK. You meant gratuitous interpretation, I suppose ? 
| >
| > Do you have factual data?  
| >
| >   
| Yes, cf the chapter on error bars, in any course of physics.

Please, don't pretend you don't understand my question and answer one
I'm not interested in.  

You made a specific strong statement -- still quoted above.  Either,
it was a pure speculation from your part, or you have factual data to
back it up.  If the latter, please make them public -- in the interest
of rigor and openness as you promote.  Otherwise, let's drop it and
call it a day. 

\start
Date: Wed, 28 Nov 2007 06:13:05 -0600 (CST)
From: Gabriel Dos Reis
To: Michel Lavaud
Subject: re: AMS Notices: Open Source Mathematical Software

On Wed, 28 Nov 2007, Michel Lavaud wrote:

| Maybe it would be clearer to say "so they extend their tolerance" ? Sorry for
| my poor English :-(

Tout le monde devrait parler fran=E7ais, n'est-ce pas ? ;-)

\start
Date: Wed, 28 Nov 2007 15:27:13 +0100
From: Michel Lavaud
To: Gabriel Dos Reis
Subject: re: AMS Notices: Open Source Mathematical Software

Gabriel Dos Reis a =E9crit :
> On Wed, 28 Nov 2007, Michel Lavaud wrote:
>
> |
> | > | > # [...] so they translate their tolerance to errors in experimental
> | > | > # results toward tolerance to possible errors in commercial software
> | > | >  
> | > | Ah, OK. You meant gratuitous interpretation, I suppose ?
> | >
> | > Do you have factual data? 
> | >
> | >  
> | Yes, cf the chapter on error bars, in any course of physics.
>
> Please, don't pretend you don't understand my question and answer one
> I'm not interested in. 
>
> You made a specific strong statement -- still quoted above.  Either,
> it was a pure speculation from your part, or you have factual data to
> back it up.  If the latter, please make them public -- in the interest
> of rigor and openness as you promote.
I am very sorry but I don't understand at all what kind of "factual
data" you want me to provide, if it's not estimates about software used,
or causes of errors in experiments. I gave my interpretation about
reactions I got from colleagues, in discussions that occurred along many
years. If you don't agree with my interpretation, that's perfectly OK
for me. Just next time, please try to explain more precisely what you
mean, if you want precise answers. Your questions are too sketchy for me
to understand.
>  Otherwise, let's drop it
Yes, please.

\start
Date: Wed, 28 Nov 2007 17:08:48 -0500
From: Bill Page
To: Martin Rubey
Subject: Re:  Re: members / parts of binarytrees
Cc: Waldek Hebisch

On 11/28/07, Waldek Hebisch wrote:
>
> Martin Rubey wrote:
> >
> > Dear all, especially Bill,
> >
> > I'd need members$BinaryTree right now, did you supply a patch or
> > did you only notice?  (I guess the patch is not difficult, but still...)
> >
>
> I also did not notice a patch -- I assume that Bill just noticed the
> problem.  I would like to have this function in the next FriCAS
> release and I would like to have release in few days so I will
> write one unless somebody provides one earlier.
>

No I did not supply a patch. I only noticed that 'members' is defined
for BinaryTree but that it depends on another function 'parts' that is
missing from domain.

I think there is a problem defining exactly what one might mean by
'members$BinaryTree'. In particular: What ordering is to be assumed?

For example if you do not mind an "in-order" traversal than maybe you
would like this definition:

  members(t) == map(value,nodes t)

\start
Date: Thu, 29 Nov 2007 01:22:23 -0600
From: Tim Daly
To: list
Subject: 20071129.01.tpd.patch

This patch sets up the mathml fonts needed to display the new hyperdoc
pages in a browser. See the README file to install the fonts in fedora
and firefox.

======================================================================
diff --git a/changelog b/changelog
index 8e672f7..867f19a 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,4 @@
+20071129 tpd zips/axiomfonts.tgz add mathml fonts
 20071119 tpd Makefile.pamphlet add fedora6,7,8 stanzas
 20071101 tpd src/interp/i-output.boot fix bugs 7010 (209), 7011
 20071019 acr src/interp/http.lisp use new return values
diff --git a/zips/axiomfonts.tgz b/zips/axiomfonts.tgz
new file mode 100644
index 0000000..4202e32
Binary files /dev/null and b/zips/axiomfonts.tgz differ

\start
Date: Thu, 29 Nov 2007 02:28:42 -0600
From: Tim Daly
To: Arthur Ralfs, Alfredo Portes
Subject: newhyper.pamphlet

topics -> solving equations is complete and has been checked in.

\start
Date: 29 Nov 2007 11:52:51 +0100
From: Martin Rubey
To: Bill Page
Subject: wiki vandalism

Dear Bill, *

I just tried to revert 

    #199 integratee^(x^2)

but without success.  ( maybe name changes are excluded from the revert
process?? No idea.)

Moreover, I think that issuetracker is so vital for axiom, that I'd suggest
that changing properties, names, etc, should only be available to registered
users.

I really wonder how wikipedia deals with that sort of vandalism.

\start
Date: Thu, 29 Nov 2007 06:45:44 -0500
From: Bill Page
To: Martin Rubey
Subject: Re: wiki vandalism

On 29 Nov 2007 11:52:51 +0100, Martin Rubey wrote:
>
> I just tried to revert
>
>     #199 integratee^(x^2)
>
> but without success.  ( maybe name changes are excluded from the
> revert process?? No idea.)
>

It seems you are right. Revert does not revert a name change. I think
that is a bug in ZWiki. You have to use 'rename' to change the name
back to what it was.

> Moreover, I think that issuetracker is so vital for axiom, that I'd
> suggest that changing properties, names, etc, should only be
> available to registered users.
>
> I really wonder how wikipedia deals with that sort of vandalism.
>

I think they require as a minimum that users to identify themselves.
That stops 90% of the spam.

I agree that spam is becoming a bit of a problem here.

Ok, I have enabled the 'edits_need_username' option on Axiom Wiki.
That should help the spam problem.

\start
Date: Thu, 29 Nov 2007 21:49:40 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: bug 7018: mathml does not render "failed" properly

limit(x*log(x),x=0)
  [leftHandLimit=~failed~,rightHandLimit=0]

should be
  [leftHandLimit="failed",rightHandLimit=0]

\start
Date: Thu, 29 Nov 2007 22:17:37 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: bug 7019: mathml does not render F,3 properly

bug 7019: mathml does not render F,3 properly
(1) -> F:=operator 'F

   (1)  F
                                                          Type: BasicOperator
(2) -> x:=operator 'x

   (2)  x
                                                          Type: BasicOperator
(3) -> y:=operator 'y

   (3)  y
                                                          Type: BasicOperator
(4) -> a:=F(x z, y z, z^2)+x y(z+1)

                                   2
   (4)  x(y(z + 1)) + F(x(z),y(z),z )
                                                     Type: Expression Integer
(5) -> dadz:=D(a,z)

   (5)
                      2     ,                  2     ,                  2
     2zF  (x(z),y(z),z ) + y (z)F  (x(z),y(z),z ) + x (z)F  (x(z),y(z),z )
        ,3                       ,2                       ,1
   + 
      ,           ,
     x (y(z + 1))y (z + 1)

                                                     Type: Expression Integer
(6) -> )set out mathml on
(6) -> dadz:=D(a,z)

   (6)
                      2     ,                  2     ,                  2
     2zF  (x(z),y(z),z ) + y (z)F  (x(z),y(z),z ) + x (z)F  (x(z),y(z),z )
        ,3                       ,2                       ,1
   + 
      ,           ,
     x (y(z + 1))y (z + 1)

<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big" display="block">
<mrow><mrow><mn>2</mn><mo>&#x02062;</mo><mi>z</mi><mo>&#x02062;</mo><mfrac><mo>&#x02202;</mo><mi>F</mi><mrow><mo>&#x02202;</mo><mi>**z2</mi></mrow></mfrac><mo>(</mo><mi>xz</mi><mo>,</mo><mi>yz</mi><mo>,</mo><mi>**z2</mi><mo>)</mo></mrow><mo>+</mo><mrow><mfrac><mrow><msup><mo>&#x02146;</mo><mn>1</mn></msup><mi>y</mi></mrow><mrow><mo>&#x02146;</mo><msup><mi>z</mi><mn>1</mn></msup></mrow></mfrac><mo>&#x02061;</mo><mo>(</mo><mi>z</mi><mo>)</mo><mo>&#x02062;</mo><mfrac><mo>&#x02202;</mo><mi>F</mi><mrow><mo>&#x02202;</mo><mi>yz</mi></mrow></mfrac><mo>(</mo><mi>xz</mi><mo>,</mo><mi>yz</mi><mo>,</mo><mi>**z2</mi><mo>)</mo></mrow><mo>+</mo><mrow><mfrac><mrow><msup><mo>&#x02146;</mo><mn>1</mn></msup><mi>x</mi></mrow><mrow><mo>&#x02146;</mo><msup><mi>z</mi><mn>1</mn></msup></mrow></mfrac><mo>&#x02061;</mo><mo>(</mo><mi>z</mi><mo>)</mo><mo>&#x02062;</mo><mfrac><mo>&#x02202;</mo><mi>F</mi><mrow><mo>&#x02202;</mo><mi>xz</mi></mrow></mfrac><mo>(</mo><mi>xz</mi><mo>,</mo><mi>yz</mi><mo>,</m!
o><mi>**z2</mi><mo>)</mo></mrow><mo>+</mo><mrow><mfrac><mrow><msup><mo>&#x02146;</mo><mn>1</mn></msup><mi>x</mi></mrow><mrow><mo>&#x02146;</mo><msup><mi>y+z1</mi><mn>1</mn></msup></mrow></mfrac><mo>&#x02061;</mo><mo>(</mo><mi>y+z1</mi><mo>)</mo><mo>&#x02062;</mo><mfrac><mrow><msup><mo>&#x02146;</mo><mn>1</mn></msup><mi>y</mi></mrow><mrow><mo>&#x02146;</mo><msup><mi>+z1</mi><mn>1</mn></msup></mrow></mfrac><mo>&#x02061;</mo><mo>(</mo><mi>+z1</mi><mo>)</mo></mrow></mrow>
</math>

                                                     Type: Expression Integer
(7) -> 




