\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, 4 Jul 2015 10:13:18 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Directions

I've been spending a lot of time working on Field Programmable Gate
Arrays (FPGAs) which is basically hardware that can be reprogrammed.

There have been some interesting developments in this area. 

First, FPGAs are a lot more powerful and much cheaper.

Second, Intel just bought the second largest FPGA company, Altera.
http://www.cnbc.com/id/102723697

Third, FPGAs are moving toward computational mathematics.
https://github.com/Gladdy/numerical-fpga-thesis

I believe, though I don't know for sure, that Intel will eventually
put an FPGA fabric on the same chip (Sytem on a Chip, SoC) as their
CPUs.

Axiom is in a unique position to exploit this kind of hardware merger. 
If anyone has pointers to work on hardware-based symbolic/numeric
work, please send me a link.

Tim

\start
Date: Sat, 04 Jul 2015 11:33:58 -0400
From: "William Sit" <wyscc@sci.ccny.cuny.edu>
To: daly@axiom-developer.org,axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Directions

Dear Tim:

I don't have pointers applying FPGA techniques to symbolic 
computations. However, the trend is to use something 
similar to FPGA all the way down to the manufacture level. 
For some background, see 
http://www.rambus.com/technology/item/979-rambus-cryptography-research-division-unveils-cryptomanager-secure-feature-management-platform.
Qualcomm, for example already licenses this technology, as 
do many other companies. Their idea is to tailor each 
individual chip at the single consumer level to enhance 
security.

By the way, the link
https://github.com/Gladdy/numerical-fpga-thesis/blob/master/thesis/thesis.pdf
is not readable by Adobe or Preview on Macs.

However, according to your link (scroll down to bottom), 
the abstract mentions:
" This thesis describes the process of implementing an 
accelerator in which the computational part is specified 
using the functional hardware description language CλaSH 
and discusses the feasibility of performing numerical 
mathematics on this accelerator by computing 
approximations to ordinary differential equations. The 
accelerator is capable of using the methods of Euler and 
Runge-Kutta (second order) to perform the approximations, 
but due to the use of a fixed-point number representation 
the accuracy suffers."

So this is mainly a numerical set up. Graphics processors 
have been used for numerical scientific work for a long 
time already since GPUs have improved tremendously in 
power (my layman observation is the advance is faster than 
CPUs in terms of number of cores, speed, and low power 
consumption).

Since Axiom is software, I am not sure how the technique 
may be applied, unless you are thinking about an Axiom 
chip, or some hybrid numerical-symbolic approach is used. 
However, Axiom is a relatively small system (compared to 
modern mammoth bloated software), and I think the priority 
should be to make Axiom's learning curve less steep than 
make Axiom run faster, or even more securely.

William

On Sat, 4 Jul 2015 10:13:18 -0500
  daly@axiom-developer.org wrote:
> I've been spending a lot of time working on Field 
>Programmable Gate
> Arrays (FPGAs) which is basically hardware that can be 
>reprogrammed.
> 
> There have been some interesting developments in this 
>area. 
> 
>First, FPGAs are a lot more powerful and much cheaper.
> 
> Second, Intel just bought the second largest FPGA 
>company, Altera.
> http://www.cnbc.com/id/102723697
> 
> Third, FPGAs are moving toward computational 
>mathematics.
> https://github.com/Gladdy/numerical-fpga-thesis
> 
> I believe, though I don't know for sure, that Intel will 
>eventually
> put an FPGA fabric on the same chip (Sytem on a Chip, 
>SoC) as their
> CPUs.
> 
> Axiom is in a unique position to exploit this kind of 
>hardware merger. 
> If anyone has pointers to work on hardware-based 
>symbolic/numeric
> work, please send me a link.
> 
> Tim

\start
Date: Sat, 4 Jul 2015 11:47:01 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] directions

>I don't have pointers applying FPGA techniques to symbolic 
>computations. However, the trend is to use something 
>similar to FPGA all the way down to the manufacture level. 
>For some background, see 
>http://www.rambus.com/technology/item/979-rambus-cryptography-research-division-unveils-cryptomanager-secure-feature-management-platform.
>Qualcomm, for example already licenses this technology, as 
>do many other companies. Their idea is to tailor each 
>individual chip at the single consumer level to enhance 
>security.

I'm actually working with FPGAs to do hardware security with some
people at CMU.

>By the way, the link
>https://github.com/Gladdy/numerical-fpga-thesis/blob/master/thesis/thesis.pdf
>is not readable by Adobe or Preview on Macs.

I cloned the repo and can read the thesis.pdf file.

>So this is mainly a numerical set up. Graphics processors 
>have been used for numerical scientific work for a long 
>time already since GPUs have improved tremendously in 
>power (my layman observation is the advance is faster than 
>CPUs in terms of number of cores, speed, and low power 
>consumption).

>Since Axiom is software, I am not sure how the technique 
>may be applied, unless you are thinking about an Axiom 
>chip, or some hybrid numerical-symbolic approach is used. 
>However, Axiom is a relatively small system (compared to 
>modern mammoth bloated software), 

The speculation is that Intel will merge the Altera FPGA fabric
into the CPU. This already exists on my FGPA board (dual hardware
CPUs, dual firmware CPUs, and a large FPGA fabric in one chip).

Think of this as a "programmable ALU" where you can temporarily
(or permanently) run an ALU to do computational mathematics. At
the moment this undergrad thesis shows that one can do a lot of
ODE (exponential, simple harmonic, cosine hyperbolic, simple
forcd harmonic) numerical computation.

The extrapolation would be to do a symbolic computation, compile
the result to the "FPGA ALU", and do blindingly fast evaluations.

I'm already pushing forward on the BLAS work (bookvol10.5). 
Given a programmable "FPGA ALU", this could really change the game.

>                                  and I think the priority 
>should be to make Axiom's learning curve less steep than 
>make Axiom run faster, or even more securely.

I'm still pushing forward on "making the learning curve less steep".

I have been collecting permissions from authors to use their work as
part of the books, the most recent being work on Clifford Algebra.
I'm trying to collect permissions for each of the domains.  These will
be used to introduce domains in a book-like readable treatment of the
Spad code so people can understand the algorithms while reading the
code. I have material to write, a document structure that will
organize it, and the permission to use it. It just takes time.

I'm also pulling yet more of the code into the books, eliminating dead
code, providing signatures for the lisp code, organizing the code into
chapters and sections, documenting the data structures, developing
help, )display examples, and input files for domains, and working on
both an enlarged computer algebra test suite and program proof
technology. It just takes time.

The incremental changes are hard to spot until there is a major
completion point. These have happened (e.g. replace noweb with
straight latex, remove boot and aldor, continuous integration with
docker, restructure the algebra, a new browser front end, additional
algebra, merged lisp code, enlarged test suite, etc.) It just takes time.

Eventually Axiom will be a system can be maintained, modified,
extended, and taught by people who are not the original authors
or one of the three gurus. It just takes time.

Fortunately Axiom has a 30 year horizon.

Tim

\start
Date: Tue, 7 Jul 2015 20:17:15 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] How to prove large software projects correct

One long term Axiom goal is proving Axiom implementation of algorithms
correct. After all, this is computational MATHEMATICS. The state of the
art involves writing code but ignores the formal aspects. This is not
acceptable for the long term. When Axiom gives an answer there needs to
be some assurance that the answer is formally correct.

I'm climbing the learning curve for program proofs, trying to find
a good way to handle something as complex as Axiom. There are three
interlocking approaches, one for the algebra, one for the lisp code,
and one for the machine level code.

At the moment I'm spending most of my time at the lisp level. I've
created a \sig macro so that the function signatures can be written
out in haskell-like syntax.

Gabriel Gonzalez gave an interesting talk, bridging the gap between
programming and equational reasoning for program proofs.

How to prove large software projects correct
http://www.techcast.com/events/bigtechday8/maffei-1450/?q=maffei-1450

Using this approach requires some bottom-up construction of monoid
behavior. I've marked "primitive" functions, that is, functions which
are implemented using only common lisp function calls. These will be
the early functions with signature maps. Once the signatures exist the
code need to be refactored to have equational semantics. Once that is
done each use has to be examined and refactored, recursively.

This gives hope that we can create some equational proofs. This
becomes more interesting when we look at lisp primitives used by the
algebra. Refactoring the algebra's use of lisp into a single package
would give Axiom-level semantics with proven code.  Equational
semantics for lisp-based algebra primitives will fit well in COQ, the
tool that seems most likely to handle the algebra level.

It looks like the pieces are slowly falling into place.

SO much more to learn though...

Tim

\start
Date: Fri, 10 Jul 2015 15:07:37 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Literate programming

This quote by Bill Thurston[1] makes it clear why we need to document
the algorithms in Axiom (emphasis mine):

  Mathematical understanding does not expand in a monotone direction.
  Our understanding frequently deteriorates as well. There are several
  obvious mechanisms of decay. THE EXPERTS IN A SUBJECT RETIRE AND DIE,
  OR SIMPLY MOVE ON TO OTHER SUBJECTS AND FORGET. Mathematics is
  commonly explained and recorded in symbolic and concrete forms that
  are easy to communicate, rather than in conceptual forms that are easy
  to understand once communicated. Translation in the direction
  conceptual -> concrete and symbolic is much easier than translation in
  the reverse direction, and symbolic forms often replaces the
  conceptual forms of understanding. And mathematical conventions and
  taken-for-granted knowledge change, so older texts may become hard to
  understand. In short, mathematics only exists in a living community of
  mathematicians that spreads understanding and breaths life into ideas
  both old and new.

The people who wrote the vast bulk of Axiom's algorithms have either
retired or died. They no longer maintain the code. We really must
collect the papers and document the algorithms. This is especially
critical going forward as open source projects tend to fall out of
interest when real life makes it inconvenient to maintain code.

Tim

[1] http://blog.computationalcomplexity.org/2015/07/will-our-understanding-of-math.html

\start
Date: Fri, 10 Jul 2015 18:29:50 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org, "William Sit" <wyscc@sci.ccny.cuny.edu>
Subject: Re: [Axiom-developer] Literate programming

William,

