\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, 5 May 2015 10:42:38 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Computerising Mathematical Text

This is an interesting paper:

Computerising Mathematical Text
http://repository.ubn.ru.nl/bitstream/handle/2066/134655/134655.pdf?sequence=1

Tim

\start
Date: Wed, 6 May 2015 08:48:49 -0500
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>, axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] new docker image

The command:

   docker run -i -i daly/axiom axiom   : fails on Ubuntu 14.01 ....

looks like a typo on my part. Try 

   docker run -i -t daly/axiom axiom   : fails on Ubuntu 14.01 ....

and let me know. I should be publishing a new docker image shortly.

Tim

\start
Date: Thu, 7 May 2015 22:20:14 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Why proving Axiom correct is important

Mathematicans need to be able to rely on the algorithms.

http://nautil.us/issue/24/error/in-mathematics-mistakes-arent-what-they-used-to-be

\start
Date: Fri, 8 May 2015 04:02:23 -0500
From: daly@axiom-developer.org
To: "William Sit" <wyscc@sci.ccny.cuny.edu>
Subject: [Axiom-developer] (no subject)

> Unfortunately, algorithms not only must be proved 
> mathematically correct, but also be implemented correctly.
>
> There is no fail-safe way to do mathematics other than 
> never leaving any "trivial" or "obvious" claims unchecked, 
> by multiple referees who would have to do the hard work. 
> Nowadays, however, few referees did that. Authors must 
> also accept responsibility for their work.

There is responsibility all the way around.

But if you're going to use a result from Axiom as a step in a proof it
is the role of the Axiom algorithm developer to provide a proof of the
algorithm. And publish the proof so others can reference the proof.

At the moment there is little more than hand-waving, 1800s style. 
"This algorithm implements a commutative function F".  Really?
For all inputs? Or is there a limit to the domain? You used a
function with branch cuts. Which cuts? Does it matter to your
proof? Can you reference the proof of the algorithm you rely upon?

We call this area "computational mathematics" but the emphasis has
been more on the "computational" and less on the "mathematics".

The current state of affairs looks as though we picked up a mathematics 
textbook, copied all of the equations, threw away all the words, and
encrypted the equations in an obscure language.

In my mind, at least, the time has come to "refocus the lens".
Unlike the rest of software, computational mathematics has theory 
behind the algorithms. 

The tools are becoming available (e.g. COQ, ACL2, etc.) to aid proof 
development. The theory exists but is divorced from the code. That was
fine for a "first generation system" like Axiom. But the time has come
for "second generation systems".

It is clear what needs to be done. 
It is clear why it needs to be done.
It is not clear how to do it... which makes it research.
Unfunded research, unfortunately.

At the moment we're in the "stagger around" phase of the research.
Find the papers. Gather a pile. Write a survey. Do an example.
Build a tool. Muscle through a trivial proof. Yaknow, research...

Axiom Volume 13 is the start of the pile. If you find any papers
or articles that might be of interest to the goal, please let me know.

Tim


\start
Date: Fri, 08 May 2015 16:20:45 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Why proving Axiom correct is important

On 08/05/15 10:02, daly@axiom-developer.org wrote:
> Axiom Volume 13 is the start of the pile. If you find any papers
> or articles that might be of interest to the goal, please let me know.

Tim,

I am currently reading Nipkow/Klien [1] just to get a top level view of 
the subject (I have not looked at any research papers).

The book is based around Isabelle/HOL so if you don't want to use 
Isabelle the book may not be of interest to you? I have only just 
started reading the book so I don't have any great insights to give.

I get the impression that what proof assistants / interactive theorem 
provers are about is proving equations/theories from other theories 
using logic and proof methods like induction. I think what you are 
talking about is proving algorithms correct (Semantics?) this is covered 
in part 2 of the book. Do you think these sort of approaches: 
Denotational Semantics, Small-step Semantics, Big-step Semantics and so 
on are what you are aiming at?

I get the impression that using a separate proof assistant is not ideal 
and there would be a lot of advantages in combining the symbolic algebra 
program (Axiom) with the logic/proof assistant. Apart from anything else 
the learning curve is as steep as Axiom! The problem for me is the 
massive and confusing overlap of these types of program. Not just the 
program but, more importantly, the libraries. As you can see from the 
libraries here:
http://isabelle.in.tum.de/dist/library/HOL/index.html
it contains most of the same algebras as Axiom but in a slightly 
different hierarchy.

