\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: Tue, 4 Apr 2017 22:20:26 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Jeremy Avigad <avigad@cmu.edu>, Laurent Thery <Laurent.Thery@inria.fr>, 
	Renaud Rioboo <renaud.rioboo@ensiie.fr>, Kurt Pagani <nilqed@gmail.com>,
	Barry M Trager <bmt@us.ibm.com>, Martin Baker <ax87438@martinb.com>,
	Frank Pfenning <fp@cs.cmu.edu>
Subject: [Axiom-developer] Proving Axiom Correct: Homotopy Type Theory

There has been a "great merger" of the ideas of Type Theory,
Category Theory, and Proof Theory. There is an interpretation
of a result in one in terms of the other two.

There has recently been a fundamentally new area of mathematics
that merges ideas from those three areas with algebraic topology.
This area is called "Homotopy Type Theory". It appears to be a
"computable form of mathematics".

This represents, as near as I can understand, a new theory
as fundamental as group theory. Axiom uses group theory as an
organizing scaffold for the algebra, giving it a clean structure.

Homotopy Type Theory (HoTT) looks like it could give Axiom a
second scaffold of Type Theory / Proof Theory for proving
computational mathematics correct.

In particular, it seems that this "second Axiom scaffold", when the
theorems and proofs are matched with the group theory scaffold,
will give Axiom a very firm foundation for computational
mathematics.

Like group theory, HoTT is a steep hill to climb. There is a book
(available as a free PDF from HomotopyTypeTheory.org) called
Homotopy Type Theory: Univalent Foundations of Mathematics.
It is the work of a large group of mathematician, published by the
Institute for Advanced Study.

The HoTT book is an intimidating piece of reading if you're not
familiar with all of the areas. A more gentle introduction would be
Pelayo and Warren, "Homotopy Type Theory and Voevodsky's
Univalent Foundations" (https://arxiv.org/pdf/1210.5658.pdf)

This is the very bleeding edge of computational mathematics
and should put Axiom in the very heart of the developments.
A computer algebra system with proven soundness would change
the whole field.

Tim

\start
Date: Thu, 6 Apr 2017 01:24:39 +0000 (UTC)
From: C Y <smustudent1@yahoo.com>
To: Tim Daly <axiomcas@gmail.com>, axiom-dev <axiom-developer@nongnu.org>, 
	Martin Baker <ax87438@martinb.com>, Tim Daly <daly@axiom-developer.org>, 
	Laurent Thery <Laurent.Thery@inria.fr>, Jeremy Avigad <avigad@cmu.edu>, 
	Renaud Rioboo <renaud.rioboo@ensiie.fr>, 
	Kurt Pagani <nilqed@gmail.com>, Frank Pfenning <fp@cs.cmu.edu>
Subject: Re: [Axiom-developer] Proving Axiom Correct -- at the C level

> On Friday, March 31, 2017, 7:16:32 PM EDT, Tim Daly <axiomcas@gmail.com> =
wrote:
> I previously mentioned the "proof tower" approach to the question
> of proving code at many different layers. Spad code proven in COQ,
> Lisp code in ACL2, and Intel code in CCAs. The missing step in the
> tower was C.

Rather than introduce another complex language and proof problem into the s=
tack, would it be possible to have Lisp implemented directly "on the metal"=
?=C2=A0 If SBCL isn't the preferred approach to such a system, maybe the fo=
llowing project could be used as a starting point to put together a purpose=
 built LISP?

https://github.com/robert-strandh/SICL
Maybe some of the open source "LISP as OS" projects could offer lower level=
 primitives from which to build the boot strapping code, or a basic set cou=
ld be defined in x86-64...=C2=A0 I suppose it's academic at this point, but=
 I can't help wondering if there would be simplicity gains in the "expressi=
ng and defining proof stacks" department that would make it worthwhile in t=
he long run to hold the number of conceptual expression languages down to t=
he minimum necessary.
CY

\start
Date: Thu, 6 Apr 2017 11:41:17 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Small documentation issue

Tim,

Just a small documentation issue.

This line appears to be duplicated in the PDF:

"Permutation is a domain which can be used to compute permutations. It
is also an implementation of Group category."

In books/bookvol10.3.pamphlet its at line 145509.

I assume you would prefer me to let you know about this by email, like 
this, rather than cloning github and sending you a pull request?

One other thing:

Some of the diagrams have been expanded making them look blocky. the 
original diagrams are in scalable (.svg) form so its easy to export 
them, at other sizes, to .png or .gif (not .eps). However I think the 
document would be more readable if the diagrams were not larger than 
necessary. To my eye, a lot of skipping over big diagrams makes reading 
harder (it would be even better if text flowed around diagrams). This is 
a very minor thought and not worth spending much time on.

More generally, on the topic of documentation. It would be possible to 
write a lot more about the group theory around these domains. For 
instance, explanations of concepts like 'generators' and so on. The 
information added here was intended to be the aspects that are not 
easily found in maths textbooks. I do agree with some of your earlier 
posts that you made about the potential benefit that Axiom could bring 
to mathematics education, just the discipline it brings to having a 
consistent notation across the whole subject seems enormously valuable 
to me. However cramming an explanation of the whole of mathematics into 
bookvol10.3.pamphlet seems a bit over ambitious to me so perhaps its 
best not to try to explain everything?

Martin

\start
Date: Thu, 6 Apr 2017 07:08:44 -0400
From: Tim Daly <axiomcas@gmail.com>
To: C Y <smustudent1@yahoo.com>,
	=?UTF-8?Q?Andr=C3=A9_Platzer?= <aplatzer@cs.cmu.edu>