Back in the day I struggled to cross the great chasm, moving from
real programming to "structured programming", i.e. not using GOTOs.

Dijkstra was asking me to change a fundamental part of my thinking,
to throw away the focus on the machine's BRANCH instruction, albeit
in my high-level FORTRAN programs. I was going to lose my precious
computed GOTOs. Even my Lisp programs had gotos. I was writing
assembler "at a higher level", being efficient; saving time; using
"best practices".

I crossed that chasm by forcing myself read what Dijkstra wrote and
forcing myself to write in the new sytle. It was painful, pointless,
and unnatural but eventually I understood. The GOTO statement,
especially my precious computed-goto, made programs hard to understand,
maintain, and modify.  I haven't written a GOTO statement in years.

Literate programming is painful, pointless, and unnatural. We're being
efficient; saving time; using "best practices"! Hierarchies of tiny
files built with MAKE and without annoying comments are best practices! 
If you want to understand the theory just read the code! Understanding, 
maintaining, and modifying raw code is for real programmers. If you 
can't do that... go away.

Knuth is trying to take away my precious hacker badge. He wants me to
write natural language to communicate ideas to other humans. What a
worthless waste of my time. 

There is no argument I can make that will convince anyone that
literate programming is worthwhile. Like lisp programming, literate
programming is an "Aha!" epiphany event. You don't "get it" until you
"get it", or as the dictionary says it is "an illuminating discovery,
realization, or disclosure". 

The only way to cross the chasm is to use the new tool. 
Once you "get it" you'll never go back.

Axiom is about ideas, not code. It is a way of structuring
computational mathematics. It is not just a tool to get an answer, it
is a tool to get the right answer. Using the tool properly implies you
understand the tool, its uses, and its limitations. Enhancing the tool
implies you understand the model and its assumptions. All of that
means that we have to communicate to people as well as machines.

Literate programming is a vehicle to communicate to both.

Tim

\start
Date: Fri, 10 Jul 2015 19:19:19 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom correct

There is a free book "Certified Programming with Dependent Types"
about COQ available at:
http://adam.chlipala.net/cpdt/cpdt.pdf

Tim

\start
Date: Fri, 10 Jul 2015 19:54:54 -0500
From: daly@axiom-developer.org
To: thery@sophia.inria.fr, Laurent.Thery@inria.fr
Subject: [Axiom-developer] Machine Checked Implementation of BuchBerger's
	Algorithm

I'm Tim Daly, lead developer on the Axiom computer algebra system.

I'm sorry if this is not to the correct person.

I'm looking to contact Laurent Thery about the files for the
implementation and proof of Buchberger's Algorithm. There is a
link in the paper to http://www.inria.fr/lemme/buch but it is dead.

Is there somewhere I can reach the sources? I'd like to reproduce
the work to understand it better.

Tim Daly

\start
Date: Fri, 10 Jul 2015 20:16:32 -0500
From: daly@axiom-developer.org
To: immaculada.medina@uca.es, rancisco.palomo@uca.es, jalonso@us.es,
	jruiz@us.es
Subject: [Axiom-developer] Verified Computer Algebra in ACL2

I'm Tim Daly, Lead developer on the Axiom computer algebra system.

I'm reading the paper "Verified Computer Algebra in ACL2".
Is the code available somewhere? I'd like to reproduce the result
and understand the details.

Tim Daly

\start
Date: Sun, 12 Jul 2015 15:01:39 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] COQ and Axiom

Axiom has a project goal of Proving Axiom Correct. This is
computational mathematics. It needs a solid foundation.

There are limits to what can be proven, of course, but the power
of the proof systems has really improved since Axiom was born.

Of the half-dozen or more proof systems and it appears that COQ 
is closest to Spad in spirit. COQ has the ability to handle dependent
types (e.g. specifying that an array has a fixed known length). COQ
has the ability to generate OCAML programs from proofs. This will
make it easy to compare with the Spad implementations. A major win
in the long term would be to auto-generate the Spad code but that's
a distant dream at the moment.

Axiom is being attacked from two directions. The first is from the
"categories down", trying to specify Axiom's category signatures in
COQ. The second is from the "bits up", trying to specify the lisp
functions that are implemented using only common lisp primitives.
These are marked in the interpreter already and will soon have
OCAML-like type signatures.

If anyone knows of prior work on either path, please let me know.

We have already gotten permission from Laurant Thery to use his work
on the proof of Buchberger's algorithm, some of which will show up
in Volume 13. I have to reverse-engineer his proof into the Spad
implementation.

Tim

\start
Date: Wed, 15 Jul 2015 15:12:57 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom Correct

The latest update contains the first proof of Axiom's Common Lisp
code using ACL2. ACL2 is a common lisp that has proof technology
and since Axiom is all common lisp (no boot code), this is a good
basis for proofs.

This update proves that the predicate isWrapped takes anything as
an argument and returns either t or nil. One caveat is that ACL2
does not handle floating point so (floatp x) is omitted but this
is fine for now. The signature line is 

   isWrapped: t -> (or t nil)

The plan of attack is to prove functions which use only common lisp
primitives in their implementation first and then work upward through
functions that use only the proven set. The base level functions are
already marked in the interpreter.

In the longer term ACL2 will be integrated into the build process so
each release has an ever-growing proven subset.

This is the first step in a very large task.

Tim

\start
Date: Wed, 15 Jul 2015 21:47:37 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom Correct

The system build has now been updated to automatically extract
and prove any acl2 stanzas. This behavior is activated by including
ACL2=acl2 on the make command line. This will, of course, only work
if you have acl2 installed.

This automation will make sure the proofs occur at build time
in order to catch failures. Currently, failing tests will not 
stop the build. The plan is to report failures after the build
just as we do with the regression test suite.

Tim

\start
Date: Thu, 16 Jul 2015 01:03:06 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom Correct

COQ is being used as the proof engine for Spad-level code.

The latest change will automatically extract literate chunks
labelled 'coq' into a separate location for the COQ proof engine.
This can be controlled from the make command line by adding COQ=coq.

ACL2, with its lisp-based syntax and semantics, is the appropriate
engine for proving the interpreter and compiler. COQ, with its
ability to form dependent types, is the appropriate engine for
proving the algebra. Thus we're able to use the best tool for
each level of abstraction.

Tim

\start
Date: Sun, 19 Jul 2015 02:49:39 +0200
From: Kurt Pagani <kp@scios.ch>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Proving Axiom Correct

Hi Tim

that's great, indeed. Coq also seems to me best suited for this
challenging task, however, I would suggest to use "the mathematical
proof language (MPL)" as described in chapeter 11 of the reference
manual. It's a matter of taste, of courese, but imho MPL is much more
readable (at least to mathematicians) I guess.

The following primitive example (standard vs. mpl) might be convincing.

Standard proof language:
------------------------

Section Group.
Parameter S : Set.
Parameter e : S.
Parameter inv : S -> S.
Parameter op: S -> S -> S.
Infix "*" := op.

Axiom left_id : forall x:S, e * x = x.
Axiom left_inv : forall x:S, inv x * x = e.
Axiom assoc : forall x y z:S, x * (y * z) = (x * y) * z.

Proposition left_cancel :
   forall x y z:S, x * y = x * z -> y = z.
Proof.
intros.
assert (inv x * (x * y) = inv x * (x * z)) as H1.
   rewrite H.
   reflexivity.
rewrite assoc in H1.
rewrite assoc in H1.
rewrite left_inv in H1.
rewrite left_id in H1.
rewrite left_id in H1.
assumption.
Qed.

Proposition right_id :
   forall x:S, x * e = x.
Proof.
intros.
apply left_cancel with (x:=inv x).
rewrite assoc.
rewrite left_inv.
apply left_id.
Qed.


the same in MPL:
----------------

Section Group.
Parameter S : Set.
Parameter e : S.
Parameter inv : S -> S.
Parameter op: S -> S -> S.
Infix "*" := op.

Axiom left_id : forall x:S, e * x = x.
Axiom left_inv : forall x:S, inv x * x = e.
Axiom assoc : forall x y z:S, x * (y * z) = (x * y) * z.

Proposition left_cancel :
   forall x y z:S, x * y = x * z -> y = z.
proof.
let x:S, y:S, z:S.
assume (x*y=x*z).
then (inv x *(x*y) = inv x * (x*z)).
then ((inv x * x)*y=(inv x* x)*z) by assoc.
then (e*y=e*z) by left_inv.
then (y=z) by left_id.
take _fact0.
end proof.
Qed.

Proposition right_id :
   forall x:S, x * e = x.
proof.
let x:S.
then  (e*e=e) by left_id.
then ((inv x * x)*e=inv x * x) by left_inv.
then (inv x*(x*e)= inv x * x) by assoc.
hence (x*e=x) by left_cancel.
end proof.
Qed.

Well, it's a quick hack, however, it contains almost every principle to
prove the 'algebra' correct.

Kurt


Am 16.07.2015 um 08:03 schrieb daly@axiom-developer.org:
> COQ is being used as the proof engine for Spad-level code.
> 
> The latest change will automatically extract literate chunks
> labelled 'coq' into a separate location for the COQ proof engine.
> This can be controlled from the make command line by adding COQ=coq.
> 
> ACL2, with its lisp-based syntax and semantics, is the appropriate
> engine for proving the interpreter and compiler. COQ, with its
> ability to form dependent types, is the appropriate engine for
> proving the algebra. Thus we're able to use the best tool for
> each level of abstraction.
> 
> Tim
> 

\start
Date: Sat, 18 Jul 2015 20:00:24 -0500
From: daly@axiom-developer.org
To: Kurt Pagani <kp@scios.ch>, axiom-developer@nongnu.org
Subject: [Axiom-developer] MPL declarative style proofs

Very nice. 

I will try to use it as a first example. I've been concentrating
on the ACL2 level at the moment but I just changed Axiom to use
COQ on extracted proofs. Since this works from coqtop it looks like
I can use it for checking during the build.

Thanks for the reference.

Tim

\start
Date: Sat, 25 Jul 2015 06:38:02 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Call for help

Axiom has moved into a new phase. The goal is to prove Axiom correct.