A possible first step would be to encode axioms/rules/identities in each 
Axiom category/domain. If nothing else this would allow automatic 
generation of test code at random values, this is not proof but it would 
be a first step to proofs at a later stage.

Martin

[1] Concrete Semantics with Isabelle/HOL, Nipkow/Klien, 2014, ISBN 
978-3-319-10541-3

\start
Date: Fri, 8 May 2015 15:40:32 -0500
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>
Subject: Re: [Axiom-developer] Why proving Axiom correct is important

Martin,

>The book is based around Isabelle/HOL so if you don't want to use 
>Isabelle the book may not be of interest to you? I have only just 
>started reading the book so I don't have any great insights to give.

Actually, Lamport's "How to write 21st Century Proofs" and 
"Specifying Systems" is the most recent bit of study. He has talks
on Youtube about it.



>I get the impression that what proof assistants / interactive theorem 
>provers are about is proving equations/theories from other theories 
>using logic and proof methods like induction. I think what you are 
>talking about is proving algorithms correct (Semantics?) this is covered 
>in part 2 of the book. Do you think these sort of approaches: 
>Denotational Semantics, Small-step Semantics, Big-step Semantics and so 
>on are what you are aiming at?

We really need "full stack" proofs. COQ/TLA for the Spad to Lisp layer
(since Spad is really just a domain-specific language on a lisp base).
ACL2 for the Lisp to C layer (since we use GCL), LLVM to ACL2
translator for the C layer (the Vellvm effort), and CCAs (Conditional
Concurrent Assignments, for Intel machine instruction semantics, my
prior research work) for the C to machine layer.




>I get the impression that using a separate proof assistant is not ideal 
>and there would be a lot of advantages in combining the symbolic algebra 
>program (Axiom) with the logic/proof assistant. Apart from anything else 
>the learning curve is as steep as Axiom! The problem for me is the 
>massive and confusing overlap of these types of program. Not just the 
>program but, more importantly, the libraries. As you can see from the 
>libraries here:
>http://isabelle.in.tum.de/dist/library/HOL/index.html
>it contains most of the same algebras as Axiom but in a slightly 
>different hierarchy.

ACL2 is in Common Lisp and can be layered underneath Axiom so that
some of its capabilities can be exposed as domains/packages. This
would allow proofs to be expressed in Spad as a mathematical feature.
It would also allow automatic checks during builds. This existed 
locally but was never pushed into the repository.

One should be able to do ")exhibit gcd" to see the proof support
for the function and ")exhibit GCDDOM" to see the category proof.
These ought to be static objects once the proof exists.



>A possible first step would be to encode axioms/rules/identities in each 
>Axiom category/domain. If nothing else this would allow automatic 
>generation of test code at random values, this is not proof but it would 
>be a first step to proofs at a later stage.

There exists a few mathematical axiom statements in the category book
(Volume 10.2), associated with each category (look at SemiGroup for
example). The intention is to decorate all of the categories and
domains with mathematical axioms which can be assumed in the proof.

Much more work needs to be done to just look up the standard axioms
for the various categories. Feel free to contribute by looking up
what the group/ring/field/etc axioms should be. They will be added
to the approprate categories.

The plan is to add an "axioms" category with an "axioms" function
export so you can query the axioms that something should obey from
code or the command line.




At the lisp level (Volume 5 Interpreter, Volume 9 Compiler), there is
a new Latex tag \sig which supports Haskell-style signatures for lisp
code. (See intloopPrefix? for an example.) The intention is to add
signatures to all of the functions. This will allow the proof engine
to move along the signature space.

Along with this effort the interpreter/compiler is being slowly
redesigned to be more functional-programming oriented. The plan is to
remove the globals, create lisp-level types using defstructs, and
introduce strict type decorations using lisp declare statements.
Removing/hoisting side-effects is an essential step. 

There is a book called "The Semantics of Destructive Lisp" (free pdf
online) which talks about functions which modify their arguments and
internals, as Spad is known to do. There is also work on the
Denotational Semantics of Lisp. Fred Blair wrote a paper defining
the denotational semantics of Lisp/370 years ago.




The proof volume (Volume 13) is taking a middle-out approach, starting
with an attempt to prove Axiom's implementation of Euclid's algorithm.
The goal is to "work at the coal-face" of the problem to see what is
needed and what works. Pointers to online versions of Euclid proofs
are most welcome.

