\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Sat,  9 Aug 2014 22:54:14 -0400 (EDT)
From: Tim Daly <daly@axiom-developer.org>
To: Nicolas Doye <nic@worldofnic.org>,
	Franz Lehner <lehner@finanz.math.tu-graz.ac.at>,
	David Joyner <wdjoyner@gmail.com>,
	Bertfried Fauser <fauser@spock.physik.uni-konstanz.de>,
	"William Sit" <wyscc@sci.ccny.cuny.edu>, "Mike Dewar" <miked@nag.co.uk>,
	"James Davenport" <J.H.Davenport@bath.ac.uk>,
	"Johannes Grabmeier" <grabm@heidelbg.ibm.com>,
	"Richard Fateman" <rjf@cs.berkeley.edu>,
	"Paul Zimmermann" <Paul.Zimmermann@loria.fr>,
	"William Stein" <wstein@gmail.com>
Cc: Barry Trager <bmt@us.ibm.com>, Ralf Hemmecke <ralf@hemmecke.de>,
	axiom-developer@nongnu.org, Vinton Cerf <vgcerf@gmail.com>
Subject: [Axiom-developer] Symbolic Algorithms Standards

The time has come, it seems to me, to organize an effort to
collect and standardize symbolic algorithms, similar in spirit
to the NIST Handbook of Mathematical Functions.

It should be possible to order algorithm development for things
like integration, starting with Liouville's work, then Risch, etc.
The idea is to provide the algorithm and a series of improvements
in some reasonably accessible pseudocode, perhaps with some
agreed-upon benchmark of time and space complexity. There should
also be an associated website with a cache of the papers for each
algorithm. The book would be updated yearly with new developments.

I have been collecting bibliographic references as part of the 
Axiom project and have recently started organizing them by topic.
http://axiom-developer.org/axiom-website/bookvolbib.pdf

Is a NIST-like algorithm collection reasonable? Opinions welcome.

Tim Daly
daly@axiom-developer.org

\start
Date: Sun, 10 Aug 2014 09:10:57 -0400
From: "William Sit" <wyscc@sci.ccny.cuny.edu>
To: Tim Daly <daly@axiom-developer.org>,Nicolas Doye
	<nic@worldofnic.org>,        Franz Lehner
	<lehner@finanz.math.tu-graz.ac.at>,        David Joyner
	<wdjoyner@gmail.com>,        Bertfried Fauser
	<fauser@spock.physik.uni-konstanz.de>,        "Mike Dewar"
	<miked@nag.co.uk>, "James Davenport" <J.H.Davenport@bath.ac.uk>, 
	"Johannes Grabmeier" <grabm@heidelbg.ibm.com>,        "Richard
	Fateman" <rjf@cs.berkeley.edu>,        "Paul Zimmermann"
	<Paul.Zimmermann@loria.fr>,        "William Stein" <wstein@gmail.com>
Subject: Re: [Axiom-developer] Symbolic Algorithms Standards
Cc: Ralf Hemmecke <ralf@hemmecke.de>, Barry Trager <bmt@us.ibm.com>,
	axiom-developer@nongnu.org, Vinton Cerf <vgcerf@gmail.com>

Dear Tim:

This would be a very ambitious project. In brief, I think 
it would be more manageable to collect survey papers and 
books rather than a list of papers leading up to the most 
recent or efficient algorithms. The reason is, it is 
difficult to "order" the latter (chronological order by 
publication dates is only an approximation due to the lag 
between the research work and final publication, and may 
lead to claims difficult to adjudicate). Survey papers or 
books have done the "distillation" and are usually easier 
to follow. At least, I think that might be a first step. 
The next stage can be a refinement to include the critical 
papers themselves.

William

On Sat,  9 Aug 2014 22:54:14 -0400 (EDT)
  Tim Daly <daly@axiom-developer.org> wrote:
> The time has come, it seems to me, to organize an effort 
>to
> collect and standardize symbolic algorithms, similar in 
>spirit
> to the NIST Handbook of Mathematical Functions.
> 
> It should be possible to order algorithm development for 
>things
> like integration, starting with Liouville's work, then 
>Risch, etc.
> The idea is to provide the algorithm and a series of 
>improvements
> in some reasonably accessible pseudocode, perhaps with 
>some
> agreed-upon benchmark of time and space complexity. 
>There should
> also be an associated website with a cache of the papers 
>for each
> algorithm. The book would be updated yearly with new 
>developments.
> 
> I have been collecting bibliographic references as part 
>of the 
> Axiom project and have recently started organizing them 
>by topic.
> http://axiom-developer.org/axiom-website/bookvolbib.pdf
> 
> Is a NIST-like algorithm collection reasonable? Opinions 
>welcome.
> 
> Tim Daly
> daly@axiom-developer.org