There are several tools and several levels of proof. I've added
the machinery to run proofs in COQ (for algebra) and ACL2 (for
the interpreter and compiler).

One of the first steps for the algebra proofs involves decorating
the categories with their mathematical axioms. That's where I am
asking for your help.

There are 241 categories, such as Monoid, which need to be annotated.
I've listed them below, sorted in the order by which they inherit
from prior categories, so that the complexity increases. The file
http://axiom-developer.org/axiom-website/endpaper.pdf
has a graph of the categories from the Jenks book which could be
a great help.

Please look at the categories and find or create the axioms.
If you have a particularly good reference page on the web or
a particularly good book that lists them, please let me know.

The axioms have to be in a certain form so they can be used in
the calculus of inductive constructions (the theory behind COQ).

The plan is to decorate the categories, then provide proofs for
category-default code. Unfortunately, Axiom is circular so some
of the domains are going to require proofs also. 

This task should be at least as hard as it was to get Axiom to
build stand-alone in the first place which took about a year.
The best case will be that the implementations are proven correct.
The bad case will be corner cases where the implementation cannot
be proven.

In any case, your help will make this first step easier. Drag out
your favorite reference book and decorate LeftModule :-).

Thanks,
Tim

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

ATADDVA AdditiveValuationAttribute
ATAPPRO ApproximateAttribute
ATARBEX ArbitraryExponentAttribute
ATARBPR ArbitraryPrecisionAttribute
AHYP    ArcHyperbolicFunctionCategory
ATRIG   ArcTrigonometricFunctionCategory
ATTREG  AttributeRegistry
BASTYPE BasicType
ATCANON CanonicalAttribute
ATCANCL CanonicalClosedAttribute
ATCUNOR CanonicalUnitNormalAttribute
ATCENRL CentralAttribute
KOERCE  CoercibleTo
CFCAT   CombinatorialFunctionCategory
ATCS    CommutativeStarAttribute
KONVERT ConvertibleTo
ELEMFUN ElementaryFunctionCategory
ELTAB   Eltable
ATFINAG FiniteAggregateAttribute
HYPCAT  HyperbolicFunctionCategory
IEVALAB InnerEvalable
ATJACID JacobiIdentityAttribute
ATLR    LazyRepresentationAttribute
ATLUNIT LeftUnitaryAttribute
MAGCDOC ModularAlgebraicGcdOperations
ATMULVA MultiplicativeValuationAttribute
ATNOTHR NotherianAttribute
ATNZDIV NoZeroDivisorsAttribute
ATNULSQ NullSquareAttribute
OM      OpenMath
ATPOSET PartiallyOrderedSetAttribute
PTRANFN PartialTranscendentalFunctions
PATAB   Patternable
PRIMCAT PrimitiveFunctionCategory
RADCAT  RadicalCategory
RETRACT RetractableTo
ATRUNIT RightUnitaryAttribute
ATSHMUT ShallowlyMutableAttribute
SPFCAT  SpecialFunctionCategory
TRIGCAT TrigonometricFunctionCategory
TYPE    Type
ATUNIKN UnitsKnownAttribute
AGG     Aggregate
COMBOPC CombinatorialOpsCategory
COMPAR  Comparable
ELTAGG  EltableAggregate
EVALAB  Evalable
FORTCAT FortranProgramCategory
FRETRCT FullyRetractableTo
FPATMAB FullyPatternMatchable
LOGIC   Logic
PPCURVE PlottablePlaneCurveCategory
PSCURVE PlottableSpaceCurveCategory
REAL    RealConstant
SEGCAT  SegmentCategory
SETCAT  SetCategory
TRANFUN TranscendentalFunctionCategory
ABELSG  AbelianSemiGroup
BLMETCT BlowUpMethodCategory
DSTRCAT DesingTreeCategory
FORTFN  FortranFunctionCategory
FMC     FortranMatrixCategory
FMFUN   FortranMatrixFunctionCategory
FVC     FortranVectorCategory
FVFUN   FortranVectorFunctionCategory
FEVALAB FullyEvalableOver
FILECAT FileCategory
FINITE  Finite
FNCAT   FileNameCategory
GRMOD   GradedModule
LORER   LeftOreRing
HOAGG   HomogeneousAggregate
IDPC    IndexedDirectProductCategory
LFCAT   LiouvillianFunctionCategory
MONAD   Monad
NUMINT  NumericalIntegrationCategory
OPTCAT  NumericalOptimizationCategory
ODECAT  OrdinaryDifferentialEquationsSolverCategory
ORDSET  OrderedSet
PDECAT  PartialDifferentialEquationsSolverCategory
PATMAB  PatternMatchable
RRCC    RealRootCharacterizationCategory
SEGXCAT SegmentExpansionCategory
SGROUP  SemiGroup
SETCATD SetCategoryWithDegree
SEXCAT  SExpressionCategory
STEP    StepThrough
SPACEC  ThreeSpaceCategory
ABELMON AbelianMonoid
AFSPCAT AffineSpaceCategory
BGAGG   BagAggregate
CACHSET CachableSet
CLAGG   Collection
DVARCAT DifferentialVariableCategory
ES      ExpressionSpace
GRALG   GradedAlgebra
IXAGG   IndexedAggregate
MONADWU MonadWithUnit
MONOID  Monoid
ORDFIN  OrderedFinite
PLACESC PlacesCategory
PRSPCAT ProjectiveSpaceCategory
RCAGG   RecursiveAggregate
ARR2CAT TwoDimensionalArrayCategory
BRAGG   BinaryRecursiveAggregate
CABMON  CancellationAbelianMonoid
DIOPS   DictionaryOperations
DLAGG   DoublyLinkedAggregate
GROUP   Group
LNAGG   LinearAggregate
MATCAT  MatrixCategory
OASGP   OrderedAbelianSemiGroup
ORDMON  OrderedMonoid
PSETCAT PolynomialSetCategory
PRQAGG  PriorityQueueAggregate
QUAGG   QueueAggregate
SETAGG  SetAggregate
SKAGG   StackAggregate
URAGG   UnaryRecursiveAggregate
ABELGRP AbelianGroup
BTCAT   BinaryTreeCategory
DIAGG   Dictionary
DQAGG   DequeueAggregate
ELAGG   ExtensibleLinearAggregate
FLAGG   FiniteLinearAggregate
FAMONC  FreeAbelianMonoidCategory
MDAGG   MultiDictionary
OAMON   OrderedAbelianMonoid
PERMCAT PermutationCategory
STAGG   StreamAggregate
TSETCAT TriangularSetCategory
FDIVCAT FiniteDivisorCategory
FSAGG   FiniteSetAggregate
KDAGG   KeyedDictionary
LZSTAGG LazyStreamAggregate
LMODULE LeftModule
LSAGG   ListAggregate
MSETAGG MultisetAggregate
NARNG   NonAssociativeRng
A1AGG   OneDimensionalArrayAggregate
OCAMON  OrderedCancellationAbelianMonoid
RSETCAT RegularTriangularSetCategory
RMODULE RightModule
RNG     Rng
BMODULE BiModule
BTAGG   BitAggregate
NASRING NonAssociativeRing
NTSCAT  NormalizedTriangularSetCategory
OAGROUP OrderedAbelianGroup
OAMONS  OrderedAbelianMonoidSup
OMSAGG  OrderedMultisetAggregate
RING    Ring
SFRTCAT SquareFreeRegularTriangularSetCategory
SRAGG   StringAggregate
TBAGG   TableAggregate
VECTCAT VectorCategory
ALAGG   AssociationListAggregate
CHARNZ  CharacteristicNonZero
CHARZ   CharacteristicZero
COMRING CommutativeRing
DIFRING DifferentialRing
ENTIRER EntireRing
FMCAT   FreeModuleCat
LALG    LeftAlgebra
LINEXP  LinearlyExplicitRingOver
MODULE  Module
ORDRING OrderedRing
PDRING  PartialDifferentialRing
PTCAT   PointCategory
RMATCAT RectangularMatrixCategory
SNTSCAT SquareFreeNormalizedTriangularSetCategory
STRICAT StringCategory
OREPCAT UnivariateSkewPolynomialCategory
XALG    XAlgebra
ALGEBRA Algebra
DIFEXT  DifferentialExtension
FLINEXP FullyLinearlyExplicitRingOver
LIECAT  LieAlgebra
LODOCAT LinearOrdinaryDifferentialOperatorCategory
NAALG   NonAssociativeAlgebra
VSPACE  VectorSpace
XFALG   XFreeAlgebra
DIRPCAT DirectProductCategory
DIVRING DivisionRing
FINAALG FiniteRankNonAssociativeAlgebra
FLALG   FreeLieAlgebra
INTDOM  IntegralDomain
MLO     MonogenicLinearOperator
OC      OctonionCategory
QUATCAT QuaternionCategory
SMATCAT SquareMatrixCategory
XPOLYC  XPolynomialsCat
AMR     AbelianMonoidRing
FMTC    FortranMachineTypeCategory
FRNAALG FramedNonAssociativeAlgebra
GCDDOM  GcdDomain
OINTDOM OrderedIntegralDomain
FAMR    FiniteAbelianMonoidRing
INTCAT  IntervalCategory
PSCAT   PowerSeriesCategory
PID     PrincipalIdealDomain
UFD     UniqueFactorizationDomain
DIVCAT  DivisorCategory
EUCDOM  EuclideanDomain
MTSCAT  MultivariateTaylorSeriesCategory
PFECAT  PolynomialFactorizationExplicit
UPSCAT  UnivariatePowerSeriesCategory
FIELD   Field
INS     IntegerNumberSystem
LOCPOWC LocalPowerSeriesCategory
PADICCT PAdicIntegerCategory
POLYCAT PolynomialCategory
UTSCAT  UnivariateTaylorSeriesCategory
ACF     AlgebraicallyClosedField
DPOLCAT DifferentialPolynomialCategory
FPC     FieldOfPrimeCharacteristic
FINRALG FiniteRankAlgebra
FS      FunctionSpace
INFCLCT InfinitlyClosePointCategory
PACPERC PseudoAlgebraicClosureOfPerfectFieldCategory
QFCAT   QuotientFieldCategory
RCFIELD RealClosedField
RNS     RealNumberSystem
RPOLCAT RecursivePolynomialCategory
ULSCAT  UnivariateLaurentSeriesCategory
UPXSCAT UnivariatePuiseuxSeriesCategory
UPOLYC  UnivariatePolynomialCategory
ACFS    AlgebraicallyClosedFunctionSpace
XF      ExtensionField
FFIELDC FiniteFieldCategory
FPS     FloatingPointSystem
FRAMALG FramedAlgebra
PACFFC  PseudoAlgebraicClosureOfFiniteFieldCategory
ULSCCAT UnivariateLaurentSeriesConstructorCategory
UPXSCCA UnivariatePuiseuxSeriesConstructorCategory
FAXF    FiniteAlgebraicExtensionField
MONOGEN MonogenicAlgebra
PACRATC PseudoAlgebraicClosureOfRationalNumberCategory
COMPCAT ComplexCategory
FFCAT   FunctionFieldCategory
PACEXTC PseudoAlgebraicClosureOfAlgExtOfRationalNumberCategory