Subject: Re: [Axiom-developer] Proving Axiom Correct -- at the C level
Cc: axiom-dev <axiom-developer@nongnu.org>, Martin Baker <ax87438@martinb.com>,
	Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, 
	Jeremy Avigad <avigad@cmu.edu>, Renaud Rioboo <renaud.rioboo@ensiie.fr>,
	Kurt Pagani <nilqed@gmail.com>, Frank Pfenning <fp@cs.cmu.edu>

Yes, I'd like to have a solid "floor" to the proofs and the fewer layers,
the better.

An issue arises when looking to prove the propositions for the Domain
NonNegativeInteger (NNI). This is closely related to the 'nat' domain in
proof
systems. However, NNI relies on calls to Lisp for things like defining
equality. Lisp equality is a much-discussed question involving EQ, EQUAL,
etc. which eventually gets resolved down to the machione level. So no
matter which lisp is used, the machine gets involved it seems.

If I "misunderstand" Homotopy Type Theory there is an axiom of
"Univalence" which states that equality is equivalence. Given that,
it might be possible to establish a "floor" at the Spad level so we
do not even have to provide proofs of lisp and below. For me this
is an open research question.

I am still studying the HoTT work. I haven't seen it used for algorithms
like Groeber basis. There is some interesting work by Andre Platzer
which uses substituion as the basis of sound reasoning.
http://dx.doi.org/10.1007/s10817-016-9385-1
>From my limited understanding so far it appears to be similar to
Hoare triples on steroids. This might prove very useful for handling
imperative programs. Again, for me this is an open research question.

Here's some things he's been doing in the realm of real arithmetic
http://www.cs.cmu.edu/~aplatzer/pub/rwv.pdf
Generally, rigorously proving valid facts of first-order real arithmetic /
unsatisfiability
of a set of polynomial inequalities is quite important for his work. He
does some
nice things with Groeber basis.

I've collected the "category tower" in Axiom for NNI along with their
associated propositions. I'm trying to do something trivial by hand so
I can understand the research questions better. When I get an example
I'll post the results here.

Tim




On Wed, Apr 5, 2017 at 9:24 PM, C Y <smustudent1@yahoo.com> wrote:

> > On Friday, March 31, 2017, 7:16:32 PM EDT, Tim Daly <axiomcas@gmail.com>
> wrote:
> > I previously mentioned the "proof tower" approach to the question
> > of proving code at many different layers. Spad code proven in COQ,
> > Lisp code in ACL2, and Intel code in CCAs. The missing step in the
> > tower was C.
>
> Rather than introduce another complex language and proof problem into the
> stack, would it be possible to have Lisp implemented directly "on the
> metal"?  If SBCL isn't the preferred approach to such a system, maybe the
> following project could be used as a starting point to put together a
> purpose built LISP?
>
> https://github.com/robert-strandh/SICL
>
> Maybe some of the open source "LISP as OS" projects could offer lower
> level primitives from which to build the boot strapping code, or a basic
> set could be defined in x86-64...  I suppose it's academic at this point,
> but I can't help wondering if there would be simplicity gains in the
> "expressing and defining proof stacks" department that would make it
> worthwhile in the long run to hold the number of conceptual expression
> languages down to the minimum necessary.
>
> CY
>

\start
Date: Thu, 6 Apr 2017 17:36:56 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Martin Baker <ax87438@martinb.com>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Small documentation problem

I'll fix the duplicate line. Thanks for the bug report.
Any path that is convenient for reporting bugs is ok.

re: diagrams.

The diagrams in the Axiom pdf use .eps (which is
encapsulated postscript, i.e. postscript with size info).
The eps files live in books/ps with the convention that
    books/ps/v103*
are images in volume 10.3. Your images are
    books/ps/v103permgrpxx.eps
where xx is a sequential number.

If you tar up the .svg diagrams I can redo the images.

Alternatively, the pamphlet files are just raw latex. If you
cd to the books directory you should be able to just do
   gcc -o tanglec tanglec.c
to get the tanglec program. You only need to do this once.

   ./tanglec bookvolbib.pamphlet axiom.bib >axiom.bib
   latex bookvol10.3.pamphlet
   makeindex bookvol10.3.idx
   bibtex bookvol10.3.aux
   latex bookvol10.3.pamphlet
   latex bookvol10.3.pamphlet
   dvipdfm bookvol10.3.dvi
   evince bookvol10.3.pdf

Open a shell to run the above commands in a bash script.
If you leave the pdf viewer running it will update automatically
every time you remake the file. So you get a "hot loop' where
you change the pamphlet file, run the bash script, and see the
result immediately.

When you are happy with the changes you can do

   git diff books/bookvol10.3.pamphlet >patchfile

and send me the patch file.

Tim



re: too much information

The target audience is students. I'm about to be a visiting
scholar at CMU and I hope to set up a seminar series to
attract students to working with Axiom. Since these are CS
students, not Math students, I assume they have very little
if any idea about group theory concepts.

Topics of a general nature would likely go into Volume 1, the
Axiom Tutorial. Topics specific to new algebra would modify
Volume 0, the Jenks book, in the appropriate algebra location,
in the help files, in hyperdoc, and in the (as yet unpublished)
web pages.

So there is a place somewhere in the system for documentation
at almost any level. Indeed, if all else seems inappropriate there
can always be a new volume.

Tim



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