William Sit, Professor Emeritus
Mathematics, City College of New York
Office: R6/291D Tel: 212-650-5179
Home Page: http://scisun.sci.ccny.cuny.edu/~wyscc/

\start
Date: Sun, 10 Aug 2014 23:22:23 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Symbolic Algorithms Standards

There appears to be at least two reasonable ways to collect data
needed to seed this effort. 

One way is to collect details of current implementations.  To this end
I am building an instrumented version of Axiom with low-level trace
facilities. This will capture all of the supporting algorithms (like
GCDs) as well as the higher levels. It will also reveal details not
mentioned in papers.

The second way is to create a lattice of published papers and their
references. This will show a partial order of the publications and the
order of introduction of improvements.  Following the reference chain
minimizes the publication delays. To this end I've started a review
of the Axiom bibliography. I hope to put up a web page that shows
the publication lattice as it unfolds. More to come.

Tim

\start
Date: Mon, 11 Aug 2014 23:00:14 +0200
From: kp <kp@scios.ch>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Symbolic Algorithms Standards

Such a collection would be indeed desirable as there is none - at least
not comprehensive enough. Most favourable of course would be a library
of formally verified algorithms like CoqEAL
(http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library)
taking advantage of the relatively new SSReflect (tutorial ->
http://hal.archives-ouvertes.fr/docs/00/40/77/78/PDF/RT-367.pdf).
The implementation of Bourbaki's "Elements of Mathematics" by Jose Grimm
(http://www-sop.inria.fr/marelle/gaia/index.html) demonstrates in an
impressive way the feasibility to create such a mathematical firm
collection of algorithms.
Regarding 'pseudocode' it might be better (imho) to use the language of
one of the available proof assistants of which Coq is only one suitable
to do the task (http://en.wikipedia.org/wiki/Proof_assistant). Although
I have no profund knowledge of the others (than Coq and Isabelle), it
would be surely preferable to choose one that is capable of 'code
generation' as it might be easier (one day ;) than expected to write a
generator for spad/aldor.
Kurt


Am 10.08.2014 04:54, schrieb Tim Daly:
> The time has come, it seems to me, to organize an effort to
> collect and standardize symbolic algorithms, similar in spirit
> to the NIST Handbook of Mathematical Functions.
> 
> It should be possible to order algorithm development for things
> like integration, starting with Liouville's work, then Risch, etc.
> The idea is to provide the algorithm and a series of improvements
> in some reasonably accessible pseudocode, perhaps with some
> agreed-upon benchmark of time and space complexity. There should
> also be an associated website with a cache of the papers for each
> algorithm. The book would be updated yearly with new developments.
> 
> I have been collecting bibliographic references as part of the 
> Axiom project and have recently started organizing them by topic.
> http://axiom-developer.org/axiom-website/bookvolbib.pdf
> 
> Is a NIST-like algorithm collection reasonable? Opinions welcome.
> 
> Tim Daly
> daly@axiom-developer.org

\start
Date: Mon, 11 Aug 2014 18:17:23 -0500
From: daly@axiom-developer.org
To: kp <kp@scios.ch>
Subject: [Axiom-developer] Symbolic Algorithms Standards

> Such a collection would be indeed desirable as there is none - at least
> not comprehensive enough. Most favourable of course would be a library
> of formally verified algorithms like CoqEAL

I have an initial effort on a wider bibliography
http://axiom-developer.org/axiom-website/bookvolbib.pdf
which I have started to lay out by year
http://axiom-developer.org/axiom-website/lattice.html
Hover over the numbers for the title.
The citation is in the source code for the web page.

I'm not sure what a good way to show the information might be.
If you hover over a number should it also show lines to the papers
it references? That info is in the page source but not used yet.
I am not the best person to do user interface design, as you can see.
Ideally clicking on a link would open the actual paper.

Half of the standards problem is the citation lattice, shown above.
This will be foundational information for when and where an algorithm
first arose. It will also show improvements and their history. Densely
referenced nodes are certainly important. 

The other half of the standards problem is what is actually
implemented in existing systems. I'm instrumenting Axiom to give a
trace of the algorithms used in the solution of an input. This will
allow me to build up a tower of the algorithms. Then I need to relate
the implementations to the published papers. A similar instrumentation
of Maxima would show what algorithms are implemented there.

The third half of the standards problem is getting it supported :-)

We're 40+ years into computational mathematics.
This needs to be done.



> (http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library)
> taking advantage of the relatively new SSReflect (tutorial ->
> http://hal.archives-ouvertes.fr/docs/00/40/77/78/PDF/RT-367.pdf).
> The implementation of Bourbaki's "Elements of Mathematics" by Jose Grimm
> (http://www-sop.inria.fr/marelle/gaia/index.html) demonstrates in an
> impressive way the feasibility to create such a mathematical firm
> collection of algorithms.

> Regarding 'pseudocode' it might be better (imho) to use the language of
> one of the available proof assistants of which Coq is only one suitable
> to do the task (http://en.wikipedia.org/wiki/Proof_assistant). Although
> I have no profund knowledge of the others (than Coq and Isabelle), it
> would be surely preferable to choose one that is capable of 'code
> generation' as it might be easier (one day ;) than expected to write a
> generator for spad/aldor.

I'm not sure what the "pseudocode" might be but I can't actually
advocate writing Spad code. The standards idea is supposed to be
somewhat more general, not a self-serving effort.

I am looking at COQ for a different reason, namely that I'm trying
to prove an Axiom algorithm correct. See
http://axiom-developer.org/axiom-website/bookvol13.pdf
for the place-holder document. I started with the euclidean algorithm.
There are "layers" of the problem so I'm looking at COQ for a
Spad-to-Lisp proof, ACL2 for a Lisp-to-C proof, and my own research on
Conditional Concurrent Assignments for C-to-Intel semantics. This is
a "thin-thread" approach, trying to take one algorithm all the way
from Spad to the machine.

It would be really useful if the standard algorithms could be proven
correct. Code generation from COQ would be ideal. 

Tim

\start
Date: Wed, 20 Aug 2014 11:38:36 +0200
From: Zimmermann Paul <Paul.Zimmermann@inria.fr>
To: Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] Symbolic Algorithms Standards
Cc: J.H.Davenport@bath.ac.uk, lehner@finanz.math.tu-graz.ac.at, bmt@us.ibm.com,
	fauser@spock.physik.uni-konstanz.de, wdjoyner@gmail.com,
	wstein@gmail.com, miked@nag.co.uk, grabm@heidelbg.ibm.com,
	ralf@hemmecke.de, rjf@cs.berkeley.edu,
	axiom-developer@nongnu.org, nic@worldofnic.org, vgcerf@gmail.com

       Dear Tim,

nice to hear from you!

> From: Tim Daly <daly@axiom-developer.org>
> Cc: daly@axiom-developer.org, axiom-developer@nongnu.org,
>    Vinton Cerf <vgcerf@gmail.com>, Raoul Bourquin <raoulb@bluewin.ch>,
>    "Ralf Hemmecke" <ralf@hemmecke.de>, "Barry Trager" <bmt@us.ibm.com>
> Date: Sat,  9 Aug 2014 22:54:14 -0400 (EDT)
> 
> The time has come, it seems to me, to organize an effort to
> collect and standardize symbolic algorithms, similar in spirit
> to the NIST Handbook of Mathematical Functions.
> 
> It should be possible to order algorithm development for things
> like integration, starting with Liouville's work, then Risch, etc.
> The idea is to provide the algorithm and a series of improvements
> in some reasonably accessible pseudocode, perhaps with some
> agreed-upon benchmark of time and space complexity. There should
> also be an associated website with a cache of the papers for each
> algorithm. The book would be updated yearly with new developments.
> 
> I have been collecting bibliographic references as part of the 
> Axiom project and have recently started organizing them by topic.
> http://axiom-developer.org/axiom-website/bookvolbib.pdf
> 
> Is a NIST-like algorithm collection reasonable? Opinions welcome.
> 
> Tim Daly
> daly@axiom-developer.org

not sure about an old-fashioned paper version. Most likely it would be
very soon outdated.

A wikipedia-like collection would be nice, where everybody could contribute,
discuss, add pointers, ...

Note we already have the Collected Algorithms from the ACM:
http://calgo.acm.org/.

Also in Sage you have the related "get_systems" command, which tells you
which systems were used when you perform a computation:

sage: from sage.misc.citation import get_systems
sage: get_systems('random_matrix(ZZ,250).determinant()')
['MPFR', 'GMP']

We could imagine a similar "get_algorithms" command:

sage: get_algorithms('integrate(1/tan(1+x), x)')
['Risch', 'Liouville', 'arxiv079645', 'http://hal.inria.fr/hal-00644166']

Best regards,
Paul

\start
Date: Thu, 21 Aug 2014 11:52:24 +0200
From: Burcin Erocal <burcin@erocal.org>
To: Zimmermann Paul <Paul.Zimmermann@inria.fr>
Subject: Re: [Axiom-developer] Symbolic Algorithms Standards
Cc: J.H.Davenport@bath.ac.uk, fauser@spock.physik.uni-konstanz.de,
	bmt@us.ibm.com, lehner@finanz.math.tu-graz.ac.at,
	wdjoyner@gmail.com, wstein@gmail.com, grabm@heidelbg.ibm.com,
	ralf@hemmecke.de, rjf@cs.berkeley.edu, miked@nag.co.uk,
	axiom-developer@nongnu.org, nic@worldofnic.org, vgcerf@gmail.com

Hi,

On Wed, 20 Aug 2014 11:38:36 +0200
Zimmermann Paul <Paul.Zimmermann@inria.fr> wrote:

> A wikipedia-like collection would be nice, where everybody could
> contribute, discuss, add pointers, ...
> 
> Note we already have the Collected Algorithms from the ACM:
> http://calgo.acm.org/.
> 
> Also in Sage you have the related "get_systems" command, which tells
> you which systems were used when you perform a computation:
> 
> sage: from sage.misc.citation import get_systems
> sage: get_systems('random_matrix(ZZ,250).determinant()')
> ['MPFR', 'GMP']
> 
> We could imagine a similar "get_algorithms" command:
> 
> sage: get_algorithms('integrate(1/tan(1+x), x)')
> ['Risch', 'Liouville', 'arxiv079645',
> 'http://hal.inria.fr/hal-00644166']

There is a prototype implementation of this here:

http://trac.sagemath.org/ticket/3317

You can find some examples of usage in this old draft:

http://www.lmona.de/citeme/citation_report.pre.pdf/at_download/file



Searching through the Sage issue tracker, I found that this ticket
attempts to do the same with a similar approach to the way
get_systems() work:

http://trac.sagemath.org/ticket/16854


Best,
Burcin

\start
Date: Thu, 21 Aug 2014 10:44:48 -0500
From: daly@axiom-developer.org
To: <Paul.Zimmermann@inria.fr>, <burcin@erocal.org>
Subject: Re: [Axiom-developer] Symbolic Algorithms Standards
Cc: axiom-developer@nongnu.org, Vinton Cerf <vgcerf@gmail.com>,
	Tim Hopkins <t.r.hopkins@kent.ac.uk>

Paul, Burcin,

Excellent. Thanks for the pointers.

Keith Geddes, Stephen Czapor, and George Labahn did an excellent job
with their book "Algorithms for Computer Algebra". It would be good to
have something similar coupled with actual executable algorithms so they
can be tested and used. There also needs to be an ongoing effort to 
connect to the published literature to keep the algorithms up to date.

I have started a depth-first literature collection at
http://axiom-developer.org/axiom-website/lattice.html
(mouse over items for the bibliography data).
I plan to link to open versions of papers.

Once the raw citation data starts converging a bit the next step
seems to be to create "threads" from recent publications back to
the earlier algorithms so people can see how the Risch-with-Dilogarithms
is connected to prior Risch work. There needs to be some creative GUI
work done to make this nagivation intuitive (a lattice?).

Crucial to the whole effort, in my mind, are clear explanations of
the algorithms. This is mathematics, after all, so there should be
no magic involved.

>> A wikipedia-like collection would be nice, where everybody could
>> contribute, discuss, add pointers, ...

My experience with Wikis is that this is where information goes to die.
Wikipedia is an exception to that observation but their mental model
existed already. Wikis don't have a mental model for people to follow
so they tend to get lost. Wikis also suffer from the "commons" problem
in that everyone uses but almost no-one contributes. 

A book-like model seems to fit better, something along the lines of
the Geddes book. 

It is important to have a "standards" approach to the effort, hence
the appeal to the "NIST-Standard" mental model. One could reasonably
expect to get the same answer from different systems. On any given
system there might be "extensions" (e.g. answers for multiple branch
cuts, etc) but the "standard" algorithm should be available.

>> 
>> Note we already have the Collected Algorithms from the ACM:
>> http://calgo.acm.org/.

The ACM Collected Algorithms is excellent as far as it goes.  It is
really necessary to have working code for an algorithm repository.
And they do provide literature references.

The ACM Collected Algorithms seems to target numerical algorithms,
at least all of the ones I downloaded. There doesn't seem to be 
any attempt at organization beyond collection.

Symbolic algorithms tend to have much deeper "towers" of algorithms
than numeric ones. Symbolic integration depends on, say, symbolic
factoring. There is a need for organization to take advantage of
lower-level standard algorithms.

Beyond that, there needs to be a good test suite. I've spent some time
on a "Computer Algebra Test Suite" (CATS). See
http://axiom-developer.org/axiom-website/CATS/index.html 
which has tests against published collections of integrals and
differential equations. As an aside, I've found some mistakes in the
published works. I've also been building some tests against the 
"CRC Standard Curves and Surfaces" for the graphics.

These tests should be tightly coupled to the published "standard"
algorithms. That way we know what the expected results of a correct
implementation should be. After all, the goal is to get the same
answer no matter which system is used.

>> Also in Sage you have the related "get_systems" command, which tells
>> you which systems were used when you perform a computation:
>> 
>> sage: from sage.misc.citation import get_systems
>> sage: get_systems('random_matrix(ZZ,250).determinant()')
>> ['MPFR', 'GMP']
>> 
>> We could imagine a similar "get_algorithms" command:
>> 
>> sage: get_algorithms('integrate(1/tan(1+x), x)')
>> ['Risch', 'Liouville', 'arxiv079645',
>> 'http://hal.inria.fr/hal-00644166']

Indeed. I am currently instrumenting Axiom to show exactly which
algorithms are used at any level of detail. The 'Risch' algorithm
has many different implementation details depending on which kind
of expression you're trying to implement. Axiom lists 33 different
"integrate" functions, depending on the domain of the arguments.
Unwinding and documenting this is expected to take a fair amount
of time.

Tim

\start
Date: Fri, 22 Aug 2014 16:20:43 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Creative Destruction and Computational Mathematics

http://www.aei-ideas.org/2014/08/fortune-500-firms-in-1995-vs-2014-89-are-gone-and-were-all-better-off-because-of-that-dynamic-creative-destruction

"12.2% of the Fortune 500 companies in 1955 were still on the list
 59 years later"

"Steven Denning pointed out that a few years [ago] in Forbes that
 fifty years ago the life expectancy of a firm in the Fortune 500
 was around 75 years. Today, it's less than 15 years and declining
 all the time"

So what does this have to do with Computational Mathematics?

Consider what happens if Maple, Mathematica, and Matlab disappear.
It can happen and probably will. REDUCE almost disappeared (Hearn
open-sourced it). DERIVE went private (TI). MACSYMA died when 
Symbolics died (Bill Schelter revived a government version and
called it MAXIMA). Axiom nearly died when it was withdrawn from
the market. Maplesoft was sold and is now owned by Cybernet Systems,
specializing in Mechanical Computer Aided Engineering. So it is
no longer an independent computer algebra company.

Many of the algorithms are either private or, if public, undocumented.
The results are amazing but the level of expertise needed to maintain
and modify these systems is intimidating. Many of these algorithms are
the implementation of Ph.D. work understood deeply by only one person.
As we all know, there is a long step between theory and implementation.
And, in my experience, that long step is never documented.

Even if systems like Mathematica were open sourced it would be very
hard to maintain them. Large systems suffer from what I'll call
"Daly's Pyramid Law:" Systems get an order of magnitude harder to
maintain for every order of magnitude of code. A system with 2x10^n
lines of code is an order of magnitude harder to maintain than
2x10^(n-1) lines of code.

Axiom is about 1.2 million lines, about half-way between n=5 and n=6
on the scale. I suspect that Mathematica is between n=6 and n=7.  I
don't know how any single person or small group could maintain that.
The pyramid law suggests that it needs about 10 maintainers active on
a daily basis. I don't know of any non-profit funding source for that.
The implication is that the loss of Mathematica will cause a "black
hole" in computational mathematics.

But, wait, ... the article cited above says we are all better off
because of "creative destruction"...

That may be true for physical goods but it is clearly not true
for computational mathematics.

The large systems all had their roots in early work in the field.
"New CAS" systems appear all the time (in fact, I collected and
distributed over 100 on a CD at ISSAC). Everyone who discovers a
new programming language seems to write a new CAS.

But the large systems are the result of hundreds of person-years
of implementation of research. Small, unfunded systems can't begin
to approach that power and complexity.

We need to move this vital collection of algorithm implementations
into a form that can preserve the level of complexity we have already
achieved.  If we don't, we face a serious crisis in computational
mathematics.

"Creative Destruction" may have a much different meaning soon.

Tim

\start
Date: Sun, 24 Aug 2014 12:08:03 -0500
From: daly@axiom-developer.org
To: Howard Cohl <howard.cohl@nist.gov>, Daniel Lozier <daniel.lazier@nist.gov>,
	Bruce Miller <bruce.miller@nist.gov>,
	"Marjorie A. McClain" <majorie.mcclain@nist.gov>,
	"Bonita.Saunders" <bonita.saunders@nist.gov>,
	Franky Backeljauw <franky.backeljauw@uantwerpen.be>,
	Stefan Becuwe <stefan.decuwe@uantwerpen.be>,
	Annie Cuyt <annie.cuyt@uantwerpen.be>
Subject: [Axiom-developer] Computational Mathematics
Cc: Paul Zimmermann <Paul.Zimmermann@loria.fr>,
	Tim Hopkins <t.r.hopkins@kent.ac.uk>, Ralf Hemmecke <ralf@hemmecke.de>,
	Wolfram Sperber <wolfram@zentralblatt-math.org>,
	Hans-Gert Graebe <hgg@hg-graebe.de>, axiom-developer@nongnu.org,
	Vinton Cerf <vgcerf@gmail.com>

All,

For those who don't know, I'm Tim Daly, Lead Developer on Axiom, an
open source computer algebra system
http://axiom-developer.org

I saw slides from a presentation about the NIST Digital Repository of
Mathematical Formulae. I'm interested in helping.

There appears to be an effort to move the book into an online form. I
saw items in there about "a high degree of computer verification". 

There are years of effort on a Computer Algebra Test Suite (CATS)
http://axiom-developer.org/axiom-website/CATS/index.html
from published tables and private communications. This effort includes
many thousands of test cases run in Axiom, all in machine readable
form. Axiom is mostly converted to "literate programs" in Latex and these
documents are also literate latex.

While the NIST DLMF is an amazing collection of formulas, it does not
address computational implementation issues such as the dependence of
integration algorithms on factoring algorithms.

The Axiom mailing list missives have been trying to raise interest in
a related area. We have been making computer algebra systems for the
last 40 years, accumulating implementations of algorithms in
computational mathematics. Unfortunately there is no "standard
reference" for these algorithms so it is highly likely that each CAS
will generate different answers.

Worse, as the computer algebra systems die, either from company deaths
(Symbolics/MACSYMA), purchase (Soft Warehouse/DERIVE), withdrawal
(NAG/Axiom), or loss of leader (Hearn/REDUCE) we lose valuable
implementations. The remaining systems (e.g. MATHEMATICA, MAPLE,
MATLAB, etc) will likely meet similar ends. 

This will leave a "black hole" in computational mathematics. Unlike
the 70s and 80s, there is no public financial support for building
large systems so these algorithmic implementations will simply
disappear. We must ensure that computational mathematics outlives
its founders.

We need to develop a standard set of algorithms along with
proofs, test cases, and implementation details. To this end I've
started collecting a bibliographic database of publications 
http://axiom-developer.org/axiom-website/lattice.html
by walking the bibliograpies of published papers. Currently it has
about 650 references, gaining about 50 per day. Also in-plan is 
providing links to published, freely available papers. 

>From this the plan is to collect the papers associated with an algorithm
and then show a series of ever more complex implementations, starting
with algorithms already implemented in Axiom.

Axiom has been instrumented to give detailed trace information so we can
build a tower of the algorithms required to do things like integration.

I believe it is important to get the computer algebra community
involved in the standard process. I'm willing to help where I can.

Tim Daly

\start
Date: Mon, 25 Aug 2014 14:16:54 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Computational Mathematics and Sage
Cc: William Stein <wstein@uw.edu>

"You will have to close source and commercialize Sage. It's inevitable"
Michael Monagan, cofounder of Maple, to William Stein.

Sage is a computer algebra system led by William Stein, originally
in the area of number theory but branching out to include other
systems including Axiom at one point. I've quoted from his post
http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-lets-clear-some.html

Stein tried hard to duplicate Magma, a large computer algebra system.
By his own admission, Sage has failed.

Consider this as an example of what will happen when Magma disappears,
an inevitable event by my own reasoning. 

There is no funding source for open source computational mathematics. 
I've tried with government, university, and commercial sources. Stein 
had a Google grant and university support but it was not enough. 
Without the university connection even Google wouldn't fund him.

The area of openly available computational mathematics is a love-it
or leave-it situation. I'm 14 years into the love-it side but I
understand why most people choose leave-it. Large systems like
Axiom are mind-bendingly complex to maintain, modify, and extend.
It is even a challenge to document obscure implementation details.
Do you really want to spend your nights, weekends, and vacations
debugging p-torsion bounds on elliptic curves? And do it for free?
Or fix up a broken port to Fedora because the NSA SELinux team
doesn't understand the Princeton architecture? (If so, email me).

Closed source, commercial computational mathematics is not inevitable.

We, as a community, cannot afford to let computational mathematics
depend solely on commercial software. Since all companies die, the
commercial software will disappear, taking all of us with it.

We need standard algorithms that are open, well documented, and
well implemented, supported by a standards organizations (NIST? ISO?),
published in a standard format and kept up to date.

We need computational mathematics courses based on openly
available, well-documented software to teach the next generation. 

We need it now.

Tim


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

Sage is Failing

Measured by the mission statement, Sage has overall failed. The core
goal is to provide similar functionality to Magma (and the other Ma's)
across the board, and the Sage development model and community has
failed to do this across the board, since after 9 years, based on our
current progress, we will never get there. There are numerous core
areas of research mathematics that I'm personally familiar with (in
arithmetic geometry), where Sage has barely moved in years and Sage
does only a few percent of what Magma does. Unless there is a viable
plan for the areas to all be systematically addressed in a reasonable
timeframe, not just with arithmetic geometry in Magma, but with
everything in Mathematica, Maple., etc, we are definitely failing at
the main goal I have for the Sage math software project.

I have absolutely no doubt that money combined with good planning and
management would make it possible to achieve our mission
statement. I've seen this hundreds of times over at a small scale at
Sage Days workshops during the last decade. And let's not forget that
with very substantial funding, Linux now provides a viable free open
source alternative to Microsoft Windows. Just providing Sage
developers with travel expenses (and 0 salary) is enough to get a huge
amount done, when possible. But all my attempts with foundations and
other clients to get any significant funding, at even the level of 1%
of the funding that Mathematica gets each year, has failed. For the
life of the Sage project, we've never got more than maybe 0.1% of what
Mathematica gets in revenue. It's just a fact that the mathematics
community provides Mathematica $50+ million a year, enough to fund
over 600 fulltime positions, and they won't provide enough to fund one
single Sage developer fulltime.

But the Sage mission statement remains, and even if everybody else in
the world gives up on it, I HAVE NOT. SMC is my last ditch strategy to
provide resources and visibility so we can succeed at this goal and
give the world a viable free open source alternative to the Ma's. I
wish I were writing interesting mathematical software, but I'm not,
because I'm sucking it up and playing the long game.

\start
Date: Thu, 28 Aug 2014 14:24:44 -0500
From: daly@axiom-developer.org
To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] [Gcl-devel] selinux support
Cc: axiom-developer@nongnu.org, Jerry James <loganjerry@gmail.com>,
	GCL Development <gcl-devel@gnu.org>

Camm,

I'm fine with requiring changes to the SELinux permissions in order
to run the system. The NSA/SELinux team seems determined to try to
create a Harvard architecture on a Princeton architecture machine.
The idea of executing code from the heap or creating self-modifying
code? Only someone with evil intent would think of such things. Sigh.
Security people love to make a system "secure" by making it unusable
instead of attacking the real problem (badly written software).

Thanks for your time and effort on this.

Tim


>Greetings!
>
>Tim -- are you ok now with 
>
>1) the selinux workaround with fedora lifetime of ~ 1 year and 
>2) the package maintainer/end user workarouns mentioned below
>
>for axiom on selinux systems using gcl 2.6.11pre?
>
>I really don't know what else to do.  If someone is using a computer
>owned by someone else who does not want anyone to allocate executable
>memory, they are going to have to get some sort of special permission if
>gcl is going to work.  I imagine ld.so has been granted said permission
>in similar fashion.
>
>What would be fantastic would be a bit we could set in gcl unexeced
>binaries to specify the required permissions for *all* gcl programs in
>one place.  Then the sysadmin people could permit/deny to their heart's
>content.  I suppose this is what chcon does, but I suppose there is no
>trans system standardization to 'gcl_exec_t'.
>
>Take care,
>
>
>
>Jerry James <loganjerry@gmail.com> writes:
>
>> On Thu, Aug 21, 2014 at 2:06 PM, Camm Maguire <camm@maguirefamily.org> wrote:
>>> Thank you so much for this.  So I suppose this means this personality
>>> bit will be completely meaningless?
>>
>> On future versions of Fedora, yes.  It may be a reasonable workaround
>> for other distributions for some time to come.  (And it will work on
>> Fedora 20 until it reaches End Of Life sometime next year.)
>>
>>> I will have to read up on selinux 'policy' files.  I take it this means
>>> an ordinary user will not be able to build gcl and or dependencies on
>>> fedora.  I take it also that every application which unexec's an image
>>> compiled by gcl will have to either be listed in this policy file or
>>> some other one.  Do such things belong in the gcl source tree?
>>
>> Yes and no.  Programs built by a user in his/her home directory and
>> executed only by that user can use some tricks to get around
>> system-wide policy (see below).  This is "safe" because any damage
>> from an exploit is confined to the user's own files.  The situation I
>> have to deal with as the maintainer of the gcl package for Fedora is
>> that the binaries are installed in /usr/bin, and have to work for all
>> users.
>>
>> Package maintainers like me need some way to affect system-wide
>> SELinux policy for gcl and any programs built by gcl.  One way to do
>> that is to tell sysadmins that they need to do this (untested):
>>
>> setsebool -P deny_execmem=0
>>
>> - OR -
>>
>> setsebool -P allow_execmem=1
>>
>> depending on which boolean is provided.  But that will allow ALL
>> programs, not just those related to gcl, to mark memory as executable.
>> (Fedora actually defaults to allowing execmem, at the moment.  But
>> since sysadmins can change that, I ship SELinux policy to allow gcl to
>> run in either case.)  The policy files I provided allow a sysadmin to
>> specify that executables marked with the SELinux type gcl_exec_t are
>> allowed the execmem permission, and specifies that gcl and maxima both
>> be so marked.
>>
>> If I'm building gcl in my home directory, for just my personal use, on
>> the other hand, I may have other options.  If my sysadmin has set
>> policy that allows some program, ANY program, to run with execmem
>> permission, I can hijack the corresponding type for my own purposes.
>> For example, if I know that lpr_exec_t provides execmem permission (I
>> don't, by the way), then I can either run my gcl-built programs in
>> one-shot mode like this:
>>
>> runcon -t lpr_exec_t my_personal_gcl_program
>>
>> or if I intend to keep an executable around for awhile, I can
>> permanently mark it, like so:
>>
>> chcon -t lpr_exec_t my_personal_gcl_program
>>
>>> I do understand how the personality bit bypasses policy, but it seems
>>> this was what was intended in supporting 'legacy' applications, and
>>> gcl's approach certainly pertains to the traditional unix memory
>>> management model.
>>
>> Yes, but it appears that the SELinux Powers That Be have decided that
>> READ_IMPLIES_EXEC is a security hole, and plan to close it.
>>
>>> It appears that all this obstruction is simply seeking assurance that
>>> code has no predictable address relationship with data.  I'm wondering
>>> how much randomness is required, and if gcl could not simply randomly
>>> offset code when loading and satisfy all these concerns, and then be
>>> left alone :-).
>>
>> Try running that by the SELinux folks and see what they say. :-)
>>
>> By the way, I am not in any imaginable way an expert on SELinux, so
>> take all of the foregoing with a grain of salt.  Regards,
>


\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