\start
Date: Sat, 25 Jul 2015 10:55:45 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

You will have to excuse me if I dozed off in the back seat during the trip.
Is this where we are?
We have a programming language (say SPAD or lisp) and a program in that 
language represented by a series of statements.
The intent is to construct, in a literate manner, a series of statements 
in MPL and SPAD that are flagged and readable by the respective 
compilers such that if the MPL statements are logically correct 
(assertions match conclusions) then SPAD will also reach the same 
conclusions as you stated in MPL.  Presumably that is also done by  MPL 
via a dictionary or some such.
For instance in Left Module Construction the assertions are equivalent 
to a triple F: (R(\cdot , +),G(+),RxG->G(+) and the base qualification is:
R is a ring
G is a group
RxG is legitimate map from R,G to G
etc...
And fail (hopefully informatively) if one of these fails
or Return a construct that has all of the functional properties of Left 
Modules.

Now the literate program has a "model" of Left Module in MPL and then 
checks the SPAD code to see if it correctly does all the of the above 
checks.  If you have done all that then it seems to me that there should 
also be a "hook" that check my custom code as well; of course that 
should be optional and only done when required.  And requires that I can 
define my expectations for my code (which unfortunately I sometimes can't).

Forgive any ignorance but I left off back in the 80's with a Sandia (I 
think) formalism to check the correctness of code.  That is: make 
assertions about what the code will do with the input and verify that 
the code does that.  To give credit this was supposed to be done by 
first order predicate expressions that can be verified.

I would appreciate constructive corrections and suggestions.
Ray


On 07/25/2015 07:38 AM, daly@axiom-developer.org wrote:
> Axiom has moved into a new phase. The goal is to prove Axiom correct.
>
> There are several tools and several levels of proof. I've added
> the machinery to run proofs in COQ (for algebra) and ACL2 (for
> the interpreter and compiler).
>
> One of the first steps for the algebra proofs involves decorating
> the categories with their mathematical axioms. That's where I am
> asking for your help.
>
> There are 241 categories, such as Monoid, which need to be annotated.
> I've listed them below, sorted in the order by which they inherit
> from prior categories, so that the complexity increases. The file
> http://axiom-developer.org/axiom-website/endpaper.pdf
> has a graph of the categories from the Jenks book which could be
> a great help.
>
> Please look at the categories and find or create the axioms.
> If you have a particularly good reference page on the web or
> a particularly good book that lists them, please let me know.
>
> The axioms have to be in a certain form so they can be used in
> the calculus of inductive constructions (the theory behind COQ).
>
> The plan is to decorate the categories, then provide proofs for
> category-default code. Unfortunately, Axiom is circular so some
> of the domains are going to require proofs also.
>
> This task should be at least as hard as it was to get Axiom to
> build stand-alone in the first place which took about a year.
> The best case will be that the implementations are proven correct.
> The bad case will be corner cases where the implementation cannot
> be proven.
>
> In any case, your help will make this first step easier. Drag out
> your favorite reference book and decorate LeftModule :-).
>
> Thanks,
> Tim
>
> ==================================================================
>
> ATADDVA AdditiveValuationAttribute
> ATAPPRO ApproximateAttribute
> ATARBEX ArbitraryExponentAttribute
> ATARBPR ArbitraryPrecisionAttribute
> AHYP    ArcHyperbolicFunctionCategory
> ATRIG   ArcTrigonometricFunctionCategory
> ATTREG  AttributeRegistry
> BASTYPE BasicType
> ATCANON CanonicalAttribute
> ATCANCL CanonicalClosedAttribute
> ATCUNOR CanonicalUnitNormalAttribute
> ATCENRL CentralAttribute
> KOERCE  CoercibleTo
> CFCAT   CombinatorialFunctionCategory
> ATCS    CommutativeStarAttribute
> KONVERT ConvertibleTo
> ELEMFUN ElementaryFunctionCategory
> ELTAB   Eltable
> ATFINAG FiniteAggregateAttribute
> HYPCAT  HyperbolicFunctionCategory
> IEVALAB InnerEvalable
> ATJACID JacobiIdentityAttribute
> ATLR    LazyRepresentationAttribute
> ATLUNIT LeftUnitaryAttribute
> MAGCDOC ModularAlgebraicGcdOperations
> ATMULVA MultiplicativeValuationAttribute
> ATNOTHR NotherianAttribute
> ATNZDIV NoZeroDivisorsAttribute
> ATNULSQ NullSquareAttribute
> OM      OpenMath
> ATPOSET PartiallyOrderedSetAttribute
> PTRANFN PartialTranscendentalFunctions
> PATAB   Patternable
> PRIMCAT PrimitiveFunctionCategory
> RADCAT  RadicalCategory
> RETRACT RetractableTo
> ATRUNIT RightUnitaryAttribute
> ATSHMUT ShallowlyMutableAttribute
> SPFCAT  SpecialFunctionCategory
> TRIGCAT TrigonometricFunctionCategory
> TYPE    Type
> ATUNIKN UnitsKnownAttribute
> AGG     Aggregate
> COMBOPC CombinatorialOpsCategory
> COMPAR  Comparable
> ELTAGG  EltableAggregate
> EVALAB  Evalable
> FORTCAT FortranProgramCategory
> FRETRCT FullyRetractableTo
> FPATMAB FullyPatternMatchable
> LOGIC   Logic
> PPCURVE PlottablePlaneCurveCategory
> PSCURVE PlottableSpaceCurveCategory
> REAL    RealConstant
> SEGCAT  SegmentCategory
> SETCAT  SetCategory
> TRANFUN TranscendentalFunctionCategory
> ABELSG  AbelianSemiGroup
> BLMETCT BlowUpMethodCategory
> DSTRCAT DesingTreeCategory
> FORTFN  FortranFunctionCategory
> FMC     FortranMatrixCategory
> FMFUN   FortranMatrixFunctionCategory
> FVC     FortranVectorCategory
> FVFUN   FortranVectorFunctionCategory
> FEVALAB FullyEvalableOver
> FILECAT FileCategory
> FINITE  Finite
> FNCAT   FileNameCategory
> GRMOD   GradedModule
> LORER   LeftOreRing
> HOAGG   HomogeneousAggregate
> IDPC    IndexedDirectProductCategory
> LFCAT   LiouvillianFunctionCategory
> MONAD   Monad
> NUMINT  NumericalIntegrationCategory
> OPTCAT  NumericalOptimizationCategory
> ODECAT  OrdinaryDifferentialEquationsSolverCategory
> ORDSET  OrderedSet
> PDECAT  PartialDifferentialEquationsSolverCategory
> PATMAB  PatternMatchable
> RRCC    RealRootCharacterizationCategory
> SEGXCAT SegmentExpansionCategory
> SGROUP  SemiGroup
> SETCATD SetCategoryWithDegree
> SEXCAT  SExpressionCategory
> STEP    StepThrough
> SPACEC  ThreeSpaceCategory
> ABELMON AbelianMonoid
> AFSPCAT AffineSpaceCategory
> BGAGG   BagAggregate
> CACHSET CachableSet
> CLAGG   Collection
> DVARCAT DifferentialVariableCategory
> ES      ExpressionSpace
> GRALG   GradedAlgebra
> IXAGG   IndexedAggregate
> MONADWU MonadWithUnit
> MONOID  Monoid
> ORDFIN  OrderedFinite
> PLACESC PlacesCategory
> PRSPCAT ProjectiveSpaceCategory
> RCAGG   RecursiveAggregate
> ARR2CAT TwoDimensionalArrayCategory
> BRAGG   BinaryRecursiveAggregate
> CABMON  CancellationAbelianMonoid
> DIOPS   DictionaryOperations
> DLAGG   DoublyLinkedAggregate
> GROUP   Group
> LNAGG   LinearAggregate
> MATCAT  MatrixCategory
> OASGP   OrderedAbelianSemiGroup
> ORDMON  OrderedMonoid
> PSETCAT PolynomialSetCategory
> PRQAGG  PriorityQueueAggregate
> QUAGG   QueueAggregate
> SETAGG  SetAggregate
> SKAGG   StackAggregate
> URAGG   UnaryRecursiveAggregate
> ABELGRP AbelianGroup
> BTCAT   BinaryTreeCategory
> DIAGG   Dictionary
> DQAGG   DequeueAggregate
> ELAGG   ExtensibleLinearAggregate
> FLAGG   FiniteLinearAggregate
> FAMONC  FreeAbelianMonoidCategory
> MDAGG   MultiDictionary
> OAMON   OrderedAbelianMonoid
> PERMCAT PermutationCategory
> STAGG   StreamAggregate
> TSETCAT TriangularSetCategory
> FDIVCAT FiniteDivisorCategory
> FSAGG   FiniteSetAggregate
> KDAGG   KeyedDictionary
> LZSTAGG LazyStreamAggregate
> LMODULE LeftModule
> LSAGG   ListAggregate
> MSETAGG MultisetAggregate
> NARNG   NonAssociativeRng
> A1AGG   OneDimensionalArrayAggregate
> OCAMON  OrderedCancellationAbelianMonoid
> RSETCAT RegularTriangularSetCategory
> RMODULE RightModule
> RNG     Rng
> BMODULE BiModule
> BTAGG   BitAggregate
> NASRING NonAssociativeRing
> NTSCAT  NormalizedTriangularSetCategory
> OAGROUP OrderedAbelianGroup
> OAMONS  OrderedAbelianMonoidSup
> OMSAGG  OrderedMultisetAggregate
> RING    Ring
> SFRTCAT SquareFreeRegularTriangularSetCategory
> SRAGG   StringAggregate
> TBAGG   TableAggregate
> VECTCAT VectorCategory
> ALAGG   AssociationListAggregate
> CHARNZ  CharacteristicNonZero
> CHARZ   CharacteristicZero
> COMRING CommutativeRing
> DIFRING DifferentialRing
> ENTIRER EntireRing
> FMCAT   FreeModuleCat
> LALG    LeftAlgebra
> LINEXP  LinearlyExplicitRingOver
> MODULE  Module
> ORDRING OrderedRing
> PDRING  PartialDifferentialRing
> PTCAT   PointCategory
> RMATCAT RectangularMatrixCategory
> SNTSCAT SquareFreeNormalizedTriangularSetCategory
> STRICAT StringCategory
> OREPCAT UnivariateSkewPolynomialCategory
> XALG    XAlgebra
> ALGEBRA Algebra
> DIFEXT  DifferentialExtension
> FLINEXP FullyLinearlyExplicitRingOver
> LIECAT  LieAlgebra
> LODOCAT LinearOrdinaryDifferentialOperatorCategory
> NAALG   NonAssociativeAlgebra
> VSPACE  VectorSpace
> XFALG   XFreeAlgebra
> DIRPCAT DirectProductCategory
> DIVRING DivisionRing
> FINAALG FiniteRankNonAssociativeAlgebra
> FLALG   FreeLieAlgebra
> INTDOM  IntegralDomain
> MLO     MonogenicLinearOperator
> OC      OctonionCategory
> QUATCAT QuaternionCategory
> SMATCAT SquareMatrixCategory
> XPOLYC  XPolynomialsCat
> AMR     AbelianMonoidRing
> FMTC    FortranMachineTypeCategory
> FRNAALG FramedNonAssociativeAlgebra
> GCDDOM  GcdDomain
> OINTDOM OrderedIntegralDomain
> FAMR    FiniteAbelianMonoidRing
> INTCAT  IntervalCategory
> PSCAT   PowerSeriesCategory
> PID     PrincipalIdealDomain
> UFD     UniqueFactorizationDomain
> DIVCAT  DivisorCategory
> EUCDOM  EuclideanDomain
> MTSCAT  MultivariateTaylorSeriesCategory
> PFECAT  PolynomialFactorizationExplicit
> UPSCAT  UnivariatePowerSeriesCategory
> FIELD   Field
> INS     IntegerNumberSystem
> LOCPOWC LocalPowerSeriesCategory
> PADICCT PAdicIntegerCategory
> POLYCAT PolynomialCategory
> UTSCAT  UnivariateTaylorSeriesCategory
> ACF     AlgebraicallyClosedField
> DPOLCAT DifferentialPolynomialCategory
> FPC     FieldOfPrimeCharacteristic
> FINRALG FiniteRankAlgebra
> FS      FunctionSpace
> INFCLCT InfinitlyClosePointCategory
> PACPERC PseudoAlgebraicClosureOfPerfectFieldCategory
> QFCAT   QuotientFieldCategory
> RCFIELD RealClosedField
> RNS     RealNumberSystem
> RPOLCAT RecursivePolynomialCategory
> ULSCAT  UnivariateLaurentSeriesCategory
> UPXSCAT UnivariatePuiseuxSeriesCategory
> UPOLYC  UnivariatePolynomialCategory
> ACFS    AlgebraicallyClosedFunctionSpace
> XF      ExtensionField
> FFIELDC FiniteFieldCategory
> FPS     FloatingPointSystem
> FRAMALG FramedAlgebra
> PACFFC  PseudoAlgebraicClosureOfFiniteFieldCategory
> ULSCCAT UnivariateLaurentSeriesConstructorCategory
> UPXSCCA UnivariatePuiseuxSeriesConstructorCategory
> FAXF    FiniteAlgebraicExtensionField
> MONOGEN MonogenicAlgebra
> PACRATC PseudoAlgebraicClosureOfRationalNumberCategory
> COMPCAT ComplexCategory
> FFCAT   FunctionFieldCategory
> PACEXTC PseudoAlgebraicClosureOfAlgExtOfRationalNumberCategory
>