Tim

\start
Date: Sat, 09 May 2015 09:37:15 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Why proving Axiom correct is important

On 08/05/15 21:40, daly@axiom-developer.org wrote:
> There exists a few mathematical axiom statements in the category book
> (Volume 10.2), associated with each category (look at SemiGroup for
> example). The intention is to decorate all of the categories and
> domains with mathematical axioms which can be assumed in the proof.
>
> Much more work needs to be done to just look up the standard axioms
> for the various categories. Feel free to contribute by looking up
> what the group/ring/field/etc axioms should be. They will be added
> to the approprate categories.
>
> The plan is to add an "axioms" category with an "axioms" function
> export so you can query the axioms that something should obey from
> code or the command line.

Tim,

If you are using COQ then why not just map the COQ library entries into 
the Axiom categories?
So if we take part of the base library here:
https://coq.inria.fr/library/Coq.Arith.Mult.html#

So the appropriate Axiom category could have an entry like:

Zero property
Lemma mult_0_r : forall n, n * 0 = 0.
Lemma mult_0_l : forall n, 0 * n = 0.

Of course the COQ libraries have a different structure than the Axiom 
libraries so there is no exact mapping between them but it would seem to 
be a good idea to have as much compatibility as possible rather than 
invent something from scratch?

Looking at these they are not 'axioms' in that they have redundancy.

For example there is also the following
Commutativity
Lemma mult_comm : forall n m, n * m = m * n.

So mult_0_l could have been derived from mult_0_r.

Do you propose to have a minimal set of axioms or to have a larger set 
of lemmas?

The form you have used in 10.2 is like this (in the human readable LP 
part - not part of the category itself):
Axioms:
associative("*":(%,%)->%)    (x*y)*z = x*(y*z)
Conditional attributes:
commutative("*":(%,%)->%)    x*y = y*x

Are you proposing to put this into the category itself, not just as a 
comment? Do you prefer this syntax over the COQ syntax?

Isabelle uses a different approach again (in the flavor of Isabelle I 
have seen so far) in that it uses 'rules' instead of 'axioms'

So instead of:
n * 0 = 0

We have separate rules for each direction:
n * 0 ==> 0
0 ==> n * 0

So the first direction can be declared as a simplification rule and can 
be applied without any danger of an infinite loop.

The advantage that I could see, for this in Axiom, is that the 
simplification that is applied to equations in the output formatter 
could be made explicit, configurable and provable.

Do you have a view on axioms vs. lemmas vs rules?
Are you proposing to put this into SPAD itself rather than comments or LP?

Martin

\start
Date: Sat, 9 May 2015 07:05:50 -0500
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Martin Baker <ax87438@martinb.com>
Subject: Re: [Axiom-developer] Why proving Axiom correct is important

I had actually had something similar in one of OpenAxiom's branch.


On Sat, May 9, 2015 at 3:37 AM, Martin Baker <ax87438@martinb.com> wrote:

> On 08/05/15 21:40, daly@axiom-developer.org wrote:
>
>> There exists a few mathematical axiom statements in the category book
>> (Volume 10.2), associated with each category (look at SemiGroup for
>> example). The intention is to decorate all of the categories and
>> domains with mathematical axioms which can be assumed in the proof.
>>
>> Much more work needs to be done to just look up the standard axioms
>> for the various categories. Feel free to contribute by looking up
>> what the group/ring/field/etc axioms should be. They will be added
>> to the approprate categories.
>>
>> The plan is to add an "axioms" category with an "axioms" function
>> export so you can query the axioms that something should obey from
>> code or the command line.
>>
>
> Tim,
>
> If you are using COQ then why not just map the COQ library entries into
> the Axiom categories?
> So if we take part of the base library here:
> https://coq.inria.fr/library/Coq.Arith.Mult.html#
>
> So the appropriate Axiom category could have an entry like:
>
> Zero property
> Lemma mult_0_r : forall n, n * 0 = 0.
> Lemma mult_0_l : forall n, 0 * n = 0.
>
> Of course the COQ libraries have a different structure than the Axiom
> libraries so there is no exact mapping between them but it would seem to be
> a good idea to have as much compatibility as possible rather than invent
> something from scratch?
>
> Looking at these they are not 'axioms' in that they have redundancy.
>
> For example there is also the following
> Commutativity
> Lemma mult_comm : forall n m, n * m = m * n.
>
> So mult_0_l could have been derived from mult_0_r.
>
> Do you propose to have a minimal set of axioms or to have a larger set of
> lemmas?
>
> The form you have used in 10.2 is like this (in the human readable LP part
> - not part of the category itself):
> Axioms:
> associative("*":(%,%)->%)    (x*y)*z = x*(y*z)
> Conditional attributes:
> commutative("*":(%,%)->%)    x*y = y*x
>
> Are you proposing to put this into the category itself, not just as a
> comment? Do you prefer this syntax over the COQ syntax?
>
> Isabelle uses a different approach again (in the flavor of Isabelle I have
> seen so far) in that it uses 'rules' instead of 'axioms'
>
> So instead of:
> n * 0 = 0
>
> We have separate rules for each direction:
> n * 0 ==> 0
> 0 ==> n * 0
>
> So the first direction can be declared as a simplification rule and can be
> applied without any danger of an infinite loop.
>
> The advantage that I could see, for this in Axiom, is that the
> simplification that is applied to equations in the output formatter could
> be made explicit, configurable and provable.
>
> Do you have a view on axioms vs. lemmas vs rules?
> Are you proposing to put this into SPAD itself rather than comments or LP?
>
> Martin