\start
Date: Sat, 25 Jul 2015 16:40:53 -0500
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: Re: [Axiom-developer] Call for help

>You will have to excuse me if I dozed off in the back seat during the
>trip.  Is this where we are?

We're still lost but things have changed a bit since the 80s.

>We have a programming language (say SPAD or lisp) and a program in
>that language represented by a series of statements.

>The intent is to construct, in a literate manner, a series of
>statements in MPL and SPAD that are flagged and readable by the
>respective compilers such that if the MPL statements are logically
>correct (assertions match conclusions) then SPAD will also reach the
>same conclusions as you stated in MPL.  Presumably that is also done
>by MPL via a dictionary or some such.

>For instance in Left Module Construction the assertions are equivalent 
>to a triple F: (R(\cdot , +),G(+),RxG->G(+) and the base qualification is:
>R is a ring
>G is a group
>RxG is legitimate map from R,G to G
>etc...
>And fail (hopefully informatively) if one of these fails
>or Return a construct that has all of the functional properties of Left 
>Modules.

>Now the literate program has a "model" of Left Module in MPL and then
>checks the SPAD code to see if it correctly does all the of the above
>checks.  If you have done all that then it seems to me that there
>should also be a "hook" that check my custom code as well; of course
>that should be optional and only done when required.  And requires
>that I can define my expectations for my code (which unfortunately I
>sometimes can't).

>Forgive any ignorance but I left off back in the 80's with a Sandia (I
>think) formalism to check the correctness of code.  That is: make
>assertions about what the code will do with the input and verify that
>the code does that.  To give credit this was supposed to be done by
>first order predicate expressions that can be verified.

>I would appreciate constructive corrections and suggestions.

It depends on what horizon we're discussing. There are at least 3
"in plan" at the moment, although like everything that isn't in
running code, this is subject to change.

THE NEAR TERM HORIZON

The near-term goal is to get the "first turn of the crank".
This first step in happening now. 

Lisp Level Code

At the lisp level I've begun marking the code with two pieces of
information, a haskell-like type signature and a "level" indicator.
Lisp-level data structures will initially be used. These will get
closer to the Spad-level types (e.g. constructors) as the code gets
closer to Spad, which from the lisp viewpoint nothing more than a
domain-specific language (DSL).

The "level" indicator marks code with its "height" in the lisp
hierarchy. Code which is pure common lisp is marked at level 0.
Code implemented using only common lisp and level 0 code is level 1,
etc. This allows us to crawl up the code from ground-level.

Lisp-level code is being proven using ACL2 and side-level proofs.
That is, the "proof" is a version of the code that fits within the
ACL2 constraints (e.g. is not using floats). Some ACL2 code is
directly executable Common Lisp and will be used verbatim.

Currently this proven code is automatically extracted at build time
and given to ACL2 to prove.

Spad Level Code

At the Spad level, it appears that COQ is the closest in spirit.
COQ allows dependent types (e.g. arrays with fixed length) and
executable primitives so properties can be defined by code.

Here the game is to decorate the categories with mathematical
axioms. These axioms will be (re-)stated in COQ so they can be 
used in proofs. The axioms are spread across the categories and
inherited using the same hierarchy as the category structure.
Thus Group inherits from Ring, etc.

Some categories provide default code. This will be the first
level of attack using COQ, trying to prove that the code conforms
to and correctly implements the axioms.

Machinery needs to be created to put these axioms into the
system in an effective way. For instance, )show should be able
to aggregate and display the inherited collection. The proof
extraction machine needs to be able to collect and assert the
axioms prior to proof.

Currently this proven code is automatically extracted at build time
and given to COQ to prove. COQ contains support for things like
integer arithmetic so this will help with the circular reference
issue.

"Other level" code

Axiom compiles to C using GCL. There is work based on LLVM that
supplies proof technology. C compiles to i86 machine code. I have
written a program which takes i86 binary code and produces 
conditional-concurrent assignments (CCA) which define the machine
level semantics of each Intel instruction. The CCAs can be
combined to produce the semantics of blocks of code. 
(see http://daly.axiom-developer.org/intel.pdf)

So there are the beginnings of "full stack" proof technologies
from Spad to machine code. In the near term we only care about
the Spad and Lisp code.

Expectations

This will be a learning experience. It is expected that the effort
will uncover bugs, misconceptions, and unprovable hypothesis cases.

THE MIDDLE TERM HORIZON

The near term proofs are "side-proofs" that sit alongside existing
code. However, we have complete control over the Spad-to-Lisp compiler
so it is possible to generate the proof code from the Spad code. We
also have complete control over the Lisp-to-C compiler so it is
possible to generate the proof code from the Lisp code. Even now some
ACL2 Lisp code is directly executable and I expect this trend to
continue.

This will certainly cause existing code to be reshaped, rewritten, and
reorganized. It will also make code even harder to write. But the
benefit is much higher confidence in the answers provided.

Since this will take a long time we can hope that the tools we use
will be much better. Quite a few things have changed since I used
NTHQM back in the distant past. I expect they will continue to change
for the better.

THE LONG TERM HORIZON

Computational mathematics is more constrained than general mathematics.
Proofs need to be constructive and need to account for more details. 
That said, it is still mathematics. We can and should demand that 
Axiom is "correct" for some provable version of "correct".

Already there are proofs of some algorithms. I have a proof of
Buchberger's algorithm. Ideally this proven code and its associated
proof can be directly inserted into Axiom.


This is a lot of work. Fortunately Axiom has a 30 year horizon so
there is plenty of time.

Tim

\start
Date: Sat, 25 Jul 2015 19:28:38 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] Call for help

Okay,
I looked at intel.pdf and brought to mind a crosscompiler I wrote way 
back when.  Convincing a PDP-8 compiler to generate object code for 
something like a 6809.  It's vague but I am convinced I was looking at 
object code and outputting differrent object code.  Or some such but 
nevertheless there are resemblances.
Aside from the semantics you seem to be trying to convert one type of 
code into another (of a mathematical syntax) or "decorate" existing 
code  for something else to agree with.  or ??
Questions and comments inline:
On 07/25/2015 05:40 PM, daly@axiom-developer.org wrote:
> --------------------------------------------
> It depends on what horizon we're discussing. There are at least 3
> "in plan" at the moment, although like everything that isn't in
> running code, this is subject to change.
>
> THE NEAR TERM HORIZON
>
> The near-term goal is to get the "first turn of the crank".
> This first step in happening now.
>
> Lisp Level Code
>
> At the lisp level I've begun marking the code with two pieces of
> information, a haskell-like type signature and a "level" indicator.
> Lisp-level data structures will initially be used. These will get
> closer to the Spad-level types (e.g. constructors) as the code gets
> closer to Spad, which from the lisp viewpoint nothing more than a
> domain-specific language (DSL).
So when I feed SPAD a statement it will have been previously been 
verified that the statement will be "correctly" interpreted and 
excuted.  "previously verified" means that it has been proven by a third 
party that syntactically correct statements will result in results that 
match some other description.

>
> The "level" indicator marks code with its "height" in the lisp
> hierarchy. Code which is pure common lisp is marked at level 0.
> Code implemented using only common lisp and level 0 code is level 1,
> etc. This allows us to crawl up the code from ground-level.
I really have doubts about relying on a single "level" indicator. My 
experience is that more complex structures are necessary for effective 
operation.  Unless it's just used as a project management tool.
>
> Lisp-level code is being proven using ACL2 and side-level proofs.
> That is, the "proof" is a version of the code that fits within the
> ACL2 constraints (e.g. is not using floats). Some ACL2 code is
> directly executable Common Lisp and will be used verbatim.
I have to look ACL2 up and find out it's relationship to Lisp.
>
> Currently this proven code is automatically extracted at build time
> and given to ACL2 to prove.
So your saying that with a few additions no translation is needed? 
That's good.
>
> Spad Level Code
>
> At the Spad level, it appears that COQ is the closest in spirit.
> COQ allows dependent types (e.g. arrays with fixed length) and
> executable primitives so properties can be defined by code.
>
> Here the game is to decorate the categories with mathematical
> axioms. These axioms will be (re-)stated in COQ so they can be
> used in proofs. The axioms are spread across the categories and
> inherited using the same hierarchy as the category structure.
> Thus Group inherits from Ring, etc.
re-stated?  Is this to be contained in literate programming.  What I 
asking is why re-state?  Is the input to be provided in CDQ format or is 
some other program acting as an inter-mediator for both COQ and SPAD?
>
> Some categories provide default code. This will be the first
> level of attack using COQ, trying to prove that the code conforms
> to and correctly implements the axioms.
Okay, now we are on an internal code line and have stacked up a 
data-structure with "history" (i.e. this term represents at least a 
group) and we are asking some code A (SPAD or Axiom) to do something to 
it; say provide an output.  The fact that this code has been previously 
checked by COQ will verify that code A will preform the modification as 
described in some third format; presumably COQ.
>
> Machinery needs to be created to put these axioms into the
> system in an effective way. For instance, )show should be able
> to aggregate and display the inherited collection. The proof
> extraction machine needs to be able to collect and assert the
> axioms prior to proof.
Yes a hierarchy with clean goals would be nice.  I have dug through some 
of the background code in Axiom and some readability (literate 
programming) would have been nice.   But of course I have a simple mind 
and limited knowledge.
>
> Currently this proven code is automatically extracted at build time
> and given to COQ to prove. COQ contains support for things like
> integer arithmetic so this will help with the circular reference
> issue.
I realize I am being lazy but a pointer to an example would be appreciated.
>
> "Other level" code
>
> Axiom compiles to C using GCL. There is work based on LLVM that
> supplies proof technology. C compiles to i86 machine code. I have
> written a program which takes i86 binary code and produces
> conditional-concurrent assignments (CCA) which define the machine
> level semantics of each Intel instruction. The CCAs can be
> combined to produce the semantics of blocks of code.
> (see http://daly.axiom-developer.org/intel.pdf)
>
> So there are the beginnings of "full stack" proof technologies
> from Spad to machine code. In the near term we only care about
> the Spad and Lisp code.
Now this has several levels, all of which seem to be related to 
cross-compiling.  I would feel much more secure if all of the 
cross-compiling was handled by one agent; that can also be verified.
>
> Expectations
>
> This will be a learning experience. It is expected that the effort
> will uncover bugs, misconceptions, and unprovable hypothesis cases.
>
> THE MIDDLE TERM HORIZON
>
> The near term proofs are "side-proofs" that sit alongside existing
> code. However, we have complete control over the Spad-to-Lisp compiler
> so it is possible to generate the proof code from the Spad code. We
> also have complete control over the Lisp-to-C compiler so it is
> possible to generate the proof code from the Lisp code. Even now some
> ACL2 Lisp code is directly executable and I expect this trend to
> continue.
>
> This will certainly cause existing code to be reshaped, rewritten, and
> reorganized. It will also make code even harder to write. But the
> benefit is much higher confidence in the answers provided.
>
> Since this will take a long time we can hope that the tools we use
> will be much better. Quite a few things have changed since I used
> NTHQM back in the distant past. I expect they will continue to change
> for the better.
I can't remember or find NTHQM; I presume it's related to the history of 
program verification (Sandia?).
>
> THE LONG TERM HORIZON
>
> Computational mathematics is more constrained than general mathematics.
> Proofs need to be constructive and need to account for more details.
> That said, it is still mathematics. We can and should demand that
> Axiom is "correct" for some provable version of "correct".
Oh yes: we would like to be "Standing on the shoulders of giants" not 
being trampled underneath.
>
> Already there are proofs of some algorithms. I have a proof of
> Buchberger's algorithm. Ideally this proven code and its associated
> proof can be directly inserted into Axiom.
Sketch?
>
>
> This is a lot of work. Fortunately Axiom has a 30 year horizon so
> there is plenty of time.
>
> Tim
>
One further comment along the literate program lines.  Unless the 
organization and references are transparent, the project will be tower 
of Babel with the same consequences.  Although I think the world is 
complex I do know that for human projects organization is key to continuity.
Euclid is my hero in math :):)  Someone I appreciate more and more.

-- 

\start
Date: Sun, 26 Jul 2015 17:53:25 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

On 25/07/15 12:38, daly@axiom-developer.org wrote:
> Axiom has moved into a new phase. The goal is to prove Axiom correct.

Tim,

Why not do the easy bit first and just mark up the operators, in 
domains, with the following common Axioms/Identities?

Only for functions with signature: ($,$)->Boolean

reflexivity forall(x): x<=x
antisymmetry forall(x,y): x<=y and y<=x implies x=y
symmetry forall(x,y): x<=y and y<=x implies error
transitivity forall(x,y,z): x<=y and y<=z implies x<=z

Only for operators with signature: ($,$)->$

commutativity: forall(x,y): x o y=y o x
associativity: forall(x,y,z): (x o y) o z=y o (x o z)
unit: forall x: x o 1=x
idempotence: forall x: x o x=x
absorption1: forall(x,y): x o (x * y)=x
absorption2: forall(x,y): x * (x o y)=x
distribution1: forall(x,y,z): x o (y * z)=(x o y) * (x o z)
distribution2: forall(x,y,z): x * (y o z)=(x * y) o (x * z)

where 'o' and '*' are replaced with the actual operator symbol.

Perhaps you could translate the above to COQ syntax?

This might be the easy bit because you only need to check for the above 
signatures and in most cases it is fairly well known if operators obey 
these identities.

What would be very interesting would be to have a program which 
generates these identities, wherever they occur in the Axiom library, 
put random values into the variables and check for non-compliance.

Martin

\start
Date: Sun, 26 Jul 2015 13:35:34 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

On 07/26/2015 12:53 PM, Martin Baker wrote:
> On 25/07/15 12:38, daly@axiom-developer.org wrote:
>> Axiom has moved into a new phase. The goal is to prove Axiom correct.
>
> Tim,
>
> Why not do the easy bit first and just mark up the operators, in 
> domains, with the following common Axioms/Identities?
>
> Only for functions with signature: ($,$)->Boolean
>
> reflexivity forall(x): x<=x
> antisymmetry forall(x,y): x<=y and y<=x implies x=y
> symmetry forall(x,y): x<=y and y<=x implies error
> transitivity forall(x,y,z): x<=y and y<=z implies x<=z
I have problems with antisymmetry and symetry.
> Only for operators with signature: ($,$)->$
>
> commutativity: forall(x,y): x o y=y o x
> associativity: forall(x,y,z): (x o y) o z=y o (x o z)
> unit: forall x: x o 1=x
> idempotence: forall x: x o x=x
> absorption1: forall(x,y): x o (x * y)=x
> absorption2: forall(x,y): x * (x o y)=x
> distribution1: forall(x,y,z): x o (y * z)=(x o y) * (x o z)
> distribution2: forall(x,y,z): x * (y o z)=(x * y) o (x * z)
>
> where 'o' and '*' are replaced with the actual operator symbol.
>
> Perhaps you could translate the above to COQ syntax?
>
> This might be the easy bit because you only need to check for the 
> above signatures and in most cases it is fairly well known if 
> operators obey these identities.
>
> What would be very interesting would be to have a program which 
> generates these identities, wherever they occur in the Axiom library, 
> put random values into the variables and check for non-compliance.
I was also thinking along similar lines; but are the above assertions 
that can be made x \in R  or tests/validations of input variables/arguments?
These are of course simple cases; but I love simplicity.
Random variables?   I wouldn't go there; for one thing "corner cases" 
have to done if nothing else.  As a matter of fact if you can find 
"corners" and prove consistency between "corners" (say a convex hull in 
function space) then proving corners is powerful in the sense we want.   
That is not trying all possibilities.  For instance equivalence 
relations might be phrased as an assertion of convexity inside certain 
things.  If you like I might be able to rattle on about this; of course 
it's probably my own eccentric terminology and I am studying Lie 
Groups/Algebra so am inclined to apply the ideas to types of toothpaste :)
Ray