\start
Date: Sat, 9 May 2015 12:17:32 -0500
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>
Subject: Re: [Axiom-developer] Why proving Axiom correct is important

Martin,

>If you are using COQ then why not just map the COQ library entries into 
>the Axiom categories?
>So if we take part of the base library here:
>https://coq.inria.fr/library/Coq.Arith.Mult.html#

>So the appropriate Axiom category could have an entry like:

>Zero property
>Lemma mult_0_r : forall n, n * 0 = 0.
>Lemma mult_0_l : forall n, 0 * n = 0.

I will look into this. Thanks for the pointer.




>Of course the COQ libraries have a different structure than the Axiom 
>libraries so there is no exact mapping between them but it would seem to 
>be a good idea to have as much compatibility as possible rather than 
>invent something from scratch?

There are no plans to invent anything from scratch. This is research,
which implies understanding and using what exists before pushing a
boundary. The bibliography volume has references on the subject but
these need to be organized, maybe into a survey paper.




>Looking at these they are not 'axioms' in that they have redundancy.

>For example there is also the following
>Commutativity
>Lemma mult_comm : forall n m, n * m = m * n.

>So mult_0_l could have been derived from mult_0_r.

>Do you propose to have a minimal set of axioms or to have a larger set 
>of lemmas?

There is no need for a minimal set. Special cases like 0 arise all
the time so it is just as easy to check for a few special cases.
Knowing that n=0 can cause a lot of simplification early in the process
which can only be a good thing.




>The form you have used in 10.2 is like this (in the human readable LP 
>part - not part of the category itself):
>Axioms:
>associative("*":(%,%)->%)    (x*y)*z = x*(y*z)
>Conditional attributes:
>commutative("*":(%,%)->%)    x*y = y*x

>Are you proposing to put this into the category itself, not just as a 
>comment? Do you prefer this syntax over the COQ syntax?

The effort at this point is collecting the information to decorate the
algebra and lisp code. There are no particular syntax requirements at
the moment because all of my reference material is from books.

You raised the interesting question of COQ vs Isabelle vs books.
It might make sense to introduce an "Axioms" category to collect
operations that make sense. In fact, there is no reason why, with
careful thought, there might be operations on the same internal
structures which present the COQ or Isabell or book form output

  )abbrev category AXIOMS Axioms
   ...
  COQ: () -> List(COQ-axioms)
  Isabell: () -> List(Isabelle rules)
  Book: () -> List(traditional book axioms)

This has the advantage that a domain can inherit the axioms which
would make it easy to see when things disagree or are incomplete.




>Isabelle uses a different approach again (in the flavor of Isabelle I 
>have seen so far) in that it uses 'rules' instead of 'axioms'

>So instead of:
>n * 0 = 0

>We have separate rules for each direction:
>n * 0 ==> 0
>0 ==> n * 0

>So the first direction can be declared as a simplification rule and can 
>be applied without any danger of an infinite loop.

>The advantage that I could see, for this in Axiom, is that the 
>simplification that is applied to equations in the output formatter 
>could be made explicit, configurable and provable.

>Do you have a view on axioms vs. lemmas vs rules?