\start
Date: Sun, 26 Jul 2015 14:26:28 -0500
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>
Subject: Re: [Axiom-developer] Call for help

Martin,

There is a distinction to be made between mathematical AXIOMS for
the category (e.g. associative) and SIGNATURES for the functions
in a category (domain, package). 

Interesting questions arise for functions like coerce, convert,
and retract about how they preserve AXIOMs across domains.
Packages have a similar issue as packages tend to do rewrites.

If nothing else, this task is going to be educational.

Tim

\start
Date: Sun, 26 Jul 2015 14:27:22 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

Martin,

I like the idea of "specific mathematical axiom markup" as a first
cut.  I will try this idea.

This is (reasonably) easy to do as there are already some markers
in place. These are the "attributes" such as LeftUnitary.
Unfortunately most of them are somewhat more advanced, such as
FiniteAggregate, which requires the use of dependent types.
That's still a steep hill to climb.

Axiom has signatures already. The real hack would be to unify
the signatures used by COQ with the signatures used by Axiom.
That way COQ would have access to the Axiom signature database
and Axiom would be able to use COQ to prove Spad code. This
would be the very essence of elegance.

Right now in Axiom you can say
   )d op pop!
and it will show you signatures and examples from domains.
Perhaps we can develop a "rewriter" that will translate the
Axiom signature to a COQ signature.

==========================================================
)d op pop!

There are 4 exposed functions called pop! :
   [1] ArrayStack(D1) -> D1 from ArrayStack(D1) if D1 has SETCAT
   [2] Dequeue(D1) -> D1 from Dequeue(D1) if D1 has SETCAT
   [3] D -> D1 from D if D has SKAGG(D1) and D1 has TYPE
   [4] Stack(D1) -> D1 from Stack(D1) if D1 has SETCAT

Examples of pop! from ArrayStack

a:ArrayStack INT:= arrayStack [1,2,3,4,5] 
pop! a 
a


Examples of pop! from Dequeue

a:Dequeue INT:= dequeue [1,2,3,4,5] 
pop! a 
a


Examples of pop! from StackAggregate

a:Stack INT:= stack [1,2,3,4,5] 
pop! a 
a


Examples of pop! from Stack

a:Stack INT:= stack [1,2,3,4,5] 
pop! a 
a
=============================================================

There really ought to be a way to show the mathematical axioms,
possibly as part of the output of the )show command.

Tim

\start
Date: Mon, 27 Jul 2015 04:31:32 +0200
From: Kurt Pagani <kp@scios.ch>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

A look at the definition of "gcd" in catdef.spad shows that the tricky
bit is how to deal with imperative constructs like while ... repeat etc.
In Coq's standard libraries we find "gcd" in Coq.ZArith.Znumtheory [1]
and in Coq.ZArith.Zgcd_alt [2], whereby the latter (earlier version) is
based on Euclid's algorithm which is more suitbale for our purposes.
Formally we only need to prove:

Theorem spad_gcd_ok: forall a,b : NNI, spad_gcd(a,b) = Zgcd_alt(a,b).

where "spad_gcd" means a suitable specification of "gcd" (preferably
1:1). However, this is not as simple as it might look at first sight.
There are various methods to do this as described in the links
(verficiation) below. It is certainly feasible to implement some
automatism (see the "tools" links further below), however, it might be
worthwile to do some thinking first.


[1] https://coq.inria.fr/library/Coq.ZArith.Znumtheory.html
[2] https://coq.inria.fr/library/Coq.ZArith.Zgcd_alt.html



catdef.spad (line 500 ff.)
====================================================================
import from NonNegativeInteger

-- declarations
x, y, z : %

...

gcd(x, y) ==                --Euclidean Algorithm
  x := unitCanonical x
  y := unitCanonical y
  while not zero? y repeat
     (x, y) := (y, x rem y)
      y := unitCanonical y     -- this doesn't affect the
                               -- correctness of Euclid's algorithm,
                               -- but
                               -- a) may improve performance
                               -- b) ensures gcd(x, y)=gcd(y, x)
                               --    if canonicalUnitNormal
   x

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




---Verification
[Software Foundations]
http://www.cis.upenn.edu/~bcpierce/sf/current/index.html
(esp. http://www.cis.upenn.edu/~bcpierce/sf/current/Imp.html)

[Proving sorted lists correct using the Coq proof assistant]
http://www.randomhacks.net/2015/07/19/proving-sorted-lists-correct-using-coq-proof-assistent/

[Software Validation and Verification], P. Cabalar
http://www.dc.fi.udc.es/~cabalar/vv/
(slides!)

[Introduction to the Coq proof-assistant for
practical software verication] by Christine Paulin-Mohring
https://www.lri.fr/~paulin/LASER/course-notes.pdf


--- Tools
Several tools are being built on top of Coq, for software verification
purposes:

[Ott]
http://www.cl.cam.ac.uk/~pes20/ott/

[Why3]
http://why3.lri.fr/

[Ynot]
http://ynot.cs.harvard.edu/

[Bedrock]
http://plv.csail.mit.edu/bedrock/


--- Math
[Implementation of Bourbaki's Elements of Mathematics in Coq]
http://www-sop.inria.fr/members/Jose.Grimm/coq.pdf
http://www-sop.inria.fr/marelle/gaia/

[Coq Math Projects]
https://coq.inria.fr/cocorico/List%20of%20Coq%20Math%20Projects


Kurt


Am 25.07.2015 um 13:38 schrieb daly@axiom-developer.org:
> Axiom has moved into a new phase. The goal is to prove Axiom correct.
> 
> There are several tools and several levels of proof. I've added
> the machinery to run proofs in COQ (for algebra) and ACL2 (for
> the interpreter and compiler).
> 
> One of the first steps for the algebra proofs involves decorating
> the categories with their mathematical axioms. That's where I am
> asking for your help.
> 
> There are 241 categories, such as Monoid, which need to be annotated.
> I've listed them below, sorted in the order by which they inherit
> from prior categories, so that the complexity increases. The file
> http://axiom-developer.org/axiom-website/endpaper.pdf
> has a graph of the categories from the Jenks book which could be
> a great help.
> 
> Please look at the categories and find or create the axioms.
> If you have a particularly good reference page on the web or
> a particularly good book that lists them, please let me know.
> 
> The axioms have to be in a certain form so they can be used in
> the calculus of inductive constructions (the theory behind COQ).
> 
> The plan is to decorate the categories, then provide proofs for
> category-default code. Unfortunately, Axiom is circular so some
> of the domains are going to require proofs also. 
> 
> This task should be at least as hard as it was to get Axiom to
> build stand-alone in the first place which took about a year.
> The best case will be that the implementations are proven correct.
> The bad case will be corner cases where the implementation cannot
> be proven.
> 
> In any case, your help will make this first step easier. Drag out
> your favorite reference book and decorate LeftModule :-).
> 
> Thanks,
> Tim
> 

\start
Date: Sun, 26 Jul 2015 22:13:14 -0500
From: daly@axiom-developer.org
To: Kurt Pagani <kp@scios.ch>, axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

I'm taking Pierce's online course at the moment (Software Foundations
in Coq).

>and in Coq.ZArith.Zgcd_alt [2], whereby the latter (earlier version) is
>based on Euclid's algorithm which is more suitable for our purposes.

It is becoming clear that between an implmentation of an algorithm and
its proof there is a bit of a gap. I've tried a couple of them so far
with no progress but that just means there is more to learn.

>Formally we only need to prove:

>Theorem spad_gcd_ok: forall a,b : NNI, spad_gcd(a,b) = Zgcd_alt(a,b).

>where "spad_gcd" means a suitable specification of "gcd" (preferably
>1:1). However, this is not as simple as it might look at first sight.
>There are various methods to do this as described in the links
>(verficiation) below. It is certainly feasible to implement some
>automatism (see the "tools" links further below), however, it might be
>worthwile to do some thinking first.

It is clear that we can prove some mathematical facts. The game is
to prove the implementation, as you point out. Currently a gathering of
the category level implementations into a file (obj/ubuntu/proofs/coq.v)
will give an overview of the problem. The hope is to get a foothold on
one or a few of these implementations and learn how to do this generally.

COQ has proofs of some of them already (e.g. not) and it might be
reasonable to accept them as "ground truth". We don't want to waste
time proving what COQ already knows, especially about the integers.
So one of the tasks will be to discover and import the COQ definitions
related to the specific proof.

Another issue is that the category implementations assume, in many
cases, that they are parameterized by a specific domain. So we would
be forced to say

    forall domains $
      where $ has the axioms....
        then this categorical method applies

where we have to collect the axioms from the categories of domain $.
That's the motivation for the task of finding and annotating the
categories with their axioms. 

We might be forced to do the proofs in each specific domain rather
than at the category level.

In any case, it seems best to do something in the face of overwhelming
ignorance, if only for the educational value of the mistakes made while
doing it wrong. 

Thanks for the links. 

Tim

\start
Date: Mon, 27 Jul 2015 08:16:11 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

On 26/07/15 20:27, daly@axiom-developer.org wrote:
> Martin,
>
> I like the idea of "specific mathematical axiom markup" as a first
> cut.  I will try this idea.

 > There is a distinction to be made between mathematical AXIOMS for
 > the category (e.g. associative) and SIGNATURES for the functions
 > in a category (domain, package).

In order to discuss the issues I have invented some pseudo code below 
for 4 interlinked lattice categories. I find it easier to invent 
categories that don't already exist in Axiom library to avoid 
discussions about what the original author intended.

My conclusions from this exercise are:

1) I have shown the Axioms/Identities/Theorems (or whatever they are?) 
as comments but I think they should be part of the code.

2) I think they need to be inherited in the same way the function 
signatures are. Otherwise the Lattice category would have to duplicate 
all the axioms for both the MeetSemilattice and the JoinSemilattice. So 
domains would inherit axioms from categories. Proofs could still be done 
at the domain level even if the axioms are specified at the category level.