There is no way to decide this at the moment. Rules seems to be more
"actionable" for writing code but lemmas seem to be more "composable".
Axiom tends toward the actionable so Isabelle's approach might make
more sense. COQ seems closer to Axiom in design.




>Are you proposing to put this into SPAD itself rather than comments or LP?

This is the design phase of the problem, collecting information.
At the moment it is just dead text being added to the files. However
the idea is to make it useful for two levels. At one level the proof
mechanism should be able to use the assumptions in a proof. At another
level Axiom should make the assumptions available to the algorithms
and the end user. So, to answer your question, this will be SPAD level
code rather than just comments.

SPAD is really just a domain-specific language layered on top of Lisp.
The lisp code is also being decorated with type information. There 
needs to be some careful thought to ensure that the two sources of
information are synergistic.

So there needs to be some thought given to encoding the assumptions
to fulfill these goals. Suggestions are welcome.

Tim

\start
Date: Sat, 16 May 2015 10:18:26 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] New Docker Image posted

The main change has been a major review and cleanup of the regression
test cases across all categories, domains, and packages. This is part
of the build automation effort and should have no visible effects.
(image 29c81235c617)

  docker pull daly/axiom
  docker run -i -t daly/axiom axiom

Tim

\start
Date: Sun, 17 May 2015 08:20:17 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] New Docker Image posted

Worked on Ubuntu 14.04 ?
No Hyperdoc though?


On 05/16/2015 11:18 AM, daly@axiom-developer.org wrote:
> docker run -i -t daly/axiom axiom

Raymond Rogers

\start
Date: Thu, 21 May 2015 12:44:59 +0000
From: David B. <david.bojanic@hotmail.com>
To: "=?utf-8?Q?axiom-developer@nongnu.org?=" <axiom-developer@nongnu.org>
Subject: [Axiom-developer] =?utf-8?q?Axiom_installation?=

--_B456DDEF-183B-4AFF-A736-C9F9D25ED93B_
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

SGVsbG8sIA0KDQpJIGFtIHRyeWluZyB0byBpbnN0YWxsIGF4aW9tIG9uIG15IHdpbmRvd3MgNyBs
YXB0b3AuDQpJIGFtIGZvbGxvd2luZyB0aGUgbWFudWFsIG9uIGhvdyB0byBpbnN0YWxsIGl0LCBi
dXQgSSBjYW5ub3Qgc2VlbSB0byBmaW5kIHRoZSBheGlvbS50Z3ogZmlsZS4NCkNvdWxkIHlvdSBw
bGVhc2UgcG9pbnQgbWUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBhcyB3aGVyZSB0byBmaW5kIGl0
Lg0KDQpUaGFuayB5b3UgaW4gYWR2YW5jZS4NCg0KUmVnYXJkcywNCg0KRGF2aWQu

--_B456DDEF-183B-4AFF-A736-C9F9D25ED93B_
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h
aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt
LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy
YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206
MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0
b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh
Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0
UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N
c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs
aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg
ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h
cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK
fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz
dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl
Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n
SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48
ZGl2PkhlbGxvLCZuYnNwOzwvZGl2PjxkaXY+SSBhbSB0cnlpbmcgdG8gaW5zdGFsbCBheGlvbSBv
biBteSB3aW5kb3dzIDcgbGFwdG9wLjxicj5JIGFtIGZvbGxvd2luZyB0aGUgbWFudWFsIG9uIGhv
dyB0byBpbnN0YWxsIGl0LCBidXQgSSBjYW5ub3Qgc2VlbSB0byBmaW5kIHRoZSBheGlvbS50Z3og
ZmlsZS48YnI+Q291bGQgeW91IHBsZWFzZSBwb2ludCBtZSBpbiB0aGUgcmlnaHQgZGlyZWN0aW9u
IGFzIHdoZXJlIHRvIGZpbmQgaXQuPC9kaXY+PGRpdj5UaGFuayB5b3UgaW4gYWR2YW5jZS48L2Rp
dj48ZGl2PlJlZ2FyZHMsPC9kaXY+PGRpdj5EYXZpZC48YnI+PC9kaXY+PGRpdiBkYXRhLXNpZ25h
dHVyZWJsb2NrPSJ0cnVlIj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj4KPC9ib2R5Pgo8L2h0
bWw+Cg==

--_B456DDEF-183B-4AFF-A736-C9F9D25ED93B_--


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