3) Some categories could have exactly the same signatures but differ 
only in their axioms.

4) Axioms are operator specific and not for the whole category. For 
instance the lattice category inherits a commutativity axiom for join 
and another commutativity axiom for meet. There is not just one 
commutativity axiom. For more 'numerical' categories I guess we would 
assume a commutativity flag applies to * and that + is always 
commutative but relying on assumptions like that does not seem to 
generalise well.

Martin
-------------------------------------------------------------------------

)abbrev category MEETLAT MeetSemilattice
++ Description: meet semilattice
++   Implementations in logic, sets and orders
++ Axiom: commutativity forall(x,y): x/\y=y/\x
++ Axiom: associativity forall(x,y,z): (x/\y)/\z=y/\(x/\z)
++ Axiom: unit forall x: x/\true()=x
++ Axiom: idempotence forall x: x/\x=x
MeetSemilattice: Category == SetCategory with
         _/_\: ($, $) -> $
         ++ returns the logical 'meet', e.g. 'and'.
         true: constant -> $
         ++ returns true.

)abbrev category JOINLAT JoinSemilattice
++ Description: join semilattice
++   Don't use for exterior Grassmann product operator as
++   that anticommutes
++   need to check precedence when used as an infix operator
++ Axiom: commutativity forall(x,y): x\/y=y\/x
++ Axiom: associativity forall(x,y,z): (x\/y)\/z=y\/(x\/z)
++ Axiom: unit forall x: x\/false()=x
++ Axiom: idempotence forall x: x\/x=x
JoinSemilattice: Category == SetCategory with
         _\_/: ($, $) -> $
         ++ returns the logical 'join', e.g. 'or'.
         false: constant -> $
         ++ returns false.

)abbrev category LAT Lattice
++ Description: lattice
++ Axiom: absorptionMeetOverJoin forall(x,y): x/\(x\/y)=x
++ Axiom: absorptionJoinOverMeet forall(x,y): x\/(x/\y)=x
Lattice: Category == Join(MeetSemilattice,JoinSemilattice)

)abbrev category DISTLAT DistributiveLattice
++ Description: not every lattice is distributive so treat this
++              as a different case
++ Axiom: distribution1 forall(x,y,z): x/\(y\/z)=(x/\y)\/(x/\z)
++ Axiom: distribution2 forall(x,y,z): x\/(y/\z)=(x\/y)/\(x\/z)
DistributiveLattice: Category == Lattice

\start
Date: Mon, 27 Jul 2015 05:22:00 -0500
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>, axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

> > There is a distinction to be made between mathematical AXIOMS for
> > the category (e.g. associative) and SIGNATURES for the functions
> > in a category (domain, package).

>In order to discuss the issues I have invented some pseudo code below 
>for 4 interlinked lattice categories. I find it easier to invent 
>categories that don't already exist in Axiom library to avoid 
>discussions about what the original author intended.

Excellent!





>My conclusions from this exercise are:

>1) I have shown the Axioms/Identities/Theorems (or whatever they are?) 
>as comments but I think they should be part of the code.

Yes, they do have to be part of the code. They also have to be 
available at compile time because the medium term plan is to 
use them in the compiler.

Previous markups are in comments just like you did below. See, for
instance, AbelianSemiGroup, which includes (minus latex)

++  Axioms:
++    associative("+":(%,%)->%) (x+y)+z = x+(y+z)
++    commutative("+":(%,%)->%) x+y = y+x

These could be added by making the compiler aware of another block.
That is, the compiler would know about

)abbrev category FOO Foo
Foo: Category == Bar with
    sig1
    sig2
  == add
    sig1 == ...
  assuming
    AssociativeAxiom:
    CommuativeAxiom:
    Proviso1:
    Definition1:

There is a bit of a struggle between an Axiom-like syntax and a
COQ-like syntax. Axiom syntax would make it easier on the compiler.
COQ syntax would make it easier on the proof checker.

The real win would be to find an isomorphism between the two.
This ought to be possible, or at least reasonable, since they are
both trying to express the same facts.

Definition stanzas would add things needed in the proof but are not
normal mathematical axioms. 




>2) I think they need to be inherited in the same way the function 
>signatures are. Otherwise the Lattice category would have to duplicate 
>all the axioms for both the MeetSemilattice and the JoinSemilattice. So 
>domains would inherit axioms from categories. Proofs could still be done 
>at the domain level even if the axioms are specified at the category level.

Agreed. Inheriting is the only reasonable thing to do. 
(Ah, the future joy of hacking the compiler. Sigh.)

This also has the potential benefit of replacing the attributes with
references to axioms, e.g. 

  LeftIdentityAttribute becomes LeftIdentityAxiom. 

This feels much less ad-hoc.





>3) Some categories could have exactly the same signatures but differ 
>only in their axioms.

Can you give me an idea of where this might happen?
This isn't an obvious case.





>4) Axioms are operator specific and not for the whole category. For 
>instance the lattice category inherits a commutativity axiom for join 
>and another commutativity axiom for meet. There is not just one 
>commutativity axiom. For more 'numerical' categories I guess we would 
>assume a commutativity flag applies to * and that + is always 
>commutative but relying on assumptions like that does not seem to 
>generalise well.

Would this be covered by the current mechanism (using 'if' as in:

   if $ has Monoid
     x ** y == exp(y * log x)

Or perhaps we can re-think the 'if' and move the conditional cases
into their own categories. This would have the benefit of 
simpliying the compiler and the inheritance machinery. It would
have the down side of expanding the category lattice.

Tim

\start
Date: Mon, 27 Jul 2015 08:30:54 -0500
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>, axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

>This goes back to pop! ; it would seem that push/pop is an abstract
>logical idea and shouldn't be specialized with different versions for
>each domain/catagory.  I might like to temporarily push/pop one of the
>elements of the above, infinite, Euclidean domains during calculations
>for GCD and not have to rewrite push/pop with all the hazards that
>carries.  In addition I would have to rely on some abstract
>delineation to prove that my new code was "correct".  So the abstract
>idea and proof has to be abstract and domain free to be coherent.

You're correct that a full proof should be abstract and domain free. But
while proving the general case might be possible, a proof might only be
available for a specific function in a specific domain.

The generalization suggested last time was to add an "assuming"
clause, of the form,

)abbrev category FOO Foo
Foo: Category == Bar with
    sig1
    sig2
  == add
    sig1 == ...
  assuming
    AssociativeAxiom:
    CommuativeAxiom:
    Proviso1:
    Definition1:

However, within a domain a single function might be easily proven.
It might make sense to extend the syntax of == definitions to admit
a proof clause, e.g.

  fn(a:Integer,b:Integer) == 
        someop(a,b)
     proof:
         ...

Tim

\start
Date: Mon, 27 Jul 2015 17:11:20 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

On 27/07/15 11:22, daly@axiom-developer.org wrote:
>> 3) Some categories could have exactly the same signatures but differ
>> only in their axioms.
>
> Can you give me an idea of where this might happen?
> This isn't an obvious case.

Well I was thinking of something like AbelianGroup vs. Group but thats 
not an example in Axiom because the '*' operator is changed to '+' so 
the signature changes. So I can't think of another example.

>> 4) Axioms are operator specific and not for the whole category. For
>> instance the lattice category inherits a commutativity axiom for join
>> and another commutativity axiom for meet. There is not just one
>> commutativity axiom. For more 'numerical' categories I guess we would
>> assume a commutativity flag applies to * and that + is always
>> commutative but relying on assumptions like that does not seem to
>> generalise well.
>
> Would this be covered by the current mechanism (using 'if' as in:
>
>     if $ has Monoid
>       x ** y == exp(y * log x)
>
> Or perhaps we can re-think the 'if' and move the conditional cases
> into their own categories. This would have the benefit of
> simpliying the compiler and the inheritance machinery. It would
> have the down side of expanding the category lattice.

When you are talking about the current mechanism is this: having an 
empty category for each attribute? It seems to me that this would 
require quite a lot of categories because we don't just need 
commutativity but meet-commutativity, join-commutativity and so on.

Martin

\start
Date: Mon, 27 Jul 2015 11:21:20 -0500
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>, axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Call for help

>>> 4) Axioms are operator specific and not for the whole category. For
>>> instance the lattice category inherits a commutativity axiom for join
>>> and another commutativity axiom for meet. There is not just one
>>> commutativity axiom. For more 'numerical' categories I guess we would
>>> assume a commutativity flag applies to * and that + is always
>>> commutative but relying on assumptions like that does not seem to
>>> generalise well.
>>
>> Would this be covered by the current mechanism (using 'if' as in:
>>
>>     if $ has Monoid
>>       x ** y == exp(y * log x)
>>
>> Or perhaps we can re-think the 'if' and move the conditional cases
>> into their own categories. This would have the benefit of
>> simpliying the compiler and the inheritance machinery. It would
>> have the down side of expanding the category lattice.
>
>When you are talking about the current mechanism is this: having an 
>empty category for each attribute? It seems to me that this would 
>require quite a lot of categories because we don't just need 
>commutativity but meet-commutativity, join-commutativity and so on.

Actually, there already is an empty category for each attribute.

But I'm thinking of something slightly different. Instead of
conditional exports where it says

  every? : ((S -> Boolean),%) -> Boolean if $ has finiteAggregate

that we have a separate category so that the new category inherits
from the prior category and unconditionally exports the additional
signatures. This eliminates the need for runtime signature checking.

It also makes it easier to attach axioms to categories because
there are no conditional attachments.

Tim

\start
Date: Fri, 31 Jul 2015 18:22:27 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom Correct

I've collected all of the functions that are implemented at the
category level. For each function I've prepended the signature.  These
chunks are automatically extracted during build and collected into a
file in the obj/sys/proofs subdirectory. The file has been uploaded to
http://daly.axiom-developer.org/coq.v

The file consists of a single COQ Module named Jenks.
Each category and its asssociated functions are comments in the file.
The categories in the file are arranged so that more primitive
categories occur before categories that inherit from them.

The next stage is to begin proving these algorithms correct using COQ.
Each proven function will be uncommented, along with its associated proof.

Tim


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