\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: Thu, 2 Jul 2020 07:15:33 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <axiomcas@gmail.com>
Subject: Re: Axiom musings...

Time for another update.

The latest Intel processors, available only to data centers
so far, have a built-in FPGA. This allows you to design
your own circuits and have them loaded "on the fly",
running in parallel with the CPU.

I bought a Lattice ICEstick FPGA development board. For
the first time there are open source tools that support it so
it is a great test bench for ideas and development. It is a
USB drive so it can be easily ported to any PC.
(https://www.latticesemi.com/products/developmentboardsandkits/icestick)

I also bought a large Intel Cyclone FPGA development board.
(http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=3DEnglish&No=3D=
836)
which has 2 embedded ARM processors. Unfortunately
the tools (which are freely available) are not open source.
It has sufficient size and power to do anything.


I've got 2 threads of work in progress, both of which
involve FPGAs (Field Programmable Gate Arrays).

Thread 1

The first thread involves proving programs correct. Once
a proof has been made it is rather easier to check the proof.
If code is shipped with a proof, the proof can be loaded into
an FPGA running a proof-checker which verifies the program
in parallel with running the code on the CPU.

I am researching the question of writing a proof checker that
runs on an FPGA, thus verifying the code "down to the metal".
The Lean proof checker is the current target.

The idea is to make "Oracle" algorithms that, because they
are proven correct and verified at runtime, can be trusted
by other mathematical software (e.g. Lean, Coq, Agda)
when used in proofs.

Thread 2


The second thread involves arithmetic. Axiom currently ships
with numeric routines (BLAS and LAPACK, see bookvol10.5).
These routines have a known set of numeric failures such as
cancellation, underflow, and scaling.

John Gustafson has designed a 'unum' numeric format that can
eliminate many of these errors. (See
Gustafson, John "The End of Error" CRC Press 2015
https://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239=
868/ref=3Dsr_1_1?dchild=3D1&keywords=3Dgustafson+the+end+of+error&qid=3D159=
3685423&sr=3D8-1)

The research goal is to implement Axiom's floating-point
arithmetic that can be offloaded onto an FPGA implementing
the unum format. Such a system would radically simplify
the implementation of BLAS and LAPACK as most of the
errors can't occur. The impact would be similar to using
multi-precision integer arithmetic, only now its floating-point.

SANE, the greater goal.

The Axiom SANE compiler / interpreter can use both of
these tools to implement trusted mathematical software.
It's a long, ambitious research effort but even if only pieces
of it succeed, it changes computational mathematics.

Tim

"A person's reach should exceed their grasp,
or what's a computer for?"  (misquoting Robert Browning)

(https://www.quotetab.com/quote/by-robert-browning/ah-but-a-mans-reach-shou=
ld-exceed-his-grasp-or-whats-a-heaven-for)




On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
> WHY PROVE AXIOM CORRECT (SANE)?
>
> Historically, Axiom credits CLU, the Cluster language by
> Barbara Liskov, with the essential ideas behind the Spad
> language. Barbara gave a talk (a partial transcript below)
> that gives the rational behind the ``where clause'' used by
> Spad.
>
> She talks about the limits of the compile time capablity.
> In particular, she says:
>
>    To go further, where we would say that T,
>    in addition, has to be an equality relation, that requires
>    much more sophisticated techniques that, even today, are
>    beyond the capabilities of the compiler.
>
> Showing that the ``equal'' function satisfies the equality
> relation is no longer ``beyond the capabilities of the compiler''.
> We have the required formalisms and mechanisms to
> prove properties at compile time.
>
> The SANE effort is essentially trying to push compile
> time checking into proving that, for categories that use
> ``equal'', we prove that the equal function implements
> equality.
>
> I strongly encourage you to watch her video.
>
> Tim
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Barbara Liskov
> May 2012
> MIT CSAIL
> Programming the Turing Machine
> https://www.youtube.com/watch?v=3DibRar7sWulM
>
> POLYMORPHISM
>
> We don't just want a set, we want polymorphism or
> generics, as they are called today. We wanted to
> have a generic set which was paramaterized by type
> so you could instantiate it as:
>
> Set =3D [T:type] create, insert,...
>   % representation for Set object
>   % implementation of Set operations
>   Set
>
> Set[int] s :=3D Set[int]$create()
> Set[int]$insert(s,3)
>
> We wanted a static solution to this problem. The
> problem is, not every type makes sense as a parameter
> to Set of T. For sets, per se, you need an equality
> relation. If it has been a sorted set we would have
> some ordering relation. And a type that didn't have
> one of those things would not have been a legitimate
> parameter. We needed a way of expressing that in a
> compile-time, checkable manner. Otherwise we would
> have had to resort to runtime checking.
>
> Our solution was
>
> Set =3D [T:  ] create, insert,...
>   T equal: (T,T) (bool)
>
>
> Our solution, what we call the ``where clause''. So we
> added this to the header. The ``where clause'' tells you
> what operations the parameter type has to have.
>
> If you have the ``where'' clause you can do the static
> checking because when you instantiate, when you provide
> an actual type, the compiler can check that the type has
> the operations that are required. And then, when you write
> the implementation of Set the compiler knows it's ok to
> call those operations because you can guarantee they are
> actually there when you get around to running.
>
> Of course, you notice that there's just syntax here; there's
> no semantics.
>
> As I'm sure you all know, compile-time type checking is
> basically a proof technique of a very limited sort and
> this was about as far as we can push what you could get out of the
> static analysis. To go further, where we would say that T,
> in addition, has to be an equality relation, that requires
> much more sophisticated techniques that, even today, are
> beyond the capabilities of the compiler.
>
>
>
>
> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>> I've spent entirely too much time studing the legal issues
>> of free and open source software. There are copyright,
>> trademark, and intellectual property laws. I have read
>> several books, listened to lectures, and read papers on
>> the subject. I've spoken to lawyers about it. I've even
>> been required, by law, to coerce people I respect.
>> You would think it was all perfectly clear. It isn't.
>>
>> The most entertaining and enlightening lectures were
>> by Robert Lefkowitz at OSCON 2004. His talk is
>> "The Semasiology of Open Source", which sounds
>> horrible but I assure you, this is a real treat.
>>
>> THE THESIS
>>
>> Semasiology, n. The science of meanings or
>> sense development (of words); the explanation
>> of the development and changes of the meanings
>> of words. Source: Webster's Revised Unabridged
>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>
>> "Open source doesn't just mean access to the
>> source code." So begins the Open Source Definition.
>> What then, does access to the source code mean?
>> Seen through the lens of an Enterprise user, what
>> does open source mean? When is (or isn't) it
>> significant? And a catalogue of open source
>> related arbitrage opportunities.
>>
>> http://origin.conversationsnetwork.org/Robert%20Lefkowitz%20-%20The%20Se=
masiology%20of%20Open%20Source.mp3
>>
>> Computer source code has words and sentence
>> structure like actual prose or even poetry. Writing
>> code for the computer is like writing an essay. It
>> should be written for other people to read,
>> understand and modify. These are some of the
>> thoughts behind literate programming proposed
>> by Donald Knuth. This is also one of the ideas
>> behind Open Source.
>>
>>  THE ANTITHESIS
>>
>> "Open Source" is a phrase like "Object Oriented"
>> - weird at first, but when it became popular, the
>> meaning began to depend on the context of the
>> speaker or listener. "Object Oriented" meant that
>> PERL, C++, Java, Smalltalk, Basic and the newest
>> version of Cobol are all "Object Oriented" - for some
>> specific definition of "Object Oriented". Similar is
>> the case of the phrase "Open Source".
>>
>> In Part I, Lefkowitz talked about the shift of the
>> meaning of "Open Source" away from any reference
>> to the actual "source code," and more towards other
>> phases of the software development life cycle. In
>> Part II, he returns to the consideration of the
>> relationship between "open source" and the actual
>> "source code," and reflects upon both the way
>> forward and the road behind, drawing inspiration
>> from Charlemagne, King Louis XIV, Donald Knuth,
>> and others.
>>
>> http://origin.conversationsnetwork.org/ITC.OSCON05-RobertLefkowitz-2005.=
08.03.mp3
>>
>> THE SYNTHESIS
>>
>> In a fascinating synthesis, Robert =E2=80=9Cr0ml=E2=80=9D Lefkowitz
>> polishes up his exposition on the evolving meaning
>> of the term =E2=80=98open source=E2=80=99. This intellectual joy-ride
>> draws on some of the key ideas in artificial intelligence
>> to probe the role of language, meaning and context
>> in computing and the software development process.
>> Like Wittgenstein=E2=80=99s famous thought experiment, the
>> open source =E2=80=98beetle in a box=E2=80=99 can represent different
>> things to different people, bearing interesting fruit for
>> philosophers and software creators alike.
>>
>> http://itc.conversationsnetwork.org/audio/download/itconversations-1502.=
mp3
>>
>>
>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>> I've pushed the lastest version of Axiom. The plan, followed
>>> so far, is to push once a month on the 7th.
>>>
>>> After some chat room interactions it was brought home
>>> again that the proof world really does not seem to like the
>>> idea of proving programs correct. And, given that it was is
>>> of the main Axiom goals and a point of friction during the fork,
>>> the computer algebra world does not like the idea of proving
>>> programs correct either.
>>>
>>> So the idea of "computational mathematics", which includes
>>> both disciplines (as well as type theory) seems still a long
>>> way off.
>>>
>>> Nevertheless, the primary change in these past and future
>>> updates is focused on merging proof and computer algebra.
>>>
>>> Proof systems are able to split the problem of creating a
>>> proof and the problem of verifying a proof, which is much
>>> cheaper. Ideally the proof checker would run on verified
>>> hardware so the proof is checked "down to the metal".
>>>
>>> I have a background in Field Programmable Gate Arrays
>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>> looking at creating a hardware proof checker using a
>>> dedicated instruction set, one designed to be verifed.
>>> New CPUs used in data centers (not yet available to us
>>> mortals) have built-in FPGAs so it would be possible to
>>> "side-load" a proof of a program to be checked while the
>>> program is run. I have the FPGA and am doing a gate-level
>>> special instruction design for such a proof checker.
>>>
>>>
>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>> mostly because it keeps muttering about Types. If you're not
>>>> familiar with type theory (most mathematicians aren't) then it
>>>> seems pointless and painful.
>>>>
>>>> So Axiom has a steep learning curve.
>>>>
>>>> As a mathematician with an algorithmic approach, it is difficult
>>>> to use a system like Axiom, mostly because you have to find
>>>> or create "domains" or "packages", understand categories
>>>> with their inheritance model, and learn a new language with
>>>> a painful compiler always complaining about types.
>>>>
>>>> So Axiom has a steep learning curve.
>>>>
>>>> The Sane version of Axiom requires knowing the mathematics.
>>>> It also assumes a background in type theory, inductive logic,
>>>> homotopy type theory, ML (meta-language, not machine
>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>> and tacticals. Also assumed is knowledge of specification languages,
>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>> Oh, and there is a whole new syntax and semantics added to
>>>> specify definitions, axioms, and theorems, not to mention whole
>>>> libraries of the same.
>>>>
>>>> So Axiom Sane has a steep learning curve.
>>>>
>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>> learning to read the leading edge literature (also known
>>>> as "greek studies", since every paper has pages of greek).
>>>>
>>>> I'm trying to unify computer algebra and proof theory into a
>>>> "computational mathematics" framework. I suspect that the only
>>>> way this system will ever be useful is after Universities have a
>>>> "Computational Mathematics" major course of study and degree.
>>>>
>>>> Creating a new department is harder than creating Axiom Sane
>>>> because, you know, ... people.
>>>>
>>>> I think such a department is inevitable given the deep and wide
>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>> started programming there was no computer science degree.
>>>>
>>>> Somebody has to be the first lemming over the cliff.
>>>>
>>>> Tim
>>>>
>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>> there is a certain amount of verification that is involved.
>>>>>
>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>> computationally more efficient if Axiom and Lean use a cryptographic
>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>> be performed. Hashes are blazingly fast. This allows proofs to be
>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>> computation request from Lean might involve many algorithms
>>>>> there would be considerable overhead to recompute each proof.
>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>
>>>>>> A computer algebra system ought to know and ought to provide
>>>>>> information about the domain and range of a resulting formula.
>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>> SuchThat domain).
>>>>>>
>>>>>> It turns out that computing with, carrying, and combining this
>>>>>> information is difficult if not impossible in the current system.
>>>>>> The information isn't available and isn't computed. In that sense,
>>>>>> the original Axiom system is 'showing its age'.
>>>>>>
>>>>>> In the Sane implementation the information is available. It is
>>>>>> part of the specification and part of the proof steps. With a
>>>>>> careful design it will be possible to provide provisos for each
>>>>>> given result that are carried with the result for use in further
>>>>>> computation.
>>>>>>
>>>>>> This raises interesting questions to be explored. For example,
>>>>>> if the formula is defined over an interval, how is the interval
>>>>>> arithmetic handled?
>>>>>>
>>>>>> Exciting research ahead!
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>
>>>>>>> While building a trusted computer algebra system, the
>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>> trust at all levels.
>>>>>>>
>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>> trusted kernel through which all other computations must
>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>> something similar.
>>>>>>>
>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>> for the logic can be specified as needed but checked by
>>>>>>> the nucleus code.
>>>>>>>
>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>> all the way down to the transistor states. You can create
>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>> history of verifying hardware logic.
>>>>>>>
>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>> form factor of a USB stick.
>>>>>>>
>>>>>>> Trust "down to the metal".
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>
>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>> the appropriate categories.
>>>>>>>>
>>>>>>>> But this is an interesting design question.
>>>>>>>>
>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>> say, the Integer category.
>>>>>>>>
>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>> ApproximateAttribute,
>>>>>>>> which implies that the results are only approximate.
>>>>>>>>
>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>> where each property has its own inheritable category,
>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>
>>>>>>>> An "axiom" category would also export a function. This function
>>>>>>>> would essentially be a "tactic" used in a proof. It would modify
>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>
>>>>>>>> Theorems would have the same structure.
>>>>>>>>
>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>
>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>> Defining the logical properties of language statements in
>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>> invariants would be partially constructed already.
>>>>>>>>
>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>> the same mechanism.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>> https://www.cs.kent.ac.uk/people/staff/srk21/) on
>>>>>>>>> Seven deadly sins of talking about =E2=80=9Ctypes=E2=80=9D
>>>>>>>>> https://www.cs.kent.ac.uk/people/staff/srk21//blog/2014/10/07/
>>>>>>>>>
>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>
>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>
>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>
>>>>>>>>> It is certainly something to explore.
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>
>>>>>>>>>> There are many goals. One of the primary goals is creating a
>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>
>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>> error (links to where errors are defined), signatures (links to
>>>>>>>>>> the signatures of lisp functions), figures (links to figures),
>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>
>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>> eventually define at least the syntax of the language. In the
>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>> not that clever.
>>>>>>>>>>
>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>
>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>> It's types all the way down.
>>>>>>>>>>
>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>
>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>> parsed the user input.
>>>>>>>>>>
>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>> Spad code.
>>>>>>>>>>
>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>
>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>> .
>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>> http://www.andrew.cmu.edu/user/avigad/meetings/fomm2020/
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>> The underlying technology to use for building such an algebra
>>>>>>>>>>> library
>>>>>>>>>>> is
>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>> Theories:
>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>> http://www.cas.mcmaster.ca/~carette/publications/tpcj.pdf [whic=
h
>>>>>>>>>>> will
>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a
>>>>>>>>>>> journal].
>>>>>>>>>>>
>>>>>>>>>>> There is a rather full-fledged prototype, very well documented
>>>>>>>>>>> at
>>>>>>>>>>> https://alhassy.github.io/next-700-module-systems/prototype/pac=
kage-former.html
>>>>>>>>>>>
>>>>>>>>>>> (source at https://github.com/alhassy/next-700-module-systems).
>>>>>>>>>>> It
>>>>>>>>>>> is
>>>>>>>>>>> literate source.
>>>>>>>>>>>
>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>> https://github.com/JacquesCarette/MathScheme.
>>>>>>>>>>>
>>>>>>>>>>> There is also a third prototype in the MMT system, but it does
>>>>>>>>>>> not
>>>>>>>>>>> quite
>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>
>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>> (https://alhassy.github.io/next-700-module-systems/papers/gpce1=
9_a_language_feature_to_unbundle_data_at_will.pdf)
>>>>>>>>>>>
>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>> theories
>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all current
>>>>>>>>>>> systems
>>>>>>>>>>> suffer from.
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas
>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>> does not depend on the algebra library (so far). It should be
>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>
>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>
>>>>>>>>>>>> This "flexible algebra" design would allow things like the
>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") developed
>>>>>>>>>>>>>> a dependently typed general parser for context free grammar
>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim

\start
Date: Thu, 2 Jul 2020 08:17:42 -0400
From: Tim Daly <axiomcas@gmail.com>
To: surow@verizon.net, axiom-developer@nongnu.org, axiomcas@gmail.com
Subject: Re: Foundations post

I just saw your email posting about agi/bica.

I have been involved in AI starting in 1975 (in
robotics at Unimation, the people with the first
robot patent).  I was a member of the robot group
at IBM Research. I have worked on just about every
known approach to AI (expert systems, knowledge
representation, speech, vision, robots, neural nets,
ML, planning, etc. I've designed a CMOS chip, a
controller board, and gotten hand-dirty on hydraulics
and gears for robots).

I created a new language (KROPS) which IBM used
in their FAME Financial and Marketing Expert System.
I co-authored ECLPS, a rule-based system. I used
a neural net to recognize and classify drugs from
drug diagrams. I designed, built, and gave a talk at
MIT on my Design-to-Build planning system using
3D modelling. I wrote a system to reverse-engineer
malware binaries. I worked on a speech system for
banking. I wrote control and vision software for
several different robot systems. My last effort at CMU
involved a man/robot system to change a car tire.

I have written code for RL from the OpenAI sandbox.
I've taken courses, such as Andrew Ng's ML course.
I have a large chess game dataset on my website I
used to attempt to train a deep neural net (badly).
I am enrolled in Autoware's self-driving car course.
I have a mobile robot and a robot arm here at home
that I use to play with ideas.

I have also spent a lot of time reading about AI,
e.g. "Parsing the Turing Test", I've read just about
everything I can find on the subject in CS,
Biology, and Philosophy. I've taken 3 courses in
brain anatomy, studied the cellular level chemistry,
and protein structures in nerve cells. I've studied
the nerve structure of the C. Elegans worm.

I've taken 3 courses in quantum mechanics. I've
read the speculation about how quantum processes
could underlie thinking (microtubules).

I have a theory about consciousness that involves
emergent complexity, chaotic theory, and self-modification.
The resulting mathematics allows an escape from
"the Turing / Godel box". So far, everyone I've presented
to just cringes at ideas like self-modification.  (See
Barwise, Jon and Moss, Lawrence "Vicious Circles",
CSLI Publications 1996
https://www.amazon.com/Barwise-Vicious-Circles-Language-Information/dp/B00SCVI0OW/ref=sr_1_2?dchild=1&keywords=Vicious+Circles+barwise&qid=1593692109&sr=8-2)

I don't think I'm any closer than anyone else, but I've
certainly given it a lot of thought and study.

All of THAT noise was to convince you that I am
not naive about the subject.

After 50 years, IN MY PROFESSIONAL OPINION:

Artificial General Intelligence (AGI) is nonsense.

Tim


On 7/1/20, Eugene Surowitz <surow@verizon.net> wrote:
> I seem to remember that you had something to do with "AXIOM" ;-)
>
> The AXIOM algebra source could be one component of the prospective project.
> Did you see the "Foundations" post?
>
> What times are good for calls?
>
> Cheers, Gene
>
>
> On 6/30/20 8:05 PM, Tim Daly wrote:
>> And this involves me how?
>>
>> I am so confused.
>>
>> If you want to talk, my home number is 724-899-3136
>>
>>
>> On 6/30/20, Eugene Surowitz <surow@verizon.net> wrote:
>>>
>>> I am talking about private support for a project that involves a
>>> solution
>>> to
>>>
>>> $n0,000/yr x 20yr = k X M
>>>
>>> where n is an integer in 5, k is probably 1, M = 10^6, x is
>>> multiplication;
>>> parameters are adjustable.
>>>
>>> The funding is a done deal in the sense that I have complete control of
>>> it.
>>>
>>> A home location for the project is needed;
>>> the legal necessities are being explored.
>>>
>>> Cheers, Gene
>>>
>>> On 6/29/20 8:20 PM, Tim Daly wrote:
>>>> I have no idea what you are talking about.
>>>>
>>>> On 6/29/20, Eugene Surowitz <surow@verizon.net> wrote:
>>>>> OK!
>>>>>
>>>>> I need to be a little careful since the effort mentioned
>>>>> in my "Foundations" post is very serious and involves another
>>>>> well known project.
>>>>>
>>>>> I am just starting lining up what needs to be done.
>>>>>
>>>>> Please do not not post this.
>>>>>
>>>>> Gene
>>>>>
>>>>> On 6/28/20 6:08 PM, Tim Daly wrote:
>>>>>> I use this one
>>>>>>
>>>>>> On 6/28/20, Eugene Surowitz <surow@verizon.net> wrote:
>>>>>>> Which email address should I use for a private conversation?
>>>>>>>
>>>>>>> Cheers, Gene

\start
Date: Sat, 18 Jul 2020 18:28:08 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <axiomcas@gmail.com>
Subject: Re: Axiom musings...

Richard Hamming gave a great talk. "You and Your Research"
https://www.youtube.com/watch?v=3Da1zDuOPkMSw

His big question is:

"What is the most important problem in your field
and why aren't you working on it?"

To my mind, the most important problem in the field of
computational mathematics is grounding computer
algebra in proofs.

Computer mathematical algorithms that "maybe,
possibly, give correct answers sometimes" is a problem.
Indeed, for computer algebra, it is the most important
problem. We need proven algorithms.

New algorithms, better graphics, better documentation,
are all "nice to have" but, as Hamming would say,
they are not "the most important problem".

Tim



On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
> Time for another update.
>
> The latest Intel processors, available only to data centers
> so far, have a built-in FPGA. This allows you to design
> your own circuits and have them loaded "on the fly",
> running in parallel with the CPU.
>
> I bought a Lattice ICEstick FPGA development board. For
> the first time there are open source tools that support it so
> it is a great test bench for ideas and development. It is a
> USB drive so it can be easily ported to any PC.
> (https://www.latticesemi.com/products/developmentboardsandkits/icestick)
>
> I also bought a large Intel Cyclone FPGA development board.
> (http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=3DEnglish&No=
=3D836)
> which has 2 embedded ARM processors. Unfortunately
> the tools (which are freely available) are not open source.
> It has sufficient size and power to do anything.
>
>
> I've got 2 threads of work in progress, both of which
> involve FPGAs (Field Programmable Gate Arrays).
>
> Thread 1
>
> The first thread involves proving programs correct. Once
> a proof has been made it is rather easier to check the proof.
> If code is shipped with a proof, the proof can be loaded into
> an FPGA running a proof-checker which verifies the program
> in parallel with running the code on the CPU.
>
> I am researching the question of writing a proof checker that
> runs on an FPGA, thus verifying the code "down to the metal".
> The Lean proof checker is the current target.
>
> The idea is to make "Oracle" algorithms that, because they
> are proven correct and verified at runtime, can be trusted
> by other mathematical software (e.g. Lean, Coq, Agda)
> when used in proofs.
>
> Thread 2
>
>
> The second thread involves arithmetic. Axiom currently ships
> with numeric routines (BLAS and LAPACK, see bookvol10.5).
> These routines have a known set of numeric failures such as
> cancellation, underflow, and scaling.
>
> John Gustafson has designed a 'unum' numeric format that can
> eliminate many of these errors. (See
> Gustafson, John "The End of Error" CRC Press 2015
> https://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/14822=
39868/ref=3Dsr_1_1?dchild=3D1&keywords=3Dgustafson+the+end+of+error&qid=3D1=
593685423&sr=3D8-1)
>
> The research goal is to implement Axiom's floating-point
> arithmetic that can be offloaded onto an FPGA implementing
> the unum format. Such a system would radically simplify
> the implementation of BLAS and LAPACK as most of the
> errors can't occur. The impact would be similar to using
> multi-precision integer arithmetic, only now its floating-point.
>
> SANE, the greater goal.
>
> The Axiom SANE compiler / interpreter can use both of
> these tools to implement trusted mathematical software.
> It's a long, ambitious research effort but even if only pieces
> of it succeed, it changes computational mathematics.
>
> Tim
>
> "A person's reach should exceed their grasp,
> or what's a computer for?"  (misquoting Robert Browning)
>
> (https://www.quotetab.com/quote/by-robert-browning/ah-but-a-mans-reach-sh=
ould-exceed-his-grasp-or-whats-a-heaven-for)
>
>
>
>
> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>> WHY PROVE AXIOM CORRECT (SANE)?
>>
>> Historically, Axiom credits CLU, the Cluster language by
>> Barbara Liskov, with the essential ideas behind the Spad
>> language. Barbara gave a talk (a partial transcript below)
>> that gives the rational behind the ``where clause'' used by
>> Spad.
>>
>> She talks about the limits of the compile time capablity.
>> In particular, she says:
>>
>>    To go further, where we would say that T,
>>    in addition, has to be an equality relation, that requires
>>    much more sophisticated techniques that, even today, are
>>    beyond the capabilities of the compiler.
>>
>> Showing that the ``equal'' function satisfies the equality
>> relation is no longer ``beyond the capabilities of the compiler''.
>> We have the required formalisms and mechanisms to
>> prove properties at compile time.
>>
>> The SANE effort is essentially trying to push compile
>> time checking into proving that, for categories that use
>> ``equal'', we prove that the equal function implements
>> equality.
>>
>> I strongly encourage you to watch her video.
>>
>> Tim
>>

>> Barbara Liskov
>> May 2012
>> MIT CSAIL
>> Programming the Turing Machine
>> https://www.youtube.com/watch?v=3DibRar7sWulM
>>
>> POLYMORPHISM
>>
>> We don't just want a set, we want polymorphism or
>> generics, as they are called today. We wanted to
>> have a generic set which was paramaterized by type
>> so you could instantiate it as:
>>
>> Set =3D [T:type] create, insert,...
>>   % representation for Set object
>>   % implementation of Set operations
>>   Set
>>
>> Set[int] s :=3D Set[int]$create()
>> Set[int]$insert(s,3)
>>
>> We wanted a static solution to this problem. The
>> problem is, not every type makes sense as a parameter
>> to Set of T. For sets, per se, you need an equality
>> relation. If it has been a sorted set we would have
>> some ordering relation. And a type that didn't have
>> one of those things would not have been a legitimate
>> parameter. We needed a way of expressing that in a
>> compile-time, checkable manner. Otherwise we would
>> have had to resort to runtime checking.
>>
>> Our solution was
>>
>> Set =3D [T:  ] create, insert,...
>>   T equal: (T,T) (bool)
>>
>>
>> Our solution, what we call the ``where clause''. So we
>> added this to the header. The ``where clause'' tells you
>> what operations the parameter type has to have.
>>
>> If you have the ``where'' clause you can do the static
>> checking because when you instantiate, when you provide
>> an actual type, the compiler can check that the type has
>> the operations that are required. And then, when you write
>> the implementation of Set the compiler knows it's ok to
>> call those operations because you can guarantee they are
>> actually there when you get around to running.
>>
>> Of course, you notice that there's just syntax here; there's
>> no semantics.
>>
>> As I'm sure you all know, compile-time type checking is
>> basically a proof technique of a very limited sort and
>> this was about as far as we can push what you could get out of the
>> static analysis. To go further, where we would say that T,
>> in addition, has to be an equality relation, that requires
>> much more sophisticated techniques that, even today, are
>> beyond the capabilities of the compiler.
>>
>>
>>
>>
>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>> I've spent entirely too much time studing the legal issues
>>> of free and open source software. There are copyright,
>>> trademark, and intellectual property laws. I have read
>>> several books, listened to lectures, and read papers on
>>> the subject. I've spoken to lawyers about it. I've even
>>> been required, by law, to coerce people I respect.
>>> You would think it was all perfectly clear. It isn't.
>>>
>>> The most entertaining and enlightening lectures were
>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>> "The Semasiology of Open Source", which sounds
>>> horrible but I assure you, this is a real treat.
>>>
>>> THE THESIS
>>>
>>> Semasiology, n. The science of meanings or
>>> sense development (of words); the explanation
>>> of the development and changes of the meanings
>>> of words. Source: Webster's Revised Unabridged
>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>
>>> "Open source doesn't just mean access to the
>>> source code." So begins the Open Source Definition.
>>> What then, does access to the source code mean?
>>> Seen through the lens of an Enterprise user, what
>>> does open source mean? When is (or isn't) it
>>> significant? And a catalogue of open source
>>> related arbitrage opportunities.
>>>
>>> http://origin.conversationsnetwork.org/Robert%20Lefkowitz%20-%20The%20S=
emasiology%20of%20Open%20Source.mp3
>>>
>>> Computer source code has words and sentence
>>> structure like actual prose or even poetry. Writing
>>> code for the computer is like writing an essay. It
>>> should be written for other people to read,
>>> understand and modify. These are some of the
>>> thoughts behind literate programming proposed
>>> by Donald Knuth. This is also one of the ideas
>>> behind Open Source.
>>>
>>>  THE ANTITHESIS
>>>
>>> "Open Source" is a phrase like "Object Oriented"
>>> - weird at first, but when it became popular, the
>>> meaning began to depend on the context of the
>>> speaker or listener. "Object Oriented" meant that
>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>> version of Cobol are all "Object Oriented" - for some
>>> specific definition of "Object Oriented". Similar is
>>> the case of the phrase "Open Source".
>>>
>>> In Part I, Lefkowitz talked about the shift of the
>>> meaning of "Open Source" away from any reference
>>> to the actual "source code," and more towards other
>>> phases of the software development life cycle. In
>>> Part II, he returns to the consideration of the
>>> relationship between "open source" and the actual
>>> "source code," and reflects upon both the way
>>> forward and the road behind, drawing inspiration
>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>> and others.
>>>
>>> http://origin.conversationsnetwork.org/ITC.OSCON05-RobertLefkowitz-2005=
.08.03.mp3
>>>
>>> THE SYNTHESIS
>>>
>>> In a fascinating synthesis, Robert =E2=80=9Cr0ml=E2=80=9D Lefkowitz
>>> polishes up his exposition on the evolving meaning
>>> of the term =E2=80=98open source=E2=80=99. This intellectual joy-ride
>>> draws on some of the key ideas in artificial intelligence
>>> to probe the role of language, meaning and context
>>> in computing and the software development process.
>>> Like Wittgenstein=E2=80=99s famous thought experiment, the
>>> open source =E2=80=98beetle in a box=E2=80=99 can represent different
>>> things to different people, bearing interesting fruit for
>>> philosophers and software creators alike.
>>>
>>> http://itc.conversationsnetwork.org/audio/download/itconversations-1502=
.mp3
>>>
>>>
>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>> so far, is to push once a month on the 7th.
>>>>
>>>> After some chat room interactions it was brought home
>>>> again that the proof world really does not seem to like the
>>>> idea of proving programs correct. And, given that it was is
>>>> of the main Axiom goals and a point of friction during the fork,
>>>> the computer algebra world does not like the idea of proving
>>>> programs correct either.
>>>>
>>>> So the idea of "computational mathematics", which includes
>>>> both disciplines (as well as type theory) seems still a long
>>>> way off.
>>>>
>>>> Nevertheless, the primary change in these past and future
>>>> updates is focused on merging proof and computer algebra.
>>>>
>>>> Proof systems are able to split the problem of creating a
>>>> proof and the problem of verifying a proof, which is much
>>>> cheaper. Ideally the proof checker would run on verified
>>>> hardware so the proof is checked "down to the metal".
>>>>
>>>> I have a background in Field Programmable Gate Arrays
>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>> looking at creating a hardware proof checker using a
>>>> dedicated instruction set, one designed to be verifed.
>>>> New CPUs used in data centers (not yet available to us
>>>> mortals) have built-in FPGAs so it would be possible to
>>>> "side-load" a proof of a program to be checked while the
>>>> program is run. I have the FPGA and am doing a gate-level
>>>> special instruction design for such a proof checker.
>>>>
>>>>
>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>> mostly because it keeps muttering about Types. If you're not
>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>> seems pointless and painful.
>>>>>
>>>>> So Axiom has a steep learning curve.
>>>>>
>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>> to use a system like Axiom, mostly because you have to find
>>>>> or create "domains" or "packages", understand categories
>>>>> with their inheritance model, and learn a new language with
>>>>> a painful compiler always complaining about types.
>>>>>
>>>>> So Axiom has a steep learning curve.
>>>>>
>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>> It also assumes a background in type theory, inductive logic,
>>>>> homotopy type theory, ML (meta-language, not machine
>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>> and tacticals. Also assumed is knowledge of specification languages,
>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>> libraries of the same.
>>>>>
>>>>> So Axiom Sane has a steep learning curve.
>>>>>
>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>> learning to read the leading edge literature (also known
>>>>> as "greek studies", since every paper has pages of greek).
>>>>>
>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>> "computational mathematics" framework. I suspect that the only
>>>>> way this system will ever be useful is after Universities have a
>>>>> "Computational Mathematics" major course of study and degree.
>>>>>
>>>>> Creating a new department is harder than creating Axiom Sane
>>>>> because, you know, ... people.
>>>>>
>>>>> I think such a department is inevitable given the deep and wide
>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>> started programming there was no computer science degree.
>>>>>
>>>>> Somebody has to be the first lemming over the cliff.
>>>>>
>>>>> Tim
>>>>>
>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>> there is a certain amount of verification that is involved.
>>>>>>
>>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>>> computationally more efficient if Axiom and Lean use a cryptographic
>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be
>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>> computation request from Lean might involve many algorithms
>>>>>> there would be considerable overhead to recompute each proof.
>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>
>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>> information about the domain and range of a resulting formula.
>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>> SuchThat domain).
>>>>>>>
>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>> information is difficult if not impossible in the current system.
>>>>>>> The information isn't available and isn't computed. In that sense,
>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>
>>>>>>> In the Sane implementation the information is available. It is
>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>> careful design it will be possible to provide provisos for each
>>>>>>> given result that are carried with the result for use in further
>>>>>>> computation.
>>>>>>>
>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>> if the formula is defined over an interval, how is the interval
>>>>>>> arithmetic handled?
>>>>>>>
>>>>>>> Exciting research ahead!
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>
>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>> trust at all levels.
>>>>>>>>
>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>> trusted kernel through which all other computations must
>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>> something similar.
>>>>>>>>
>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>> the nucleus code.
>>>>>>>>
>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>> history of verifying hardware logic.
>>>>>>>>
>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>> form factor of a USB stick.
>>>>>>>>
>>>>>>>> Trust "down to the metal".
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>
>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>> the appropriate categories.
>>>>>>>>>
>>>>>>>>> But this is an interesting design question.
>>>>>>>>>
>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>> say, the Integer category.
>>>>>>>>>
>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>> ApproximateAttribute,
>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>
>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>
>>>>>>>>> An "axiom" category would also export a function. This function
>>>>>>>>> would essentially be a "tactic" used in a proof. It would modify
>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>
>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>
>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>
>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>
>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>> the same mechanism.
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>> https://www.cs.kent.ac.uk/people/staff/srk21/) on
>>>>>>>>>> Seven deadly sins of talking about =E2=80=9Ctypes=E2=80=9D
>>>>>>>>>> https://www.cs.kent.ac.uk/people/staff/srk21//blog/2014/10/07/
>>>>>>>>>>
>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>
>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>
>>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>
>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>
>>>>>>>>>>> There are many goals. One of the primary goals is creating a
>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>
>>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>>> error (links to where errors are defined), signatures (links to
>>>>>>>>>>> the signatures of lisp functions), figures (links to figures),
>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>
>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>>> eventually define at least the syntax of the language. In the
>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>> not that clever.
>>>>>>>>>>>
>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>
>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>
>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>
>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>
>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>> Spad code.
>>>>>>>>>>>
>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>
>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>> .
>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>> http://www.andrew.cmu.edu/user/avigad/meetings/fomm2020/
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>> The underlying technology to use for building such an algebra
>>>>>>>>>>>> library
>>>>>>>>>>>> is
>>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>>> Theories:
>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>> http://www.cas.mcmaster.ca/~carette/publications/tpcj.pdf
>>>>>>>>>>>> [which
>>>>>>>>>>>> will
>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a
>>>>>>>>>>>> journal].
>>>>>>>>>>>>
>>>>>>>>>>>> There is a rather full-fledged prototype, very well documented
>>>>>>>>>>>> at
>>>>>>>>>>>> https://alhassy.github.io/next-700-module-systems/prototype/pa=
ckage-former.html
>>>>>>>>>>>>
>>>>>>>>>>>> (source at https://github.com/alhassy/next-700-module-systems)=
.
>>>>>>>>>>>> It
>>>>>>>>>>>> is
>>>>>>>>>>>> literate source.
>>>>>>>>>>>>
>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>> https://github.com/JacquesCarette/MathScheme.
>>>>>>>>>>>>
>>>>>>>>>>>> There is also a third prototype in the MMT system, but it does
>>>>>>>>>>>> not
>>>>>>>>>>>> quite
>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>
>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>> (https://alhassy.github.io/next-700-module-systems/papers/gpce=
19_a_language_feature_to_unbundle_data_at_will.pdf)
>>>>>>>>>>>>
>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>>> theories
>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all curren=
t
>>>>>>>>>>>> systems
>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas
>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>> does not depend on the algebra library (so far). It should be
>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This "flexible algebra" design would allow things like the
>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") developed
>>>>>>>>>>>>>>> a dependently typed general parser for context free grammar
>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tim

\start
Date: Sun, 19 Jul 2020 16:21:23 +0000
From: William Sit <wsit@ccny.cuny.edu>
To: Tim Daly <axiomcas@gmail.com>, axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [EXTERNAL] Re: Axiom musings...

Hi Tim:=0A=
=0A=
Glad to hear from you now and then, promoting and working towards your idea=
s and ideals.=0A=
=0A=
 >>We need proven algorithms.=0A=
=0A=
Just one short comment: it is often possible to prove algorithms (that is, =
providing the theoretical foundation for the algorithm), but it is much har=
der to prove that an implementation of the algorithm is correct. As you wel=
l know, the distinction lies in that implementation involves data represent=
ations whereas proofs of algorithms normally ignore them. Introducing (fini=
te) data representations means introducing boundary situations that a progr=
ammer implementing an algorithm must deal with. So perhaps what we need to =
prove should include the correctness of implementations (to the bare metal,=
 as you often say) and we should have a different set of analytic tools tha=
t can deal with the correctness (or completeness) of data representations. =
Of course, these tools must also be proven with the same rigor since behind=
 every program is an algorithm.=0A=
=0A=
William=0A=
=0A=
William Sit=0A=
Professor Emeritus=0A=
Department of Mathematics=0A=
The City College of The City University of New York=0A=
New York, NY 10031=0A=
homepage: wsit.ccny.cuny.edu=0A=
=0A=
________________________________________=0A=
From: Axiom-developer <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@no=
ngnu.org> on behalf of Tim Daly <axiomcas@gmail.com>=0A=
Sent: Saturday, July 18, 2020 6:28 PM=0A=
To: axiom-dev; Tim Daly=0A=
Subject: [EXTERNAL] Re: Axiom musings...=0A=
=0A=
Richard Hamming gave a great talk. "You and Your Research"=0A=
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_watc=
h-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIM=
Gmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0k=
mp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0U&e=
=3D=0A=
=0A=
His big question is:=0A=
=0A=
"What is the most important problem in your field=0A=
and why aren't you working on it?"=0A=
=0A=
To my mind, the most important problem in the field of=0A=
computational mathematics is grounding computer=0A=
algebra in proofs.=0A=
=0A=
Computer mathematical algorithms that "maybe,=0A=
possibly, give correct answers sometimes" is a problem.=0A=
Indeed, for computer algebra, it is the most important=0A=
problem. We need proven algorithms.=0A=
=0A=
New algorithms, better graphics, better documentation,=0A=
are all "nice to have" but, as Hamming would say,=0A=
they are not "the most important problem".=0A=
=0A=
Tim=0A=
=0A=
=0A=
=0A=
On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
> Time for another update.=0A=
>=0A=
> The latest Intel processors, available only to data centers=0A=
> so far, have a built-in FPGA. This allows you to design=0A=
> your own circuits and have them loaded "on the fly",=0A=
> running in parallel with the CPU.=0A=
>=0A=
> I bought a Lattice ICEstick FPGA development board. For=0A=
> the first time there are open source tools that support it so=0A=
> it is a great test bench for ideas and development. It is a=0A=
> USB drive so it can be easily ported to any PC.=0A=
> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesemi.c=
om_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQz2H=
FhAAAymG-QswIjRao_YTwz4&e=3D )=0A=
>=0A=
> I also bought a large Intel Cyclone FPGA development board.=0A=
> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com.tw=
_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=3D4=
NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdS=
WMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW6Bue=
AeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D )=0A=
> which has 2 embedded ARM processors. Unfortunately=0A=
> the tools (which are freely available) are not open source.=0A=
> It has sufficient size and power to do anything.=0A=
>=0A=
>=0A=
> I've got 2 threads of work in progress, both of which=0A=
> involve FPGAs (Field Programmable Gate Arrays).=0A=
>=0A=
> Thread 1=0A=
>=0A=
> The first thread involves proving programs correct. Once=0A=
> a proof has been made it is rather easier to check the proof.=0A=
> If code is shipped with a proof, the proof can be loaded into=0A=
> an FPGA running a proof-checker which verifies the program=0A=
> in parallel with running the code on the CPU.=0A=
>=0A=
> I am researching the question of writing a proof checker that=0A=
> runs on an FPGA, thus verifying the code "down to the metal".=0A=
> The Lean proof checker is the current target.=0A=
>=0A=
> The idea is to make "Oracle" algorithms that, because they=0A=
> are proven correct and verified at runtime, can be trusted=0A=
> by other mathematical software (e.g. Lean, Coq, Agda)=0A=
> when used in proofs.=0A=
>=0A=
> Thread 2=0A=
>=0A=
>=0A=
> The second thread involves arithmetic. Axiom currently ships=0A=
> with numeric routines (BLAS and LAPACK, see bookvol10.5).=0A=
> These routines have a known set of numeric failures such as=0A=
> cancellation, underflow, and scaling.=0A=
>=0A=
> John Gustafson has designed a 'unum' numeric format that can=0A=
> eliminate many of these errors. (See=0A=
> Gustafson, John "The End of Error" CRC Press 2015=0A=
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_End=
-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F1-5=
F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D159=
3685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtI=
MGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0=
kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0A&e=
=3D )=0A=
>=0A=
> The research goal is to implement Axiom's floating-point=0A=
> arithmetic that can be offloaded onto an FPGA implementing=0A=
> the unum format. Such a system would radically simplify=0A=
> the implementation of BLAS and LAPACK as most of the=0A=
> errors can't occur. The impact would be similar to using=0A=
> multi-precision integer arithmetic, only now its floating-point.=0A=
>=0A=
> SANE, the greater goal.=0A=
>=0A=
> The Axiom SANE compiler / interpreter can use both of=0A=
> these tools to implement trusted mathematical software.=0A=
> It's a long, ambitious research effort but even if only pieces=0A=
> of it succeed, it changes computational mathematics.=0A=
>=0A=
> Tim=0A=
>=0A=
> "A person's reach should exceed their grasp,=0A=
> or what's a computer for?"  (misquoting Robert Browning)=0A=
>=0A=
> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.com_=
quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexceed-=
2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_Oqs=
fcYl4z14qlYS02TBNmnaHUY&e=3D )=0A=
>=0A=
>=0A=
>=0A=
>=0A=
> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>> WHY PROVE AXIOM CORRECT (SANE)?=0A=
>>=0A=
>> Historically, Axiom credits CLU, the Cluster language by=0A=
>> Barbara Liskov, with the essential ideas behind the Spad=0A=
>> language. Barbara gave a talk (a partial transcript below)=0A=
>> that gives the rational behind the ``where clause'' used by=0A=
>> Spad.=0A=
>>=0A=
>> She talks about the limits of the compile time capablity.=0A=
>> In particular, she says:=0A=
>>=0A=
>>    To go further, where we would say that T,=0A=
>>    in addition, has to be an equality relation, that requires=0A=
>>    much more sophisticated techniques that, even today, are=0A=
>>    beyond the capabilities of the compiler.=0A=
>>=0A=
>> Showing that the ``equal'' function satisfies the equality=0A=
>> relation is no longer ``beyond the capabilities of the compiler''.=0A=
>> We have the required formalisms and mechanisms to=0A=
>> prove properties at compile time.=0A=
>>=0A=
>> The SANE effort is essentially trying to push compile=0A=
>> time checking into proving that, for categories that use=0A=
>> ``equal'', we prove that the equal function implements=0A=
>> equality.=0A=
>>=0A=
>> I strongly encourage you to watch her video.=0A=
>>=0A=
>> Tim=0A=
>>=0A=
>> Barbara Liskov=0A=
>> May 2012=0A=
>> MIT CSAIL=0A=
>> Programming the Turing Machine=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_w=
atch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZeP=
X0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1eGY=
&e=3D=0A=
>>=0A=
>> POLYMORPHISM=0A=
>>=0A=
>> We don't just want a set, we want polymorphism or=0A=
>> generics, as they are called today. We wanted to=0A=
>> have a generic set which was paramaterized by type=0A=
>> so you could instantiate it as:=0A=
>>=0A=
>> Set =3D [T:type] create, insert,...=0A=
>>   % representation for Set object=0A=
>>   % implementation of Set operations=0A=
>>   Set=0A=
>>=0A=
>> Set[int] s :=3D Set[int]$create()=0A=
>> Set[int]$insert(s,3)=0A=
>>=0A=
>> We wanted a static solution to this problem. The=0A=
>> problem is, not every type makes sense as a parameter=0A=
>> to Set of T. For sets, per se, you need an equality=0A=
>> relation. If it has been a sorted set we would have=0A=
>> some ordering relation. And a type that didn't have=0A=
>> one of those things would not have been a legitimate=0A=
>> parameter. We needed a way of expressing that in a=0A=
>> compile-time, checkable manner. Otherwise we would=0A=
>> have had to resort to runtime checking.=0A=
>>=0A=
>> Our solution was=0A=
>>=0A=
>> Set =3D [T:  ] create, insert,...=0A=
>>   T equal: (T,T) (bool)=0A=
>>=0A=
>>=0A=
>> Our solution, what we call the ``where clause''. So we=0A=
>> added this to the header. The ``where clause'' tells you=0A=
>> what operations the parameter type has to have.=0A=
>>=0A=
>> If you have the ``where'' clause you can do the static=0A=
>> checking because when you instantiate, when you provide=0A=
>> an actual type, the compiler can check that the type has=0A=
>> the operations that are required. And then, when you write=0A=
>> the implementation of Set the compiler knows it's ok to=0A=
>> call those operations because you can guarantee they are=0A=
>> actually there when you get around to running.=0A=
>>=0A=
>> Of course, you notice that there's just syntax here; there's=0A=
>> no semantics.=0A=
>>=0A=
>> As I'm sure you all know, compile-time type checking is=0A=
>> basically a proof technique of a very limited sort and=0A=
>> this was about as far as we can push what you could get out of the=0A=
>> static analysis. To go further, where we would say that T,=0A=
>> in addition, has to be an equality relation, that requires=0A=
>> much more sophisticated techniques that, even today, are=0A=
>> beyond the capabilities of the compiler.=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>> I've spent entirely too much time studing the legal issues=0A=
>>> of free and open source software. There are copyright,=0A=
>>> trademark, and intellectual property laws. I have read=0A=
>>> several books, listened to lectures, and read papers on=0A=
>>> the subject. I've spoken to lawyers about it. I've even=0A=
>>> been required, by law, to coerce people I respect.=0A=
>>> You would think it was all perfectly clear. It isn't.=0A=
>>>=0A=
>>> The most entertaining and enlightening lectures were=0A=
>>> by Robert Lefkowitz at OSCON 2004. His talk is=0A=
>>> "The Semasiology of Open Source", which sounds=0A=
>>> horrible but I assure you, this is a real treat.=0A=
>>>=0A=
>>> THE THESIS=0A=
>>>=0A=
>>> Semasiology, n. The science of meanings or=0A=
>>> sense development (of words); the explanation=0A=
>>> of the development and changes of the meanings=0A=
>>> of words. Source: Webster's Revised Unabridged=0A=
>>> Dictionary, =EF=BF=BD 1996, 1998 MICRA, Inc.=0A=
>>>=0A=
>>> "Open source doesn't just mean access to the=0A=
>>> source code." So begins the Open Source Definition.=0A=
>>> What then, does access to the source code mean?=0A=
>>> Seen through the lens of an Enterprise user, what=0A=
>>> does open source mean? When is (or isn't) it=0A=
>>> significant? And a catalogue of open source=0A=
>>> related arbitrage opportunities.=0A=
>>>=0A=
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversati=
onsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520of-=
2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZe=
PX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnEbus=
M&e=3D=0A=
>>>=0A=
>>> Computer source code has words and sentence=0A=
>>> structure like actual prose or even poetry. Writing=0A=
>>> code for the computer is like writing an essay. It=0A=
>>> should be written for other people to read,=0A=
>>> understand and modify. These are some of the=0A=
>>> thoughts behind literate programming proposed=0A=
>>> by Donald Knuth. This is also one of the ideas=0A=
>>> behind Open Source.=0A=
>>>=0A=
>>>  THE ANTITHESIS=0A=
>>>=0A=
>>> "Open Source" is a phrase like "Object Oriented"=0A=
>>> - weird at first, but when it became popular, the=0A=
>>> meaning began to depend on the context of the=0A=
>>> speaker or listener. "Object Oriented" meant that=0A=
>>> PERL, C++, Java, Smalltalk, Basic and the newest=0A=
>>> version of Cobol are all "Object Oriented" - for some=0A=
>>> specific definition of "Object Oriented". Similar is=0A=
>>> the case of the phrase "Open Source".=0A=
>>>=0A=
>>> In Part I, Lefkowitz talked about the shift of the=0A=
>>> meaning of "Open Source" away from any reference=0A=
>>> to the actual "source code," and more towards other=0A=
>>> phases of the software development life cycle. In=0A=
>>> Part II, he returns to the consideration of the=0A=
>>> relationship between "open source" and the actual=0A=
>>> "source code," and reflects upon both the way=0A=
>>> forward and the road behind, drawing inspiration=0A=
>>> from Charlemagne, King Louis XIV, Donald Knuth,=0A=
>>> and others.=0A=
>>>=0A=
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversati=
onsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DLTg=
LxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D=0A=
>>>=0A=
>>> THE SYNTHESIS=0A=
>>>=0A=
>>> In a fascinating synthesis, Robert =93r0ml=94 Lefkowitz=0A=
>>> polishes up his exposition on the evolving meaning=0A=
>>> of the term =91open source=92. This intellectual joy-ride=0A=
>>> draws on some of the key ideas in artificial intelligence=0A=
>>> to probe the role of language, meaning and context=0A=
>>> in computing and the software development process.=0A=
>>> Like Wittgenstein=92s famous thought experiment, the=0A=
>>> open source =91beetle in a box=92 can represent different=0A=
>>> things to different people, bearing interesting fruit for=0A=
>>> philosophers and software creators alike.=0A=
>>>=0A=
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversations=
network.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4NmamN=
ZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxN=
ZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIwON-=
5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D=0A=
>>>=0A=
>>>=0A=
>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>> I've pushed the lastest version of Axiom. The plan, followed=0A=
>>>> so far, is to push once a month on the 7th.=0A=
>>>>=0A=
>>>> After some chat room interactions it was brought home=0A=
>>>> again that the proof world really does not seem to like the=0A=
>>>> idea of proving programs correct. And, given that it was is=0A=
>>>> of the main Axiom goals and a point of friction during the fork,=0A=
>>>> the computer algebra world does not like the idea of proving=0A=
>>>> programs correct either.=0A=
>>>>=0A=
>>>> So the idea of "computational mathematics", which includes=0A=
>>>> both disciplines (as well as type theory) seems still a long=0A=
>>>> way off.=0A=
>>>>=0A=
>>>> Nevertheless, the primary change in these past and future=0A=
>>>> updates is focused on merging proof and computer algebra.=0A=
>>>>=0A=
>>>> Proof systems are able to split the problem of creating a=0A=
>>>> proof and the problem of verifying a proof, which is much=0A=
>>>> cheaper. Ideally the proof checker would run on verified=0A=
>>>> hardware so the proof is checked "down to the metal".=0A=
>>>>=0A=
>>>> I have a background in Field Programmable Gate Arrays=0A=
>>>> (FPGAs) as I tried to do a startup using them. So now I'm=0A=
>>>> looking at creating a hardware proof checker using a=0A=
>>>> dedicated instruction set, one designed to be verifed.=0A=
>>>> New CPUs used in data centers (not yet available to us=0A=
>>>> mortals) have built-in FPGAs so it would be possible to=0A=
>>>> "side-load" a proof of a program to be checked while the=0A=
>>>> program is run. I have the FPGA and am doing a gate-level=0A=
>>>> special instruction design for such a proof checker.=0A=
>>>>=0A=
>>>>=0A=
>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>> As a mathematician, it is difficult to use a system like Axiom,=0A=
>>>>> mostly because it keeps muttering about Types. If you're not=0A=
>>>>> familiar with type theory (most mathematicians aren't) then it=0A=
>>>>> seems pointless and painful.=0A=
>>>>>=0A=
>>>>> So Axiom has a steep learning curve.=0A=
>>>>>=0A=
>>>>> As a mathematician with an algorithmic approach, it is difficult=0A=
>>>>> to use a system like Axiom, mostly because you have to find=0A=
>>>>> or create "domains" or "packages", understand categories=0A=
>>>>> with their inheritance model, and learn a new language with=0A=
>>>>> a painful compiler always complaining about types.=0A=
>>>>>=0A=
>>>>> So Axiom has a steep learning curve.=0A=
>>>>>=0A=
>>>>> The Sane version of Axiom requires knowing the mathematics.=0A=
>>>>> It also assumes a background in type theory, inductive logic,=0A=
>>>>> homotopy type theory, ML (meta-language, not machine=0A=
>>>>> learning (yet)), interactive theorem proving, kernels, tactics,=0A=
>>>>> and tacticals. Also assumed is knowledge of specification languages,=
=0A=
>>>>> Hoare triples, proof techniques, soundness, and completeness.=0A=
>>>>> Oh, and there is a whole new syntax and semantics added to=0A=
>>>>> specify definitions, axioms, and theorems, not to mention whole=0A=
>>>>> libraries of the same.=0A=
>>>>>=0A=
>>>>> So Axiom Sane has a steep learning curve.=0A=
>>>>>=0A=
>>>>> I've taken 10 courses at CMU and spent the last 4-5 years=0A=
>>>>> learning to read the leading edge literature (also known=0A=
>>>>> as "greek studies", since every paper has pages of greek).=0A=
>>>>>=0A=
>>>>> I'm trying to unify computer algebra and proof theory into a=0A=
>>>>> "computational mathematics" framework. I suspect that the only=0A=
>>>>> way this system will ever be useful is after Universities have a=0A=
>>>>> "Computational Mathematics" major course of study and degree.=0A=
>>>>>=0A=
>>>>> Creating a new department is harder than creating Axiom Sane=0A=
>>>>> because, you know, ... people.=0A=
>>>>>=0A=
>>>>> I think such a department is inevitable given the deep and wide=0A=
>>>>> impact of computers, just not in my lifetime. That's ok. When I=0A=
>>>>> started programming there was no computer science degree.=0A=
>>>>>=0A=
>>>>> Somebody has to be the first lemming over the cliff.=0A=
>>>>>=0A=
>>>>> Tim=0A=
>>>>>=0A=
>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)=0A=
>>>>>> there is a certain amount of verification that is involved.=0A=
>>>>>>=0A=
>>>>>> Axiom will provide proofs (presumably validated by Lean) for its=0A=
>>>>>> algorithms. Ideally, when a computation is requested from Lean=0A=
>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is=0A=
>>>>>> returned. Lean can the verify that the proof is valid. But it is=0A=
>>>>>> computationally more efficient if Axiom and Lean use a cryptographic=
=0A=
>>>>>> hash, such as SHA1. That way the proof doesn't need to be=0A=
>>>>>> 'reproven', only a hash computation over the proof text needs to=0A=
>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be=0A=
>>>>>> exchanged without re-running the proof mechanism. Since a large=0A=
>>>>>> computation request from Lean might involve many algorithms=0A=
>>>>>> there would be considerable overhead to recompute each proof.=0A=
>>>>>> A hash simplifies the issue yet provides proof integrity.=0A=
>>>>>>=0A=
>>>>>> Tim=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'=0A=
>>>>>>>=0A=
>>>>>>> A computer algebra system ought to know and ought to provide=0A=
>>>>>>> information about the domain and range of a resulting formula.=0A=
>>>>>>> I've been pushing this effort since the 1980s (hence the=0A=
>>>>>>> SuchThat domain).=0A=
>>>>>>>=0A=
>>>>>>> It turns out that computing with, carrying, and combining this=0A=
>>>>>>> information is difficult if not impossible in the current system.=
=0A=
>>>>>>> The information isn't available and isn't computed. In that sense,=
=0A=
>>>>>>> the original Axiom system is 'showing its age'.=0A=
>>>>>>>=0A=
>>>>>>> In the Sane implementation the information is available. It is=0A=
>>>>>>> part of the specification and part of the proof steps. With a=0A=
>>>>>>> careful design it will be possible to provide provisos for each=0A=
>>>>>>> given result that are carried with the result for use in further=0A=
>>>>>>> computation.=0A=
>>>>>>>=0A=
>>>>>>> This raises interesting questions to be explored. For example,=0A=
>>>>>>> if the formula is defined over an interval, how is the interval=0A=
>>>>>>> arithmetic handled?=0A=
>>>>>>>=0A=
>>>>>>> Exciting research ahead!=0A=
>>>>>>>=0A=
>>>>>>> Tim=0A=
>>>>>>>=0A=
>>>>>>>=0A=
>>>>>>>=0A=
>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>> Trusted Kernel... all the way to the metal.=0A=
>>>>>>>>=0A=
>>>>>>>> While building a trusted computer algebra system, the=0A=
>>>>>>>> SANE version of Axiom, I've been looking at questions of=0A=
>>>>>>>> trust at all levels.=0A=
>>>>>>>>=0A=
>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a=0A=
>>>>>>>> trusted kernel through which all other computations must=0A=
>>>>>>>> pass. Coq, Lean, and other systems do this. They base=0A=
>>>>>>>> their kernel  on logic like the Calculus of Construction or=0A=
>>>>>>>> something similar.=0A=
>>>>>>>>=0A=
>>>>>>>> Andrej Bauer has been working on a smaller kernel (a=0A=
>>>>>>>> nucleus) that separates the trust from the logic. The rules=0A=
>>>>>>>> for the logic can be specified as needed but checked by=0A=
>>>>>>>> the nucleus code.=0A=
>>>>>>>>=0A=
>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)=0A=
>>>>>>>> that allow you to create your own hardware in a C-like=0A=
>>>>>>>> language (Verilog). It allows you to check the chip you build=0A=
>>>>>>>> all the way down to the transistor states. You can create=0A=
>>>>>>>> things as complex as a whole CPU or as simple as a trusted=0A=
>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a=0A=
>>>>>>>> history of verifying hardware logic.=0A=
>>>>>>>>=0A=
>>>>>>>> It appears that, assuming I can understand Bauers=0A=
>>>>>>>> Andromeda system, it would be possible and not that hard=0A=
>>>>>>>> to implement a trusted kernel on an FPGA the size and=0A=
>>>>>>>> form factor of a USB stick.=0A=
>>>>>>>>=0A=
>>>>>>>> Trust "down to the metal".=0A=
>>>>>>>>=0A=
>>>>>>>> Tim=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>> Progress in happening on the new Sane Axiom compiler.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Recently I've been musing about methods to insert axioms=0A=
>>>>>>>>> into categories so they could be inherited like signatures.=0A=
>>>>>>>>> At the moment I've been thinking about adding axioms in=0A=
>>>>>>>>> the same way that signatures are written, adding them to=0A=
>>>>>>>>> the appropriate categories.=0A=
>>>>>>>>>=0A=
>>>>>>>>> But this is an interesting design question.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Axiom already has a mechanism for inheriting signatures=0A=
>>>>>>>>> from categories. That is, we can bet a plus signature from,=0A=
>>>>>>>>> say, the Integer category.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Suppose we follow the same pattern. Currently Axiom=0A=
>>>>>>>>> inherits certain so-called "attributes", such as=0A=
>>>>>>>>> ApproximateAttribute,=0A=
>>>>>>>>> which implies that the results are only approximate.=0A=
>>>>>>>>>=0A=
>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive=0A=
>>>>>>>>> property by defining it in its own category. In fact, if we=0A=
>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,=0A=
>>>>>>>>> where each property has its own inheritable category,=0A=
>>>>>>>>> we can "mix and match" the axioms at will.=0A=
>>>>>>>>>=0A=
>>>>>>>>> An "axiom" category would also export a function. This function=
=0A=
>>>>>>>>> would essentially be a "tactic" used in a proof. It would modify=
=0A=
>>>>>>>>> the proof step by applying the function to the step.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Theorems would have the same structure.=0A=
>>>>>>>>>=0A=
>>>>>>>>> This allows theorems to be constructed at run time (since=0A=
>>>>>>>>> Axiom supports "First Class Dynamic Types".=0A=
>>>>>>>>>=0A=
>>>>>>>>> In addition, this design can be "pushed down" into the Spad=0A=
>>>>>>>>> language so that Spad statements (e.g. assignment) had=0A=
>>>>>>>>> proof-related properties. A range such as [1..10] would=0A=
>>>>>>>>> provide explicit bounds in a proof "by language definition".=0A=
>>>>>>>>> Defining the logical properties of language statements in=0A=
>>>>>>>>> this way would make it easier to construct proofs since the=0A=
>>>>>>>>> invariants would be partially constructed already.=0A=
>>>>>>>>>=0A=
>>>>>>>>> This design merges the computer algebra inheritance=0A=
>>>>>>>>> structure with the proof of algorithms structure, all under=0A=
>>>>>>>>> the same mechanism.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Tim=0A=
>>>>>>>>>=0A=
>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent=0A=
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.ke=
nt.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKr=
kZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOID=
fXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5xsNk=
1_eii0&e=3D ) on=0A=
>>>>>>>>>> Seven deadly sins of talking about =93types=94=0A=
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.ke=
nt.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62fTb=
qv-K98dBQv0oMmB82kE8mXo&e=3D=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> He raised an interesting idea toward the end of the essay=0A=
>>>>>>>>>> that type-checking could be done outside the compiler.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.=0A=
>>>>>>>>>> It would be possible to run a program over the source code=0A=
>>>>>>>>>> to collect the information and write a stand-alone type=0A=
>>>>>>>>>> checker. This "unbundles" type checking and compiling.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Taken further I can think of several other kinds of checkers=0A=
>>>>>>>>>> (aka 'linters') that could be unbundled.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> It is certainly something to explore.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Tim=0A=
>>>>>>>>>>=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer=0A=
>>>>>>>>>>> blows of reality", to coin a phrase.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> There are many goals. One of the primary goals is creating a=0A=
>>>>>>>>>>> compiler that can be understood, maintained, and modified.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> So the latest changes involved adding multiple index files.=0A=
>>>>>>>>>>> These are documentation (links to where terms are mentioned=0A=
>>>>>>>>>>> in the text), code (links to the implementation of things),=0A=
>>>>>>>>>>> error (links to where errors are defined), signatures (links to=
=0A=
>>>>>>>>>>> the signatures of lisp functions), figures (links to figures),=
=0A=
>>>>>>>>>>> and separate category, domain, and package indexes.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"=0A=
>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of=0A=
>>>>>>>>>>> those diagrams follows immediately. Collectively these will=0A=
>>>>>>>>>>> eventually define at least the syntax of the language. In the=
=0A=
>>>>>>>>>>> ideal, changing the diagram would change the code but I'm=0A=
>>>>>>>>>>> not that clever.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Reality shows up with the curent constraint that the=0A=
>>>>>>>>>>> compiler should accept the current Spad language as=0A=
>>>>>>>>>>> closely as possible. Of course, plans are to include new=0A=
>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)=0A=
>>>>>>>>>>> but these are being postponed until "syntax complete".=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> All parse information is stored in a parse object, which=0A=
>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)=0A=
>>>>>>>>>>> Fields within the parse object, e.g. variables are also=0A=
>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).=0A=
>>>>>>>>>>> It's types all the way down.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> These types are being used as 'signatures' for the=0A=
>>>>>>>>>>> lisp functions. The goal is to be able to type-check the=0A=
>>>>>>>>>>> compiler implementation as well as the Sane language.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> The parser is designed to "wrap around" so that the=0A=
>>>>>>>>>>> user-level output of a parse should be the user-level=0A=
>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"=0A=
>>>>>>>>>>> should make it easy to see that the parser properly=0A=
>>>>>>>>>>> parsed the user input.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> The parser is "first class" so it will be available at=0A=
>>>>>>>>>>> runtime as a domain allowing Spad code to construct=0A=
>>>>>>>>>>> Spad code.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> One plan, not near implementation, is to "unify" some=0A=
>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How=0A=
>>>>>>>>>>> this will happen is still in the land of design. This would=0A=
>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is=0A=
>>>>>>>>>>> really just a domain-specific language in lisp. Lisp=0A=
>>>>>>>>>>> functions (with CLOS types as signatures) would be=0A=
>>>>>>>>>>> avaiable for implementing Spad functions. This not=0A=
>>>>>>>>>>> only improves the efficiency, it would make the=0A=
>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.=0A=
>>>>>>>>>>> .=0A=
>>>>>>>>>>> On the theory front I plan to attend the Formal Methods=0A=
>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to=0A=
>>>>>>>>>>> know how little I know, especially that I need to know.=0A=
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.andre=
w.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6In=
oLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=
=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx-3=
GFVk62hxr53YKr4naRk&e=3D=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:=0A=
>>>>>>>>>>>> The underlying technology to use for building such an algebra=
=0A=
>>>>>>>>>>>> library=0A=
>>>>>>>>>>>> is=0A=
>>>>>>>>>>>> documented in the paper " Building on the Diamonds between=0A=
>>>>>>>>>>>> Theories:=0A=
>>>>>>>>>>>> Theory Presentation Combinators"=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.cas.=
mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkx=
c&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryVeFo=
Bjl0AZs2cuQZhKuIxk8NUw&e=3D=0A=
>>>>>>>>>>>> [which=0A=
>>>>>>>>>>>> will=0A=
>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a=0A=
>>>>>>>>>>>> journal].=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> There is a rather full-fledged prototype, very well documented=
=0A=
>>>>>>>>>>>> at=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhassy=
.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html&d=
=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWE=
VPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDz=
gkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> (source at https://urldefense.proofpoint.com/v2/url?u=3Dhttps-=
3A__github.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZ=
G3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZ=
vTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP=
2l23mZBB5fBQOj0-Q48CUKRS1VNLao&e=3D ).=0A=
>>>>>>>>>>>> It=0A=
>>>>>>>>>>>> is=0A=
>>>>>>>>>>>> literate source.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> The old prototype was hard to find - it is now at=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.=
com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVK=
rkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOI=
DfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITFQRp=
kFBgg8c&e=3D .=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> There is also a third prototype in the MMT system, but it does=
=0A=
>>>>>>>>>>>> not=0A=
>>>>>>>>>>>> quite=0A=
>>>>>>>>>>>> function properly today, it is under repair.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"=0A=
>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhass=
y.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5Ffe=
ature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkx=
c&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0zit=
s8pEczWsib7Q7_mxyRIxhk&e=3D )=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized=0A=
>>>>>>>>>>>> theories=0A=
>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all curren=
t=0A=
>>>>>>>>>>>> systems=0A=
>>>>>>>>>>>> suffer from.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Jacques=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:=0A=
>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas=0A=
>>>>>>>>>>>>> algebra code. The compiler knows about the language but=0A=
>>>>>>>>>>>>> does not depend on the algebra library (so far). It should be=
=0A=
>>>>>>>>>>>>> possible, by design, to load different algebra towers.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"=0A=
>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much=0A=
>>>>>>>>>>>>> finer grain separation of algebra and axioms.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> This "flexible algebra" design would allow things like the=0A=
>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports=0A=
>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Another possible design choice is to target the GNU=0A=
>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just=0A=
>>>>>>>>>>>>>> another front-end language" supported by GCC.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> The current intermediate representation does not (yet)=0A=
>>>>>>>>>>>>>> make any decision about the runtime implementation.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") developed=
=0A=
>>>>>>>>>>>>>>> a dependently typed general parser for context free grammar=
=0A=
>>>>>>>>>>>>>>> in Coq.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> They used the parser to prove its own completeness.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.=0A=
>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider=0A=
>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Tim=0A=

\start
Date: Sun, 19 Jul 2020 17:33:47 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>
Subject: Re: [EXTERNAL] Re: Axiom musings...

There are several "problems" with proving programs correct that
I don't quite know how to solve, or even approach. But that's the
fun of "research", right?

For the data representation question I've been looking at types.
I took 10 courses at CMU. I am eyebrow deep in type theory.
I'm looking at category theory and homotopy type theory. So
far I haven't seen anyone looking at the data problem. Most of
the focus is on strict code typing.

There is an old MIT course by Abelson and Sussman "Structure
and Interpretation of Computer Programs" (SICP). They rewrite
data as programs which, in Lisp, is trivial to do, Dan Friedman
seems to have some interesting ideas too.

All of Axiom's SANE types are now CLOS objects which gives
two benefits. First, they can be inherited. But second, they
are basically Lisp data structures with associated code.

I'm thinking of associating "data axioms" with the representation
(REP) object of a domain as well as with the functions.

For example, DenavitHartenbergMatrix encodes 4x4 matrices
used in graphics and robotics. They are 4x4 matrices where
the upper left 3x3 encodes rotations, the right column encodes
translations, and the lower row includes scaling, skewing, etc.

(As an aside, DHMATRIX matrices have an associated
Jacobian which encodes the dynamics in things like robots.
Since I'm also programming a robot I'm tempted to work on
extending the domain with related functions... but, as
Hamming said, new algebra code isn't "the most important
problem in computational mathematics").

Axioms associated with the REP can assume that they are
4x4, that they can be inverted, that they have a "space" of
rotations, etc. The axioms provide "facts" known to be true
about the REP. (I also need to think about a "specification"
for the REP but I'm not there yet).

Since every category and domain is a CLOS data structure
the DHMATRIX data structure inherits REP axioms from its
inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX
adds domain-specific REP axioms (as well as domain-specific
function axioms). Thus a DHMATRIX rotate function can
base its proof on the fact that it only affects the upper 3x3
and lives in a space of rotations, all of which can be assumed
by the proof.

If I use the SICP "trick" of representing data as code I can
"expand" the data as part of the program proof.

It is all Omphaloskepsis (navel gazing) at this point though.
I'm still writing the new SANE compiler (which is wildly
different from the compiler course I taught).

I did give a talk at Notre Dame but I haven't attempted to
publish. All of my work shows up in literate programming
Axiom books on github.
(https://github.com/daly/PDFS)

It is all pretty pointless since nobody cares about computer
algebra, proving math programs correct, or Axiom itself.
Wolfram is taking up all the oxygen in the discussions.

But I have to say, this research is great fun. It reminds me
of the Scratchpad days, although I miss the give-and-take
of the group. It is hard to recreate my role as the dumbest
guy in the room when I'm stuck here by myself :-)

Hope you and your family are safe and healthy.

Tim

PS. I think we should redefine the "Hamming Distance" as
the distance between an idea and its implementation.



On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:
> Hi Tim:
>
> Glad to hear from you now and then, promoting and working towards your id=
eas
> and ideals.
>
>  >>We need proven algorithms.
>
> Just one short comment: it is often possible to prove algorithms (that is=
,
> providing the theoretical foundation for the algorithm), but it is much
> harder to prove that an implementation of the algorithm is correct. As yo=
u
> well know, the distinction lies in that implementation involves data
> representations whereas proofs of algorithms normally ignore them.
> Introducing (finite) data representations means introducing boundary
> situations that a programmer implementing an algorithm must deal with. So
> perhaps what we need to prove should include the correctness of
> implementations (to the bare metal, as you often say) and we should have =
a
> different set of analytic tools that can deal with the correctness (or
> completeness) of data representations. Of course, these tools must also b=
e
> proven with the same rigor since behind every program is an algorithm.
>
> William
>
> William Sit
> Professor Emeritus
> Department of Mathematics
> The City College of The City University of New York
> New York, NY 10031
> homepage: wsit.ccny.cuny.edu
>
> ________________________________________
> From: Axiom-developer
> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behalf =
of
> Tim Daly <axiomcas@gmail.com>
> Sent: Saturday, July 18, 2020 6:28 PM
> To: axiom-dev; Tim Daly
> Subject: [EXTERNAL] Re: Axiom musings...
>
> Richard Hamming gave a great talk. "You and Your Research"
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_wa=
tch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwt=
IMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX=
0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0U&=
e=3D
>
> His big question is:
>
> "What is the most important problem in your field
> and why aren't you working on it?"
>
> To my mind, the most important problem in the field of
> computational mathematics is grounding computer
> algebra in proofs.
>
> Computer mathematical algorithms that "maybe,
> possibly, give correct answers sometimes" is a problem.
> Indeed, for computer algebra, it is the most important
> problem. We need proven algorithms.
>
> New algorithms, better graphics, better documentation,
> are all "nice to have" but, as Hamming would say,
> they are not "the most important problem".
>
> Tim
>
>
>
> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
>> Time for another update.
>>
>> The latest Intel processors, available only to data centers
>> so far, have a built-in FPGA. This allows you to design
>> your own circuits and have them loaded "on the fly",
>> running in parallel with the CPU.
>>
>> I bought a Lattice ICEstick FPGA development board. For
>> the first time there are open source tools that support it so
>> it is a great test bench for ideas and development. It is a
>> USB drive so it can be easily ported to any PC.
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesemi.=
com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQz2=
HFhAAAymG-QswIjRao_YTwz4&e=3D
>> )
>>
>> I also bought a large Intel Cyclone FPGA development board.
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com.t=
w_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=3D=
4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79Pd=
SWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW6Bu=
eAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D
>> )
>> which has 2 embedded ARM processors. Unfortunately
>> the tools (which are freely available) are not open source.
>> It has sufficient size and power to do anything.
>>
>>
>> I've got 2 threads of work in progress, both of which
>> involve FPGAs (Field Programmable Gate Arrays).
>>
>> Thread 1
>>
>> The first thread involves proving programs correct. Once
>> a proof has been made it is rather easier to check the proof.
>> If code is shipped with a proof, the proof can be loaded into
>> an FPGA running a proof-checker which verifies the program
>> in parallel with running the code on the CPU.
>>
>> I am researching the question of writing a proof checker that
>> runs on an FPGA, thus verifying the code "down to the metal".
>> The Lean proof checker is the current target.
>>
>> The idea is to make "Oracle" algorithms that, because they
>> are proven correct and verified at runtime, can be trusted
>> by other mathematical software (e.g. Lean, Coq, Agda)
>> when used in proofs.
>>
>> Thread 2
>>
>>
>> The second thread involves arithmetic. Axiom currently ships
>> with numeric routines (BLAS and LAPACK, see bookvol10.5).
>> These routines have a known set of numeric failures such as
>> cancellation, underflow, and scaling.
>>
>> John Gustafson has designed a 'unum' numeric format that can
>> eliminate many of these errors. (See
>> Gustafson, John "The End of Error" CRC Press 2015
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_En=
d-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F1-=
5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D15=
93685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwt=
IMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX=
0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0A&=
e=3D
>> )
>>
>> The research goal is to implement Axiom's floating-point
>> arithmetic that can be offloaded onto an FPGA implementing
>> the unum format. Such a system would radically simplify
>> the implementation of BLAS and LAPACK as most of the
>> errors can't occur. The impact would be similar to using
>> multi-precision integer arithmetic, only now its floating-point.
>>
>> SANE, the greater goal.
>>
>> The Axiom SANE compiler / interpreter can use both of
>> these tools to implement trusted mathematical software.
>> It's a long, ambitious research effort but even if only pieces
>> of it succeed, it changes computational mathematics.
>>
>> Tim
>>
>> "A person's reach should exceed their grasp,
>> or what's a computer for?"  (misquoting Robert Browning)
>>
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.com=
_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexceed=
-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_Oq=
sfcYl4z14qlYS02TBNmnaHUY&e=3D
>> )
>>
>>
>>
>>
>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>>> WHY PROVE AXIOM CORRECT (SANE)?
>>>
>>> Historically, Axiom credits CLU, the Cluster language by
>>> Barbara Liskov, with the essential ideas behind the Spad
>>> language. Barbara gave a talk (a partial transcript below)
>>> that gives the rational behind the ``where clause'' used by
>>> Spad.
>>>
>>> She talks about the limits of the compile time capablity.
>>> In particular, she says:
>>>
>>>    To go further, where we would say that T,
>>>    in addition, has to be an equality relation, that requires
>>>    much more sophisticated techniques that, even today, are
>>>    beyond the capabilities of the compiler.
>>>
>>> Showing that the ``equal'' function satisfies the equality
>>> relation is no longer ``beyond the capabilities of the compiler''.
>>> We have the required formalisms and mechanisms to
>>> prove properties at compile time.
>>>
>>> The SANE effort is essentially trying to push compile
>>> time checking into proving that, for categories that use
>>> ``equal'', we prove that the equal function implements
>>> equality.
>>>
>>> I strongly encourage you to watch her video.
>>>
>>> Tim
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> Barbara Liskov
>>> May 2012
>>> MIT CSAIL
>>> Programming the Turing Machine
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_=
watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZe=
PX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1eG=
Y&e=3D
>>>
>>> POLYMORPHISM
>>>
>>> We don't just want a set, we want polymorphism or
>>> generics, as they are called today. We wanted to
>>> have a generic set which was paramaterized by type
>>> so you could instantiate it as:
>>>
>>> Set =3D [T:type] create, insert,...
>>>   % representation for Set object
>>>   % implementation of Set operations
>>>   Set
>>>
>>> Set[int] s :=3D Set[int]$create()
>>> Set[int]$insert(s,3)
>>>
>>> We wanted a static solution to this problem. The
>>> problem is, not every type makes sense as a parameter
>>> to Set of T. For sets, per se, you need an equality
>>> relation. If it has been a sorted set we would have
>>> some ordering relation. And a type that didn't have
>>> one of those things would not have been a legitimate
>>> parameter. We needed a way of expressing that in a
>>> compile-time, checkable manner. Otherwise we would
>>> have had to resort to runtime checking.
>>>
>>> Our solution was
>>>
>>> Set =3D [T:  ] create, insert,...
>>>   T equal: (T,T) (bool)
>>>
>>>
>>> Our solution, what we call the ``where clause''. So we
>>> added this to the header. The ``where clause'' tells you
>>> what operations the parameter type has to have.
>>>
>>> If you have the ``where'' clause you can do the static
>>> checking because when you instantiate, when you provide
>>> an actual type, the compiler can check that the type has
>>> the operations that are required. And then, when you write
>>> the implementation of Set the compiler knows it's ok to
>>> call those operations because you can guarantee they are
>>> actually there when you get around to running.
>>>
>>> Of course, you notice that there's just syntax here; there's
>>> no semantics.
>>>
>>> As I'm sure you all know, compile-time type checking is
>>> basically a proof technique of a very limited sort and
>>> this was about as far as we can push what you could get out of the
>>> static analysis. To go further, where we would say that T,
>>> in addition, has to be an equality relation, that requires
>>> much more sophisticated techniques that, even today, are
>>> beyond the capabilities of the compiler.
>>>
>>>
>>>
>>>
>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>> I've spent entirely too much time studing the legal issues
>>>> of free and open source software. There are copyright,
>>>> trademark, and intellectual property laws. I have read
>>>> several books, listened to lectures, and read papers on
>>>> the subject. I've spoken to lawyers about it. I've even
>>>> been required, by law, to coerce people I respect.
>>>> You would think it was all perfectly clear. It isn't.
>>>>
>>>> The most entertaining and enlightening lectures were
>>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>>> "The Semasiology of Open Source", which sounds
>>>> horrible but I assure you, this is a real treat.
>>>>
>>>> THE THESIS
>>>>
>>>> Semasiology, n. The science of meanings or
>>>> sense development (of words); the explanation
>>>> of the development and changes of the meanings
>>>> of words. Source: Webster's Revised Unabridged
>>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>>
>>>> "Open source doesn't just mean access to the
>>>> source code." So begins the Open Source Definition.
>>>> What then, does access to the source code mean?
>>>> Seen through the lens of an Enterprise user, what
>>>> does open source mean? When is (or isn't) it
>>>> significant? And a catalogue of open source
>>>> related arbitrage opportunities.
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversat=
ionsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520of=
-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnEbu=
sM&e=3D
>>>>
>>>> Computer source code has words and sentence
>>>> structure like actual prose or even poetry. Writing
>>>> code for the computer is like writing an essay. It
>>>> should be written for other people to read,
>>>> understand and modify. These are some of the
>>>> thoughts behind literate programming proposed
>>>> by Donald Knuth. This is also one of the ideas
>>>> behind Open Source.
>>>>
>>>>  THE ANTITHESIS
>>>>
>>>> "Open Source" is a phrase like "Object Oriented"
>>>> - weird at first, but when it became popular, the
>>>> meaning began to depend on the context of the
>>>> speaker or listener. "Object Oriented" meant that
>>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>>> version of Cobol are all "Object Oriented" - for some
>>>> specific definition of "Object Oriented". Similar is
>>>> the case of the phrase "Open Source".
>>>>
>>>> In Part I, Lefkowitz talked about the shift of the
>>>> meaning of "Open Source" away from any reference
>>>> to the actual "source code," and more towards other
>>>> phases of the software development life cycle. In
>>>> Part II, he returns to the consideration of the
>>>> relationship between "open source" and the actual
>>>> "source code," and reflects upon both the way
>>>> forward and the road behind, drawing inspiration
>>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>>> and others.
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversat=
ionsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DLTg=
LxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D
>>>>
>>>> THE SYNTHESIS
>>>>
>>>> In a fascinating synthesis, Robert =E2=80=9Cr0ml=E2=80=9D Lefkowitz
>>>> polishes up his exposition on the evolving meaning
>>>> of the term =E2=80=98open source=E2=80=99. This intellectual joy-ride
>>>> draws on some of the key ideas in artificial intelligence
>>>> to probe the role of language, meaning and context
>>>> in computing and the software development process.
>>>> Like Wittgenstein=E2=80=99s famous thought experiment, the
>>>> open source =E2=80=98beetle in a box=E2=80=99 can represent different
>>>> things to different people, bearing interesting fruit for
>>>> philosophers and software creators alike.
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversation=
snetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4Nmam=
NZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRx=
NZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIwON=
-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D
>>>>
>>>>
>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>>> so far, is to push once a month on the 7th.
>>>>>
>>>>> After some chat room interactions it was brought home
>>>>> again that the proof world really does not seem to like the
>>>>> idea of proving programs correct. And, given that it was is
>>>>> of the main Axiom goals and a point of friction during the fork,
>>>>> the computer algebra world does not like the idea of proving
>>>>> programs correct either.
>>>>>
>>>>> So the idea of "computational mathematics", which includes
>>>>> both disciplines (as well as type theory) seems still a long
>>>>> way off.
>>>>>
>>>>> Nevertheless, the primary change in these past and future
>>>>> updates is focused on merging proof and computer algebra.
>>>>>
>>>>> Proof systems are able to split the problem of creating a
>>>>> proof and the problem of verifying a proof, which is much
>>>>> cheaper. Ideally the proof checker would run on verified
>>>>> hardware so the proof is checked "down to the metal".
>>>>>
>>>>> I have a background in Field Programmable Gate Arrays
>>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>>> looking at creating a hardware proof checker using a
>>>>> dedicated instruction set, one designed to be verifed.
>>>>> New CPUs used in data centers (not yet available to us
>>>>> mortals) have built-in FPGAs so it would be possible to
>>>>> "side-load" a proof of a program to be checked while the
>>>>> program is run. I have the FPGA and am doing a gate-level
>>>>> special instruction design for such a proof checker.
>>>>>
>>>>>
>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>>> mostly because it keeps muttering about Types. If you're not
>>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>>> seems pointless and painful.
>>>>>>
>>>>>> So Axiom has a steep learning curve.
>>>>>>
>>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>>> to use a system like Axiom, mostly because you have to find
>>>>>> or create "domains" or "packages", understand categories
>>>>>> with their inheritance model, and learn a new language with
>>>>>> a painful compiler always complaining about types.
>>>>>>
>>>>>> So Axiom has a steep learning curve.
>>>>>>
>>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>>> It also assumes a background in type theory, inductive logic,
>>>>>> homotopy type theory, ML (meta-language, not machine
>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>>> and tacticals. Also assumed is knowledge of specification languages,
>>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>>> libraries of the same.
>>>>>>
>>>>>> So Axiom Sane has a steep learning curve.
>>>>>>
>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>>> learning to read the leading edge literature (also known
>>>>>> as "greek studies", since every paper has pages of greek).
>>>>>>
>>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>>> "computational mathematics" framework. I suspect that the only
>>>>>> way this system will ever be useful is after Universities have a
>>>>>> "Computational Mathematics" major course of study and degree.
>>>>>>
>>>>>> Creating a new department is harder than creating Axiom Sane
>>>>>> because, you know, ... people.
>>>>>>
>>>>>> I think such a department is inevitable given the deep and wide
>>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>>> started programming there was no computer science degree.
>>>>>>
>>>>>> Somebody has to be the first lemming over the cliff.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>>> there is a certain amount of verification that is involved.
>>>>>>>
>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>>>> computationally more efficient if Axiom and Lean use a cryptographi=
c
>>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be
>>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>>> computation request from Lean might involve many algorithms
>>>>>>> there would be considerable overhead to recompute each proof.
>>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>>
>>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>>> information about the domain and range of a resulting formula.
>>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>>> SuchThat domain).
>>>>>>>>
>>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>>> information is difficult if not impossible in the current system.
>>>>>>>> The information isn't available and isn't computed. In that sense,
>>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>>
>>>>>>>> In the Sane implementation the information is available. It is
>>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>>> careful design it will be possible to provide provisos for each
>>>>>>>> given result that are carried with the result for use in further
>>>>>>>> computation.
>>>>>>>>
>>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>>> if the formula is defined over an interval, how is the interval
>>>>>>>> arithmetic handled?
>>>>>>>>
>>>>>>>> Exciting research ahead!
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>>
>>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>>> trust at all levels.
>>>>>>>>>
>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>>> trusted kernel through which all other computations must
>>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>>> something similar.
>>>>>>>>>
>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>>> the nucleus code.
>>>>>>>>>
>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>>> history of verifying hardware logic.
>>>>>>>>>
>>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>>> form factor of a USB stick.
>>>>>>>>>
>>>>>>>>> Trust "down to the metal".
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>>
>>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>>> the appropriate categories.
>>>>>>>>>>
>>>>>>>>>> But this is an interesting design question.
>>>>>>>>>>
>>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>>> say, the Integer category.
>>>>>>>>>>
>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>>> ApproximateAttribute,
>>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>>
>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>>
>>>>>>>>>> An "axiom" category would also export a function. This function
>>>>>>>>>> would essentially be a "tactic" used in a proof. It would modify
>>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>>
>>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>>
>>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>>
>>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>>
>>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>>> the same mechanism.
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.k=
ent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVK=
rkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOI=
DfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5xsN=
k1_eii0&e=3D
>>>>>>>>>>> ) on
>>>>>>>>>>> Seven deadly sins of talking about =E2=80=9Ctypes=E2=80=9D
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.k=
ent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62fT=
bqv-K98dBQv0oMmB82kE8mXo&e=3D
>>>>>>>>>>>
>>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>>
>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>>
>>>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>>
>>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>>
>>>>>>>>>>>> There are many goals. One of the primary goals is creating a
>>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>>
>>>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>>>> error (links to where errors are defined), signatures (links t=
o
>>>>>>>>>>>> the signatures of lisp functions), figures (links to figures),
>>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>>
>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>>>> eventually define at least the syntax of the language. In the
>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>>> not that clever.
>>>>>>>>>>>>
>>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>>
>>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>>
>>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>>
>>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>>
>>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>>> Spad code.
>>>>>>>>>>>>
>>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>>
>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>>> .
>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.andr=
ew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6I=
noLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=
=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx-3=
GFVk62hxr53YKr4naRk&e=3D
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>>> The underlying technology to use for building such an algebra
>>>>>>>>>>>>> library
>>>>>>>>>>>>> is
>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>>>> Theories:
>>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.cas=
.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryVeF=
oBjl0AZs2cuQZhKuIxk8NUw&e=3D
>>>>>>>>>>>>> [which
>>>>>>>>>>>>> will
>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a
>>>>>>>>>>>>> journal].
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is a rather full-fledged prototype, very well documente=
d
>>>>>>>>>>>>> at
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhass=
y.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html&d=
=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWE=
VPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDz=
gkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D
>>>>>>>>>>>>>
>>>>>>>>>>>>> (source at
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github=
.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6=
InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&=
m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZBB5f=
BQOj0-Q48CUKRS1VNLao&e=3D
>>>>>>>>>>>>> ).
>>>>>>>>>>>>> It
>>>>>>>>>>>>> is
>>>>>>>>>>>>> literate source.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github=
.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqO=
IDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITFQR=
pkFBgg8c&e=3D
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it doe=
s
>>>>>>>>>>>>> not
>>>>>>>>>>>>> quite
>>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhas=
sy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5Ff=
eature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0zi=
ts8pEczWsib7Q7_mxyRIxhk&e=3D
>>>>>>>>>>>>> )
>>>>>>>>>>>>>
>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>>>> theories
>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all curre=
nt
>>>>>>>>>>>>> systems
>>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas
>>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>>> does not depend on the algebra library (so far). It should b=
e
>>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This "flexible algebra" design would allow things like the
>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") developed
>>>>>>>>>>>>>>>> a dependently typed general parser for context free gramma=
r
>>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim

\start
Date: Mon, 20 Jul 2020 13:30:45 +0000
From: William Sit <wsit@ccny.cuny.edu>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [EXTERNAL] Re: Axiom musings...
Message-ID: <1595251845196.15576@ccny.cuny.edu>
References: <CAJn5L=+FGXs0XSYpAfk3SeoRhK-D4mZxWUojfmpXvp_Ny2E3MQ@mail.gmail.com>
 <CAJn5L=J-8MWFVwFBvHgaoXg49oGGRwnYhFcCCABcYXDCAaHyKQ@mail.gmail.com>
 <CAJn5L=+svkt9-g9Qft+FGYQkiStcgGjmAuEVxdYw1KQTN=3gxQ@mail.gmail.com>
 <f857bc83-2061-68f0-c53b-f5418de48313@mcmaster.ca>
 <CAJn5L=J5kiV3Lr1smRj47B4v6sPxpbX1z2fVDCZQdxFMx+4RAw@mail.gmail.com>
 <CAJn5L=Jr0QhJ4+9H977jECaet0BLLoCZ=SE9=19zuywHaMxDcg@mail.gmail.com>
 <CAJn5L=LZOLgZDgsZvP9he-=rjKHtGbE33xAjLtnzPO8+k2ntPQ@mail.gmail.com>
 <CAJn5L=LNcKHbeJpvk2Ek5eqSb+QFzhUJrfdAat7tdjJ=8DDGNQ@mail.gmail.com>
 <CAJn5L=+b6wqKnyViMsxOQRpSFR5L5eidSteH42mTOraGGiNYoA@mail.gmail.com>
 <CAJn5L=JSbNN43eZt7JGKbp9kxE8S-OBrLpziNPMfBDixG3P3rQ@mail.gmail.com>
 <CAJn5L=Lv3yPam3k3cavTkP0-ArLz6_w8N3Tew_B_y+fir9SZ+g@mail.gmail.com>
 <CAJn5L=+sFUCScX92VmLgWMBAu==epZy9hbV5f7QJda-3jbRAHw@mail.gmail.com>
 <CAJn5L=LDgfvMN3G=1A7zBu8MYZLezkKjKD3F6Vy7Laent3m-ZA@mail.gmail.com>
 <CAJn5L=J=iztMK1B1LqM8obqfOb_QQKWhEx9GLn=d25v7L9AXWg@mail.gmail.com>
 <CAJn5L=KCdmfwnZNdD9BCK=sK1x0J=s+Cb5bixbcpX1KnVkmQCg@mail.gmail.com>
 <CAJn5L=Kwb3EKXU6SK93hmZkznEDpSWMNnJgqj-ueuMt54_FCOw@mail.gmail.com>
 <1595175684369.31200@ccny.cuny.edu>,
 <CAJn5L=K3GnetNHnfcMRZ76hmVOS3bwkYU9qUdMSx8psz9Am3qw@mail.gmail.com>
In-Reply-To: <CAJn5L=K3GnetNHnfcMRZ76hmVOS3bwkYU9qUdMSx8psz9Am3qw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [134.74.99.235]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687
 definitions=2020-07-20_09:2020-07-20,
 2020-07-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 spamscore=0
 mlxscore=0 suspectscore=0 priorityscore=1501 adultscore=0
 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 malwarescore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2006250000 definitions=main-2007200094
Received-SPF: pass client-ip=134.74.98.56; envelope-from=wsit@ccny.cuny.edu;
 helo=ppsf02.ccny.cuny.edu
X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/20 09:30:49
X-ACL-Warn: Detected OS   = Linux 3.x [generic] [fuzzy]
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: axiom-developer@nongnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Axiom Developers <axiom-developer.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/axiom-developer>, 
 <mailto:axiom-developer-request@nongnu.org?subject=unsubscribe>
List-Archive: <https://lists.nongnu.org/archive/html/axiom-developer>
List-Post: <mailto:axiom-developer@nongnu.org>
List-Help: <mailto:axiom-developer-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/axiom-developer>,
 <mailto:axiom-developer-request@nongnu.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2020 13:30:55 -0000

Hi Tim:=0A=
=0A=
Perhaps I did not make myself clear in the short comment.=0A=
What I wanted to say is that a data representation is not the same as the a=
bstract mathematical objects because there are finite bounds on the represe=
ntation. Take for example, an algorithm to compute the LCM of two integers.=
 The LCM can cause overflow and not be representable. Of course, you can ch=
ange the data representation to have "infinite precision", but that would s=
till be bounded by actual physical memory of the machine. The careful progr=
ammer of the LCM algorithm would add throws and catches to handle the "erro=
r",but the implementation will have to add code that is not considered in t=
he theoretical LCM algorithm (unless the LCM algorithm is meant for bounded=
 integers of a fixed data representation and not abstract integers). So the=
re are two kinds of algorithms, one that is purely mathematical and one tha=
t is computational, the latter including a particular (class of) data repre=
sentation(s) (perhaps even the computer language and system of the implemen=
tation). It is proofs for the latter type of algorithms that is lacking. Si=
nce data representations (like REP in Axiom) are built recursively, a compu=
tational algorithm (in the sense above) for Groebner basis may have to be d=
esigned to take care of just a few of the ways integers can be represented.=
 Axiom is built with that in mind (that's where type theory comes in), but =
I bet no one SPECIFIES their computational algorithms with the limitations =
of data representation in mind, much less proves the algorithm anew for eac=
h new representation. So if a computation of a Groebner basis halts because=
 of an intermediate LCM computation (say of two integer coefficients), shou=
ld we consider the implementation as proven correct? What if the overflow c=
ondition was not detected and the computation continues? Indeed, since ther=
e may be different implementations of the integer domain, we must be sure t=
hat every implementation of the LCM algorithm handles overflows correctly A=
ND specified in the documentation.=0A=
=0A=
I am sure I am just being ignorant to pose these questions, because they mu=
st have been considered and perhaps solved. In that case, please ignore the=
m and just tell me so.=0A=
=0A=
William=0A=
=0A=
William Sit=0A=
Professor Emeritus=0A=
Department of Mathematics=0A=
The City College of The City University of New York=0A=
New York, NY 10031=0A=
homepage: wsit.ccny.cuny.edu=0A=
=0A=
________________________________________=0A=
From: Tim Daly <axiomcas@gmail.com>=0A=
Sent: Sunday, July 19, 2020 5:33 PM=0A=
To: William Sit=0A=
Cc: axiom-dev=0A=
Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
=0A=
There are several "problems" with proving programs correct that=0A=
I don't quite know how to solve, or even approach. But that's the=0A=
fun of "research", right?=0A=
=0A=
For the data representation question I've been looking at types.=0A=
I took 10 courses at CMU. I am eyebrow deep in type theory.=0A=
I'm looking at category theory and homotopy type theory. So=0A=
far I haven't seen anyone looking at the data problem. Most of=0A=
the focus is on strict code typing.=0A=
=0A=
There is an old MIT course by Abelson and Sussman "Structure=0A=
and Interpretation of Computer Programs" (SICP). They rewrite=0A=
data as programs which, in Lisp, is trivial to do, Dan Friedman=0A=
seems to have some interesting ideas too.=0A=
=0A=
All of Axiom's SANE types are now CLOS objects which gives=0A=
two benefits. First, they can be inherited. But second, they=0A=
are basically Lisp data structures with associated code.=0A=
=0A=
I'm thinking of associating "data axioms" with the representation=0A=
(REP) object of a domain as well as with the functions.=0A=
=0A=
For example, DenavitHartenbergMatrix encodes 4x4 matrices=0A=
used in graphics and robotics. They are 4x4 matrices where=0A=
the upper left 3x3 encodes rotations, the right column encodes=0A=
translations, and the lower row includes scaling, skewing, etc.=0A=
=0A=
(As an aside, DHMATRIX matrices have an associated=0A=
Jacobian which encodes the dynamics in things like robots.=0A=
Since I'm also programming a robot I'm tempted to work on=0A=
extending the domain with related functions... but, as=0A=
Hamming said, new algebra code isn't "the most important=0A=
problem in computational mathematics").=0A=
=0A=
Axioms associated with the REP can assume that they are=0A=
4x4, that they can be inverted, that they have a "space" of=0A=
rotations, etc. The axioms provide "facts" known to be true=0A=
about the REP. (I also need to think about a "specification"=0A=
for the REP but I'm not there yet).=0A=
=0A=
Since every category and domain is a CLOS data structure=0A=
the DHMATRIX data structure inherits REP axioms from its=0A=
inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX=0A=
adds domain-specific REP axioms (as well as domain-specific=0A=
function axioms). Thus a DHMATRIX rotate function can=0A=
base its proof on the fact that it only affects the upper 3x3=0A=
and lives in a space of rotations, all of which can be assumed=0A=
by the proof.=0A=
=0A=
If I use the SICP "trick" of representing data as code I can=0A=
"expand" the data as part of the program proof.=0A=
=0A=
It is all Omphaloskepsis (navel gazing) at this point though.=0A=
I'm still writing the new SANE compiler (which is wildly=0A=
different from the compiler course I taught).=0A=
=0A=
I did give a talk at Notre Dame but I haven't attempted to=0A=
publish. All of my work shows up in literate programming=0A=
Axiom books on github.=0A=
(https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly_PDF=
S&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR=
8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQIcLfv=
TFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D )=0A=
=0A=
It is all pretty pointless since nobody cares about computer=0A=
algebra, proving math programs correct, or Axiom itself.=0A=
Wolfram is taking up all the oxygen in the discussions.=0A=
=0A=
But I have to say, this research is great fun. It reminds me=0A=
of the Scratchpad days, although I miss the give-and-take=0A=
of the group. It is hard to recreate my role as the dumbest=0A=
guy in the room when I'm stuck here by myself :-)=0A=
=0A=
Hope you and your family are safe and healthy.=0A=
=0A=
Tim=0A=
=0A=
PS. I think we should redefine the "Hamming Distance" as=0A=
the distance between an idea and its implementation.=0A=
=0A=
=0A=
=0A=
On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
> Hi Tim:=0A=
>=0A=
> Glad to hear from you now and then, promoting and working towards your id=
eas=0A=
> and ideals.=0A=
>=0A=
>  >>We need proven algorithms.=0A=
>=0A=
> Just one short comment: it is often possible to prove algorithms (that is=
,=0A=
> providing the theoretical foundation for the algorithm), but it is much=
=0A=
> harder to prove that an implementation of the algorithm is correct. As yo=
u=0A=
> well know, the distinction lies in that implementation involves data=0A=
> representations whereas proofs of algorithms normally ignore them.=0A=
> Introducing (finite) data representations means introducing boundary=0A=
> situations that a programmer implementing an algorithm must deal with. So=
=0A=
> perhaps what we need to prove should include the correctness of=0A=
> implementations (to the bare metal, as you often say) and we should have =
a=0A=
> different set of analytic tools that can deal with the correctness (or=0A=
> completeness) of data representations. Of course, these tools must also b=
e=0A=
> proven with the same rigor since behind every program is an algorithm.=0A=
>=0A=
> William=0A=
>=0A=
> William Sit=0A=
> Professor Emeritus=0A=
> Department of Mathematics=0A=
> The City College of The City University of New York=0A=
> New York, NY 10031=0A=
> homepage: wsit.ccny.cuny.edu=0A=
>=0A=
> ________________________________________=0A=
> From: Axiom-developer=0A=
> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behalf =
of=0A=
> Tim Daly <axiomcas@gmail.com>=0A=
> Sent: Saturday, July 18, 2020 6:28 PM=0A=
> To: axiom-dev; Tim Daly=0A=
> Subject: [EXTERNAL] Re: Axiom musings...=0A=
>=0A=
> Richard Hamming gave a great talk. "You and Your Research"=0A=
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_wa=
tch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwt=
IMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX=
0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0U&=
e=3D=0A=
>=0A=
> His big question is:=0A=
>=0A=
> "What is the most important problem in your field=0A=
> and why aren't you working on it?"=0A=
>=0A=
> To my mind, the most important problem in the field of=0A=
> computational mathematics is grounding computer=0A=
> algebra in proofs.=0A=
>=0A=
> Computer mathematical algorithms that "maybe,=0A=
> possibly, give correct answers sometimes" is a problem.=0A=
> Indeed, for computer algebra, it is the most important=0A=
> problem. We need proven algorithms.=0A=
>=0A=
> New algorithms, better graphics, better documentation,=0A=
> are all "nice to have" but, as Hamming would say,=0A=
> they are not "the most important problem".=0A=
>=0A=
> Tim=0A=
>=0A=
>=0A=
>=0A=
> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>> Time for another update.=0A=
>>=0A=
>> The latest Intel processors, available only to data centers=0A=
>> so far, have a built-in FPGA. This allows you to design=0A=
>> your own circuits and have them loaded "on the fly",=0A=
>> running in parallel with the CPU.=0A=
>>=0A=
>> I bought a Lattice ICEstick FPGA development board. For=0A=
>> the first time there are open source tools that support it so=0A=
>> it is a great test bench for ideas and development. It is a=0A=
>> USB drive so it can be easily ported to any PC.=0A=
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesemi.=
com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQz2=
HFhAAAymG-QswIjRao_YTwz4&e=3D=0A=
>> )=0A=
>>=0A=
>> I also bought a large Intel Cyclone FPGA development board.=0A=
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com.t=
w_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=3D=
4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79Pd=
SWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW6Bu=
eAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D=0A=
>> )=0A=
>> which has 2 embedded ARM processors. Unfortunately=0A=
>> the tools (which are freely available) are not open source.=0A=
>> It has sufficient size and power to do anything.=0A=
>>=0A=
>>=0A=
>> I've got 2 threads of work in progress, both of which=0A=
>> involve FPGAs (Field Programmable Gate Arrays).=0A=
>>=0A=
>> Thread 1=0A=
>>=0A=
>> The first thread involves proving programs correct. Once=0A=
>> a proof has been made it is rather easier to check the proof.=0A=
>> If code is shipped with a proof, the proof can be loaded into=0A=
>> an FPGA running a proof-checker which verifies the program=0A=
>> in parallel with running the code on the CPU.=0A=
>>=0A=
>> I am researching the question of writing a proof checker that=0A=
>> runs on an FPGA, thus verifying the code "down to the metal".=0A=
>> The Lean proof checker is the current target.=0A=
>>=0A=
>> The idea is to make "Oracle" algorithms that, because they=0A=
>> are proven correct and verified at runtime, can be trusted=0A=
>> by other mathematical software (e.g. Lean, Coq, Agda)=0A=
>> when used in proofs.=0A=
>>=0A=
>> Thread 2=0A=
>>=0A=
>>=0A=
>> The second thread involves arithmetic. Axiom currently ships=0A=
>> with numeric routines (BLAS and LAPACK, see bookvol10.5).=0A=
>> These routines have a known set of numeric failures such as=0A=
>> cancellation, underflow, and scaling.=0A=
>>=0A=
>> John Gustafson has designed a 'unum' numeric format that can=0A=
>> eliminate many of these errors. (See=0A=
>> Gustafson, John "The End of Error" CRC Press 2015=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_En=
d-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F1-=
5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D15=
93685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwt=
IMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX=
0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0A&=
e=3D=0A=
>> )=0A=
>>=0A=
>> The research goal is to implement Axiom's floating-point=0A=
>> arithmetic that can be offloaded onto an FPGA implementing=0A=
>> the unum format. Such a system would radically simplify=0A=
>> the implementation of BLAS and LAPACK as most of the=0A=
>> errors can't occur. The impact would be similar to using=0A=
>> multi-precision integer arithmetic, only now its floating-point.=0A=
>>=0A=
>> SANE, the greater goal.=0A=
>>=0A=
>> The Axiom SANE compiler / interpreter can use both of=0A=
>> these tools to implement trusted mathematical software.=0A=
>> It's a long, ambitious research effort but even if only pieces=0A=
>> of it succeed, it changes computational mathematics.=0A=
>>=0A=
>> Tim=0A=
>>=0A=
>> "A person's reach should exceed their grasp,=0A=
>> or what's a computer for?"  (misquoting Robert Browning)=0A=
>>=0A=
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.com=
_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexceed=
-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_Oq=
sfcYl4z14qlYS02TBNmnaHUY&e=3D=0A=
>> )=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>> WHY PROVE AXIOM CORRECT (SANE)?=0A=
>>>=0A=
>>> Historically, Axiom credits CLU, the Cluster language by=0A=
>>> Barbara Liskov, with the essential ideas behind the Spad=0A=
>>> language. Barbara gave a talk (a partial transcript below)=0A=
>>> that gives the rational behind the ``where clause'' used by=0A=
>>> Spad.=0A=
>>>=0A=
>>> She talks about the limits of the compile time capablity.=0A=
>>> In particular, she says:=0A=
>>>=0A=
>>>    To go further, where we would say that T,=0A=
>>>    in addition, has to be an equality relation, that requires=0A=
>>>    much more sophisticated techniques that, even today, are=0A=
>>>    beyond the capabilities of the compiler.=0A=
>>>=0A=
>>> Showing that the ``equal'' function satisfies the equality=0A=
>>> relation is no longer ``beyond the capabilities of the compiler''.=0A=
>>> We have the required formalisms and mechanisms to=0A=
>>> prove properties at compile time.=0A=
>>>=0A=
>>> The SANE effort is essentially trying to push compile=0A=
>>> time checking into proving that, for categories that use=0A=
>>> ``equal'', we prove that the equal function implements=0A=
>>> equality.=0A=
>>>=0A=
>>> I strongly encourage you to watch her video.=0A=
>>>=0A=
>>> Tim=0A=
>>>=0A=
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
>>> Barbara Liskov=0A=
>>> May 2012=0A=
>>> MIT CSAIL=0A=
>>> Programming the Turing Machine=0A=
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_=
watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZe=
PX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1eG=
Y&e=3D=0A=
>>>=0A=
>>> POLYMORPHISM=0A=
>>>=0A=
>>> We don't just want a set, we want polymorphism or=0A=
>>> generics, as they are called today. We wanted to=0A=
>>> have a generic set which was paramaterized by type=0A=
>>> so you could instantiate it as:=0A=
>>>=0A=
>>> Set =3D [T:type] create, insert,...=0A=
>>>   % representation for Set object=0A=
>>>   % implementation of Set operations=0A=
>>>   Set=0A=
>>>=0A=
>>> Set[int] s :=3D Set[int]$create()=0A=
>>> Set[int]$insert(s,3)=0A=
>>>=0A=
>>> We wanted a static solution to this problem. The=0A=
>>> problem is, not every type makes sense as a parameter=0A=
>>> to Set of T. For sets, per se, you need an equality=0A=
>>> relation. If it has been a sorted set we would have=0A=
>>> some ordering relation. And a type that didn't have=0A=
>>> one of those things would not have been a legitimate=0A=
>>> parameter. We needed a way of expressing that in a=0A=
>>> compile-time, checkable manner. Otherwise we would=0A=
>>> have had to resort to runtime checking.=0A=
>>>=0A=
>>> Our solution was=0A=
>>>=0A=
>>> Set =3D [T:  ] create, insert,...=0A=
>>>   T equal: (T,T) (bool)=0A=
>>>=0A=
>>>=0A=
>>> Our solution, what we call the ``where clause''. So we=0A=
>>> added this to the header. The ``where clause'' tells you=0A=
>>> what operations the parameter type has to have.=0A=
>>>=0A=
>>> If you have the ``where'' clause you can do the static=0A=
>>> checking because when you instantiate, when you provide=0A=
>>> an actual type, the compiler can check that the type has=0A=
>>> the operations that are required. And then, when you write=0A=
>>> the implementation of Set the compiler knows it's ok to=0A=
>>> call those operations because you can guarantee they are=0A=
>>> actually there when you get around to running.=0A=
>>>=0A=
>>> Of course, you notice that there's just syntax here; there's=0A=
>>> no semantics.=0A=
>>>=0A=
>>> As I'm sure you all know, compile-time type checking is=0A=
>>> basically a proof technique of a very limited sort and=0A=
>>> this was about as far as we can push what you could get out of the=0A=
>>> static analysis. To go further, where we would say that T,=0A=
>>> in addition, has to be an equality relation, that requires=0A=
>>> much more sophisticated techniques that, even today, are=0A=
>>> beyond the capabilities of the compiler.=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>> I've spent entirely too much time studing the legal issues=0A=
>>>> of free and open source software. There are copyright,=0A=
>>>> trademark, and intellectual property laws. I have read=0A=
>>>> several books, listened to lectures, and read papers on=0A=
>>>> the subject. I've spoken to lawyers about it. I've even=0A=
>>>> been required, by law, to coerce people I respect.=0A=
>>>> You would think it was all perfectly clear. It isn't.=0A=
>>>>=0A=
>>>> The most entertaining and enlightening lectures were=0A=
>>>> by Robert Lefkowitz at OSCON 2004. His talk is=0A=
>>>> "The Semasiology of Open Source", which sounds=0A=
>>>> horrible but I assure you, this is a real treat.=0A=
>>>>=0A=
>>>> THE THESIS=0A=
>>>>=0A=
>>>> Semasiology, n. The science of meanings or=0A=
>>>> sense development (of words); the explanation=0A=
>>>> of the development and changes of the meanings=0A=
>>>> of words. Source: Webster's Revised Unabridged=0A=
>>>> Dictionary, =EF=BF=BD 1996, 1998 MICRA, Inc.=0A=
>>>>=0A=
>>>> "Open source doesn't just mean access to the=0A=
>>>> source code." So begins the Open Source Definition.=0A=
>>>> What then, does access to the source code mean?=0A=
>>>> Seen through the lens of an Enterprise user, what=0A=
>>>> does open source mean? When is (or isn't) it=0A=
>>>> significant? And a catalogue of open source=0A=
>>>> related arbitrage opportunities.=0A=
>>>>=0A=
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversat=
ionsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520of=
-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnEbu=
sM&e=3D=0A=
>>>>=0A=
>>>> Computer source code has words and sentence=0A=
>>>> structure like actual prose or even poetry. Writing=0A=
>>>> code for the computer is like writing an essay. It=0A=
>>>> should be written for other people to read,=0A=
>>>> understand and modify. These are some of the=0A=
>>>> thoughts behind literate programming proposed=0A=
>>>> by Donald Knuth. This is also one of the ideas=0A=
>>>> behind Open Source.=0A=
>>>>=0A=
>>>>  THE ANTITHESIS=0A=
>>>>=0A=
>>>> "Open Source" is a phrase like "Object Oriented"=0A=
>>>> - weird at first, but when it became popular, the=0A=
>>>> meaning began to depend on the context of the=0A=
>>>> speaker or listener. "Object Oriented" meant that=0A=
>>>> PERL, C++, Java, Smalltalk, Basic and the newest=0A=
>>>> version of Cobol are all "Object Oriented" - for some=0A=
>>>> specific definition of "Object Oriented". Similar is=0A=
>>>> the case of the phrase "Open Source".=0A=
>>>>=0A=
>>>> In Part I, Lefkowitz talked about the shift of the=0A=
>>>> meaning of "Open Source" away from any reference=0A=
>>>> to the actual "source code," and more towards other=0A=
>>>> phases of the software development life cycle. In=0A=
>>>> Part II, he returns to the consideration of the=0A=
>>>> relationship between "open source" and the actual=0A=
>>>> "source code," and reflects upon both the way=0A=
>>>> forward and the road behind, drawing inspiration=0A=
>>>> from Charlemagne, King Louis XIV, Donald Knuth,=0A=
>>>> and others.=0A=
>>>>=0A=
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversat=
ionsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DLTg=
LxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D=0A=
>>>>=0A=
>>>> THE SYNTHESIS=0A=
>>>>=0A=
>>>> In a fascinating synthesis, Robert =93r0ml=94 Lefkowitz=0A=
>>>> polishes up his exposition on the evolving meaning=0A=
>>>> of the term =91open source=92. This intellectual joy-ride=0A=
>>>> draws on some of the key ideas in artificial intelligence=0A=
>>>> to probe the role of language, meaning and context=0A=
>>>> in computing and the software development process.=0A=
>>>> Like Wittgenstein=92s famous thought experiment, the=0A=
>>>> open source =91beetle in a box=92 can represent different=0A=
>>>> things to different people, bearing interesting fruit for=0A=
>>>> philosophers and software creators alike.=0A=
>>>>=0A=
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversation=
snetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4Nmam=
NZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRx=
NZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIwON=
-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D=0A=
>>>>=0A=
>>>>=0A=
>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>> I've pushed the lastest version of Axiom. The plan, followed=0A=
>>>>> so far, is to push once a month on the 7th.=0A=
>>>>>=0A=
>>>>> After some chat room interactions it was brought home=0A=
>>>>> again that the proof world really does not seem to like the=0A=
>>>>> idea of proving programs correct. And, given that it was is=0A=
>>>>> of the main Axiom goals and a point of friction during the fork,=0A=
>>>>> the computer algebra world does not like the idea of proving=0A=
>>>>> programs correct either.=0A=
>>>>>=0A=
>>>>> So the idea of "computational mathematics", which includes=0A=
>>>>> both disciplines (as well as type theory) seems still a long=0A=
>>>>> way off.=0A=
>>>>>=0A=
>>>>> Nevertheless, the primary change in these past and future=0A=
>>>>> updates is focused on merging proof and computer algebra.=0A=
>>>>>=0A=
>>>>> Proof systems are able to split the problem of creating a=0A=
>>>>> proof and the problem of verifying a proof, which is much=0A=
>>>>> cheaper. Ideally the proof checker would run on verified=0A=
>>>>> hardware so the proof is checked "down to the metal".=0A=
>>>>>=0A=
>>>>> I have a background in Field Programmable Gate Arrays=0A=
>>>>> (FPGAs) as I tried to do a startup using them. So now I'm=0A=
>>>>> looking at creating a hardware proof checker using a=0A=
>>>>> dedicated instruction set, one designed to be verifed.=0A=
>>>>> New CPUs used in data centers (not yet available to us=0A=
>>>>> mortals) have built-in FPGAs so it would be possible to=0A=
>>>>> "side-load" a proof of a program to be checked while the=0A=
>>>>> program is run. I have the FPGA and am doing a gate-level=0A=
>>>>> special instruction design for such a proof checker.=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>> As a mathematician, it is difficult to use a system like Axiom,=0A=
>>>>>> mostly because it keeps muttering about Types. If you're not=0A=
>>>>>> familiar with type theory (most mathematicians aren't) then it=0A=
>>>>>> seems pointless and painful.=0A=
>>>>>>=0A=
>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>=0A=
>>>>>> As a mathematician with an algorithmic approach, it is difficult=0A=
>>>>>> to use a system like Axiom, mostly because you have to find=0A=
>>>>>> or create "domains" or "packages", understand categories=0A=
>>>>>> with their inheritance model, and learn a new language with=0A=
>>>>>> a painful compiler always complaining about types.=0A=
>>>>>>=0A=
>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>=0A=
>>>>>> The Sane version of Axiom requires knowing the mathematics.=0A=
>>>>>> It also assumes a background in type theory, inductive logic,=0A=
>>>>>> homotopy type theory, ML (meta-language, not machine=0A=
>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,=0A=
>>>>>> and tacticals. Also assumed is knowledge of specification languages,=
=0A=
>>>>>> Hoare triples, proof techniques, soundness, and completeness.=0A=
>>>>>> Oh, and there is a whole new syntax and semantics added to=0A=
>>>>>> specify definitions, axioms, and theorems, not to mention whole=0A=
>>>>>> libraries of the same.=0A=
>>>>>>=0A=
>>>>>> So Axiom Sane has a steep learning curve.=0A=
>>>>>>=0A=
>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years=0A=
>>>>>> learning to read the leading edge literature (also known=0A=
>>>>>> as "greek studies", since every paper has pages of greek).=0A=
>>>>>>=0A=
>>>>>> I'm trying to unify computer algebra and proof theory into a=0A=
>>>>>> "computational mathematics" framework. I suspect that the only=0A=
>>>>>> way this system will ever be useful is after Universities have a=0A=
>>>>>> "Computational Mathematics" major course of study and degree.=0A=
>>>>>>=0A=
>>>>>> Creating a new department is harder than creating Axiom Sane=0A=
>>>>>> because, you know, ... people.=0A=
>>>>>>=0A=
>>>>>> I think such a department is inevitable given the deep and wide=0A=
>>>>>> impact of computers, just not in my lifetime. That's ok. When I=0A=
>>>>>> started programming there was no computer science degree.=0A=
>>>>>>=0A=
>>>>>> Somebody has to be the first lemming over the cliff.=0A=
>>>>>>=0A=
>>>>>> Tim=0A=
>>>>>>=0A=
>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)=0A=
>>>>>>> there is a certain amount of verification that is involved.=0A=
>>>>>>>=0A=
>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its=0A=
>>>>>>> algorithms. Ideally, when a computation is requested from Lean=0A=
>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is=0A=
>>>>>>> returned. Lean can the verify that the proof is valid. But it is=0A=
>>>>>>> computationally more efficient if Axiom and Lean use a cryptographi=
c=0A=
>>>>>>> hash, such as SHA1. That way the proof doesn't need to be=0A=
>>>>>>> 'reproven', only a hash computation over the proof text needs to=0A=
>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be=
=0A=
>>>>>>> exchanged without re-running the proof mechanism. Since a large=0A=
>>>>>>> computation request from Lean might involve many algorithms=0A=
>>>>>>> there would be considerable overhead to recompute each proof.=0A=
>>>>>>> A hash simplifies the issue yet provides proof integrity.=0A=
>>>>>>>=0A=
>>>>>>> Tim=0A=
>>>>>>>=0A=
>>>>>>>=0A=
>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'=0A=
>>>>>>>>=0A=
>>>>>>>> A computer algebra system ought to know and ought to provide=0A=
>>>>>>>> information about the domain and range of a resulting formula.=0A=
>>>>>>>> I've been pushing this effort since the 1980s (hence the=0A=
>>>>>>>> SuchThat domain).=0A=
>>>>>>>>=0A=
>>>>>>>> It turns out that computing with, carrying, and combining this=0A=
>>>>>>>> information is difficult if not impossible in the current system.=
=0A=
>>>>>>>> The information isn't available and isn't computed. In that sense,=
=0A=
>>>>>>>> the original Axiom system is 'showing its age'.=0A=
>>>>>>>>=0A=
>>>>>>>> In the Sane implementation the information is available. It is=0A=
>>>>>>>> part of the specification and part of the proof steps. With a=0A=
>>>>>>>> careful design it will be possible to provide provisos for each=0A=
>>>>>>>> given result that are carried with the result for use in further=
=0A=
>>>>>>>> computation.=0A=
>>>>>>>>=0A=
>>>>>>>> This raises interesting questions to be explored. For example,=0A=
>>>>>>>> if the formula is defined over an interval, how is the interval=0A=
>>>>>>>> arithmetic handled?=0A=
>>>>>>>>=0A=
>>>>>>>> Exciting research ahead!=0A=
>>>>>>>>=0A=
>>>>>>>> Tim=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>> Trusted Kernel... all the way to the metal.=0A=
>>>>>>>>>=0A=
>>>>>>>>> While building a trusted computer algebra system, the=0A=
>>>>>>>>> SANE version of Axiom, I've been looking at questions of=0A=
>>>>>>>>> trust at all levels.=0A=
>>>>>>>>>=0A=
>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a=0A=
>>>>>>>>> trusted kernel through which all other computations must=0A=
>>>>>>>>> pass. Coq, Lean, and other systems do this. They base=0A=
>>>>>>>>> their kernel  on logic like the Calculus of Construction or=0A=
>>>>>>>>> something similar.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a=0A=
>>>>>>>>> nucleus) that separates the trust from the logic. The rules=0A=
>>>>>>>>> for the logic can be specified as needed but checked by=0A=
>>>>>>>>> the nucleus code.=0A=
>>>>>>>>>=0A=
>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)=0A=
>>>>>>>>> that allow you to create your own hardware in a C-like=0A=
>>>>>>>>> language (Verilog). It allows you to check the chip you build=0A=
>>>>>>>>> all the way down to the transistor states. You can create=0A=
>>>>>>>>> things as complex as a whole CPU or as simple as a trusted=0A=
>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a=0A=
>>>>>>>>> history of verifying hardware logic.=0A=
>>>>>>>>>=0A=
>>>>>>>>> It appears that, assuming I can understand Bauers=0A=
>>>>>>>>> Andromeda system, it would be possible and not that hard=0A=
>>>>>>>>> to implement a trusted kernel on an FPGA the size and=0A=
>>>>>>>>> form factor of a USB stick.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Trust "down to the metal".=0A=
>>>>>>>>>=0A=
>>>>>>>>> Tim=0A=
>>>>>>>>>=0A=
>>>>>>>>>=0A=
>>>>>>>>>=0A=
>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Recently I've been musing about methods to insert axioms=0A=
>>>>>>>>>> into categories so they could be inherited like signatures.=0A=
>>>>>>>>>> At the moment I've been thinking about adding axioms in=0A=
>>>>>>>>>> the same way that signatures are written, adding them to=0A=
>>>>>>>>>> the appropriate categories.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> But this is an interesting design question.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Axiom already has a mechanism for inheriting signatures=0A=
>>>>>>>>>> from categories. That is, we can bet a plus signature from,=0A=
>>>>>>>>>> say, the Integer category.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom=0A=
>>>>>>>>>> inherits certain so-called "attributes", such as=0A=
>>>>>>>>>> ApproximateAttribute,=0A=
>>>>>>>>>> which implies that the results are only approximate.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive=0A=
>>>>>>>>>> property by defining it in its own category. In fact, if we=0A=
>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,=0A=
>>>>>>>>>> where each property has its own inheritable category,=0A=
>>>>>>>>>> we can "mix and match" the axioms at will.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> An "axiom" category would also export a function. This function=
=0A=
>>>>>>>>>> would essentially be a "tactic" used in a proof. It would modify=
=0A=
>>>>>>>>>> the proof step by applying the function to the step.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Theorems would have the same structure.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> This allows theorems to be constructed at run time (since=0A=
>>>>>>>>>> Axiom supports "First Class Dynamic Types".=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> In addition, this design can be "pushed down" into the Spad=0A=
>>>>>>>>>> language so that Spad statements (e.g. assignment) had=0A=
>>>>>>>>>> proof-related properties. A range such as [1..10] would=0A=
>>>>>>>>>> provide explicit bounds in a proof "by language definition".=0A=
>>>>>>>>>> Defining the logical properties of language statements in=0A=
>>>>>>>>>> this way would make it easier to construct proofs since the=0A=
>>>>>>>>>> invariants would be partially constructed already.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> This design merges the computer algebra inheritance=0A=
>>>>>>>>>> structure with the proof of algorithms structure, all under=0A=
>>>>>>>>>> the same mechanism.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Tim=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent=0A=
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.k=
ent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVK=
rkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOI=
DfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5xsN=
k1_eii0&e=3D=0A=
>>>>>>>>>>> ) on=0A=
>>>>>>>>>>> Seven deadly sins of talking about =93types=94=0A=
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.k=
ent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62fT=
bqv-K98dBQv0oMmB82kE8mXo&e=3D=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> He raised an interesting idea toward the end of the essay=0A=
>>>>>>>>>>> that type-checking could be done outside the compiler.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.=0A=
>>>>>>>>>>> It would be possible to run a program over the source code=0A=
>>>>>>>>>>> to collect the information and write a stand-alone type=0A=
>>>>>>>>>>> checker. This "unbundles" type checking and compiling.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Taken further I can think of several other kinds of checkers=0A=
>>>>>>>>>>> (aka 'linters') that could be unbundled.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> It is certainly something to explore.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer=0A=
>>>>>>>>>>>> blows of reality", to coin a phrase.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> There are many goals. One of the primary goals is creating a=
=0A=
>>>>>>>>>>>> compiler that can be understood, maintained, and modified.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> So the latest changes involved adding multiple index files.=0A=
>>>>>>>>>>>> These are documentation (links to where terms are mentioned=0A=
>>>>>>>>>>>> in the text), code (links to the implementation of things),=0A=
>>>>>>>>>>>> error (links to where errors are defined), signatures (links t=
o=0A=
>>>>>>>>>>>> the signatures of lisp functions), figures (links to figures),=
=0A=
>>>>>>>>>>>> and separate category, domain, and package indexes.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"=0A=
>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of=0A=
>>>>>>>>>>>> those diagrams follows immediately. Collectively these will=0A=
>>>>>>>>>>>> eventually define at least the syntax of the language. In the=
=0A=
>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm=0A=
>>>>>>>>>>>> not that clever.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Reality shows up with the curent constraint that the=0A=
>>>>>>>>>>>> compiler should accept the current Spad language as=0A=
>>>>>>>>>>>> closely as possible. Of course, plans are to include new=0A=
>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)=0A=
>>>>>>>>>>>> but these are being postponed until "syntax complete".=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> All parse information is stored in a parse object, which=0A=
>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)=0A=
>>>>>>>>>>>> Fields within the parse object, e.g. variables are also=0A=
>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).=0A=
>>>>>>>>>>>> It's types all the way down.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> These types are being used as 'signatures' for the=0A=
>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the=0A=
>>>>>>>>>>>> compiler implementation as well as the Sane language.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> The parser is designed to "wrap around" so that the=0A=
>>>>>>>>>>>> user-level output of a parse should be the user-level=0A=
>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"=0A=
>>>>>>>>>>>> should make it easy to see that the parser properly=0A=
>>>>>>>>>>>> parsed the user input.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> The parser is "first class" so it will be available at=0A=
>>>>>>>>>>>> runtime as a domain allowing Spad code to construct=0A=
>>>>>>>>>>>> Spad code.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> One plan, not near implementation, is to "unify" some=0A=
>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How=0A=
>>>>>>>>>>>> this will happen is still in the land of design. This would=0A=
>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is=0A=
>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp=0A=
>>>>>>>>>>>> functions (with CLOS types as signatures) would be=0A=
>>>>>>>>>>>> avaiable for implementing Spad functions. This not=0A=
>>>>>>>>>>>> only improves the efficiency, it would make the=0A=
>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.=0A=
>>>>>>>>>>>> .=0A=
>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods=0A=
>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to=0A=
>>>>>>>>>>>> know how little I know, especially that I need to know.=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.andr=
ew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6I=
noLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=
=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx-3=
GFVk62hxr53YKr4naRk&e=3D=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:=0A=
>>>>>>>>>>>>> The underlying technology to use for building such an algebra=
=0A=
>>>>>>>>>>>>> library=0A=
>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between=0A=
>>>>>>>>>>>>> Theories:=0A=
>>>>>>>>>>>>> Theory Presentation Combinators"=0A=
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.cas=
.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryVeF=
oBjl0AZs2cuQZhKuIxk8NUw&e=3D=0A=
>>>>>>>>>>>>> [which=0A=
>>>>>>>>>>>>> will=0A=
>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a=
=0A=
>>>>>>>>>>>>> journal].=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> There is a rather full-fledged prototype, very well documente=
d=0A=
>>>>>>>>>>>>> at=0A=
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhass=
y.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html&d=
=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWE=
VPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDz=
gkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> (source at=0A=
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github=
.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6=
InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&=
m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZBB5f=
BQOj0-Q48CUKRS1VNLao&e=3D=0A=
>>>>>>>>>>>>> ).=0A=
>>>>>>>>>>>>> It=0A=
>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>> literate source.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> The old prototype was hard to find - it is now at=0A=
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github=
.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqO=
IDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITFQR=
pkFBgg8c&e=3D=0A=
>>>>>>>>>>>>> .=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it doe=
s=0A=
>>>>>>>>>>>>> not=0A=
>>>>>>>>>>>>> quite=0A=
>>>>>>>>>>>>> function properly today, it is under repair.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"=0A=
>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhas=
sy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5Ff=
eature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0zi=
ts8pEczWsib7Q7_mxyRIxhk&e=3D=0A=
>>>>>>>>>>>>> )=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized=0A=
>>>>>>>>>>>>> theories=0A=
>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all curre=
nt=0A=
>>>>>>>>>>>>> systems=0A=
>>>>>>>>>>>>> suffer from.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Jacques=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:=0A=
>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas=
=0A=
>>>>>>>>>>>>>> algebra code. The compiler knows about the language but=0A=
>>>>>>>>>>>>>> does not depend on the algebra library (so far). It should b=
e=0A=
>>>>>>>>>>>>>> possible, by design, to load different algebra towers.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"=0A=
>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much=0A=
>>>>>>>>>>>>>> finer grain separation of algebra and axioms.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> This "flexible algebra" design would allow things like the=
=0A=
>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports=0A=
>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Another possible design choice is to target the GNU=0A=
>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just=0A=
>>>>>>>>>>>>>>> another front-end language" supported by GCC.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> The current intermediate representation does not (yet)=0A=
>>>>>>>>>>>>>>> make any decision about the runtime implementation.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") developed=
=0A=
>>>>>>>>>>>>>>>> a dependently typed general parser for context free gramma=
r=0A=
>>>>>>>>>>>>>>>> in Coq.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.=0A=
>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider=0A=
>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> Tim=0A=

\start
Date: Mon, 20 Jul 2020 16:44:33 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>
Subject: Re: [EXTERNAL] Re: Axiom musings...

> So there are two kinds of algorithms, one that is purely mathematical
> and one that is computational, the latter including a particular (class o=
f)
> data representation(s) (perhaps even the computer language and
> system of the implementation). It is proofs for the latter type of
> algorithms that is lacking.

There are ,as you point out, several kinds of proofs to consider.

One is the proof of the algorithm. An example is Buchberger's
Groebner Basis algorithm which was proven in Coq:
https://www.ricam.oeaw.ac.at/specsem/srs/groeb/download/coq-linz.pdf

The Coq proof establishes that the formal algorithm is correct.

Even in proof one runs into limits of what can be proved. For example,
if the convergence is non-uniform one can, at best, do a proof that
assumes bounds on the non-uniform behavior. So this isn't strictly
a computer algorithm issue.

> Since data representations (like REP in Axiom) are built recursively,
> a computational algorithm (in the sense above) for Groebner basis
> may have to be designed to take care of just a few of the ways
> integers can be represented. Axiom is built with that in mind (that's
> where type theory comes in), but I bet no one SPECIFIES their
> computational algorithms with the limitations of data representation
> in mind, much less proves the algorithm anew for each new
> representation.

If you remember, while we were both at CCNY, I worked on a
grant project to construct a "symbolic integer" domain so that
computations could occur over non-numeric integers. The
symbolic form did not have a numeric limitation. Unfortunatly
the current Axiom has no way to support such a domain.

I'm glad you brought this up. I will have to give some thought
to representing and computing with symbolic integers again.

> So if a computation of a Groebner basis halts
> because of an intermediate LCM computation (say of two integer
> coefficients), should we consider the implementation as proven
> correct? What if the overflow condition was not detected and the
> computation continues? Indeed, since there may be different
> implementations of the integer domain, we must be sure that
> every implementation of the LCM algorithm handles overflows
> correctly AND specified in the documentation.

Establishing that the algorithm is correct (e.g Groebner) is
clearly in the proof side of computational math
.
Establishing that there is an implementation of Groebner is
clearly in the computer algebra side of computational math.

The game is to unite the two.

Such a proof becomes a PART of the specification of a program
that implements the algorithm, such as in Axiom.

The definitions and axioms of the proof have to be put into
the system both at the category and domain levels. They
need to be available at the implementation code.

On the other hand, there are non-logical 'axioms' of
categories and domains, such as limits to the size of a
floating point number. One could have many FLOAT
domains, such as Gustafson's UNUMs.
http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf

There are non-logical limits to the implementation, such as
intermediate expression swell that uses up all of memory.
It isn't possible to write a specification that can detect all of
these kinds of failures before they occur. But there are logical
ways to handle such boundaries.

In logic there are 'product types' which are basically
multi-field records. There are 'sum types' which are disjoint
unions.

Axiom's approach to reaching limits of computation is to
return a 'sum type' that is either the result or 'failed'. The
'failed' result needs to be explicitly carried in the proof.
Because 'failed' is a valid result, the specification can be
expanded to include this as a valid result.

Just because a program can fail there is no reason to say
that it can't be proven, given that 'failed' is a valid result.

One could even expand the sum types to include information
about the failure so that 'failed' would be a product type that
said why it failed. That allows another domain to be used.
In fact, one could introduce a FAILED domain in Axiom
with a 'why?' function. Local domains could extend FAILED
with their own 'why?' function specific to their possible
failures.

Axiom has the ability to have muttiple domains that can
overcome limits, e.g. small floats, large floats, unums.
These would allow users to 'retry' a computation with
different assumptions.

The issue you raise is important. Some algorithms in
Axiom have "hand-waving' specifications that need
to be expanded to properly return 'failed' when that is
expected. I think this is a 'good thing' and a useful
by-product of combining proof and computer algebra.

Am I closer to understanding your objections?

Tim



On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:
> Hi Tim:
>
> Perhaps I did not make myself clear in the short comment.
> What I wanted to say is that a data representation is not the same as the
> abstract mathematical objects because there are finite bounds on the
> representation. Take for example, an algorithm to compute the LCM of two
> integers. The LCM can cause overflow and not be representable. Of course,
> you can change the data representation to have "infinite precision", but
> that would still be bounded by actual physical memory of the machine. The
> careful programmer of the LCM algorithm would add throws and catches to
> handle the "error",but the implementation will have to add code that is n=
ot
> considered in the theoretical LCM algorithm (unless the LCM algorithm is
> meant for bounded integers of a fixed data representation and not abstrac=
t
> integers). So there are two kinds of algorithms, one that is purely
> mathematical and one that is computational, the latter including a
> particular (class of) data representation(s) (perhaps even the computer
> language and system of the implementation). It is proofs for the latter t=
ype
> of algorithms that is lacking. Since data representations (like REP in
> Axiom) are built recursively, a computational algorithm (in the sense abo=
ve)
> for Groebner basis may have to be designed to take care of just a few of =
the
> ways integers can be represented. Axiom is built with that in mind (that'=
s
> where type theory comes in), but I bet no one SPECIFIES their computation=
al
> algorithms with the limitations of data representation in mind, much less
> proves the algorithm anew for each new representation. So if a computatio=
n
> of a Groebner basis halts because of an intermediate LCM computation (say=
 of
> two integer coefficients), should we consider the implementation as prove=
n
> correct? What if the overflow condition was not detected and the computat=
ion
> continues? Indeed, since there may be different implementations of the
> integer domain, we must be sure that every implementation of the LCM
> algorithm handles overflows correctly AND specified in the documentation.
>
> I am sure I am just being ignorant to pose these questions, because they
> must have been considered and perhaps solved. In that case, please ignore
> them and just tell me so.
>
> William
>
> William Sit
> Professor Emeritus
> Department of Mathematics
> The City College of The City University of New York
> New York, NY 10031
> homepage: wsit.ccny.cuny.edu
>
> ________________________________________
> From: Tim Daly <axiomcas@gmail.com>
> Sent: Sunday, July 19, 2020 5:33 PM
> To: William Sit
> Cc: axiom-dev
> Subject: Re: [EXTERNAL] Re: Axiom musings...
>
> There are several "problems" with proving programs correct that
> I don't quite know how to solve, or even approach. But that's the
> fun of "research", right?
>
> For the data representation question I've been looking at types.
> I took 10 courses at CMU. I am eyebrow deep in type theory.
> I'm looking at category theory and homotopy type theory. So
> far I haven't seen anyone looking at the data problem. Most of
> the focus is on strict code typing.
>
> There is an old MIT course by Abelson and Sussman "Structure
> and Interpretation of Computer Programs" (SICP). They rewrite
> data as programs which, in Lisp, is trivial to do, Dan Friedman
> seems to have some interesting ideas too.
>
> All of Axiom's SANE types are now CLOS objects which gives
> two benefits. First, they can be inherited. But second, they
> are basically Lisp data structures with associated code.
>
> I'm thinking of associating "data axioms" with the representation
> (REP) object of a domain as well as with the functions.
>
> For example, DenavitHartenbergMatrix encodes 4x4 matrices
> used in graphics and robotics. They are 4x4 matrices where
> the upper left 3x3 encodes rotations, the right column encodes
> translations, and the lower row includes scaling, skewing, etc.
>
> (As an aside, DHMATRIX matrices have an associated
> Jacobian which encodes the dynamics in things like robots.
> Since I'm also programming a robot I'm tempted to work on
> extending the domain with related functions... but, as
> Hamming said, new algebra code isn't "the most important
> problem in computational mathematics").
>
> Axioms associated with the REP can assume that they are
> 4x4, that they can be inverted, that they have a "space" of
> rotations, etc. The axioms provide "facts" known to be true
> about the REP. (I also need to think about a "specification"
> for the REP but I'm not there yet).
>
> Since every category and domain is a CLOS data structure
> the DHMATRIX data structure inherits REP axioms from its
> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX
> adds domain-specific REP axioms (as well as domain-specific
> function axioms). Thus a DHMATRIX rotate function can
> base its proof on the fact that it only affects the upper 3x3
> and lives in a space of rotations, all of which can be assumed
> by the proof.
>
> If I use the SICP "trick" of representing data as code I can
> "expand" the data as part of the program proof.
>
> It is all Omphaloskepsis (navel gazing) at this point though.
> I'm still writing the new SANE compiler (which is wildly
> different from the compiler course I taught).
>
> I did give a talk at Notre Dame but I haven't attempted to
> publish. All of my work shows up in literate programming
> Axiom books on github.
> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly_P=
DFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcT=
vR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQIcL=
fvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D
> )
>
> It is all pretty pointless since nobody cares about computer
> algebra, proving math programs correct, or Axiom itself.
> Wolfram is taking up all the oxygen in the discussions.
>
> But I have to say, this research is great fun. It reminds me
> of the Scratchpad days, although I miss the give-and-take
> of the group. It is hard to recreate my role as the dumbest
> guy in the room when I'm stuck here by myself :-)
>
> Hope you and your family are safe and healthy.
>
> Tim
>
> PS. I think we should redefine the "Hamming Distance" as
> the distance between an idea and its implementation.
>
>
>
> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:
>> Hi Tim:
>>
>> Glad to hear from you now and then, promoting and working towards your
>> ideas
>> and ideals.
>>
>>  >>We need proven algorithms.
>>
>> Just one short comment: it is often possible to prove algorithms (that i=
s,
>> providing the theoretical foundation for the algorithm), but it is much
>> harder to prove that an implementation of the algorithm is correct. As y=
ou
>> well know, the distinction lies in that implementation involves data
>> representations whereas proofs of algorithms normally ignore them.
>> Introducing (finite) data representations means introducing boundary
>> situations that a programmer implementing an algorithm must deal with. S=
o
>> perhaps what we need to prove should include the correctness of
>> implementations (to the bare metal, as you often say) and we should have=
 a
>> different set of analytic tools that can deal with the correctness (or
>> completeness) of data representations. Of course, these tools must also =
be
>> proven with the same rigor since behind every program is an algorithm.
>>
>> William
>>
>> William Sit
>> Professor Emeritus
>> Department of Mathematics
>> The City College of The City University of New York
>> New York, NY 10031
>> homepage: wsit.ccny.cuny.edu
>>
>> ________________________________________
>> From: Axiom-developer
>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behalf=
 of
>> Tim Daly <axiomcas@gmail.com>
>> Sent: Saturday, July 18, 2020 6:28 PM
>> To: axiom-dev; Tim Daly
>> Subject: [EXTERNAL] Re: Axiom musings...
>>
>> Richard Hamming gave a great talk. "You and Your Research"
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_w=
atch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZeP=
X0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0U=
&e=3D
>>
>> His big question is:
>>
>> "What is the most important problem in your field
>> and why aren't you working on it?"
>>
>> To my mind, the most important problem in the field of
>> computational mathematics is grounding computer
>> algebra in proofs.
>>
>> Computer mathematical algorithms that "maybe,
>> possibly, give correct answers sometimes" is a problem.
>> Indeed, for computer algebra, it is the most important
>> problem. We need proven algorithms.
>>
>> New algorithms, better graphics, better documentation,
>> are all "nice to have" but, as Hamming would say,
>> they are not "the most important problem".
>>
>> Tim
>>
>>
>>
>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
>>> Time for another update.
>>>
>>> The latest Intel processors, available only to data centers
>>> so far, have a built-in FPGA. This allows you to design
>>> your own circuits and have them loaded "on the fly",
>>> running in parallel with the CPU.
>>>
>>> I bought a Lattice ICEstick FPGA development board. For
>>> the first time there are open source tools that support it so
>>> it is a great test bench for ideas and development. It is a
>>> USB drive so it can be easily ported to any PC.
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesemi=
.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQz=
2HFhAAAymG-QswIjRao_YTwz4&e=3D
>>> )
>>>
>>> I also bought a large Intel Cyclone FPGA development board.
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com.=
tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW=
6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D
>>> )
>>> which has 2 embedded ARM processors. Unfortunately
>>> the tools (which are freely available) are not open source.
>>> It has sufficient size and power to do anything.
>>>
>>>
>>> I've got 2 threads of work in progress, both of which
>>> involve FPGAs (Field Programmable Gate Arrays).
>>>
>>> Thread 1
>>>
>>> The first thread involves proving programs correct. Once
>>> a proof has been made it is rather easier to check the proof.
>>> If code is shipped with a proof, the proof can be loaded into
>>> an FPGA running a proof-checker which verifies the program
>>> in parallel with running the code on the CPU.
>>>
>>> I am researching the question of writing a proof checker that
>>> runs on an FPGA, thus verifying the code "down to the metal".
>>> The Lean proof checker is the current target.
>>>
>>> The idea is to make "Oracle" algorithms that, because they
>>> are proven correct and verified at runtime, can be trusted
>>> by other mathematical software (e.g. Lean, Coq, Agda)
>>> when used in proofs.
>>>
>>> Thread 2
>>>
>>>
>>> The second thread involves arithmetic. Axiom currently ships
>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).
>>> These routines have a known set of numeric failures such as
>>> cancellation, underflow, and scaling.
>>>
>>> John Gustafson has designed a 'unum' numeric format that can
>>> eliminate many of these errors. (See
>>> Gustafson, John "The End of Error" CRC Press 2015
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_E=
nd-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F1=
-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D1=
593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZeP=
X0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0A=
&e=3D
>>> )
>>>
>>> The research goal is to implement Axiom's floating-point
>>> arithmetic that can be offloaded onto an FPGA implementing
>>> the unum format. Such a system would radically simplify
>>> the implementation of BLAS and LAPACK as most of the
>>> errors can't occur. The impact would be similar to using
>>> multi-precision integer arithmetic, only now its floating-point.
>>>
>>> SANE, the greater goal.
>>>
>>> The Axiom SANE compiler / interpreter can use both of
>>> these tools to implement trusted mathematical software.
>>> It's a long, ambitious research effort but even if only pieces
>>> of it succeed, it changes computational mathematics.
>>>
>>> Tim
>>>
>>> "A person's reach should exceed their grasp,
>>> or what's a computer for?"  (misquoting Robert Browning)
>>>
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.co=
m_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexcee=
d-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_O=
qsfcYl4z14qlYS02TBNmnaHUY&e=3D
>>> )
>>>
>>>
>>>
>>>
>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>> WHY PROVE AXIOM CORRECT (SANE)?
>>>>
>>>> Historically, Axiom credits CLU, the Cluster language by
>>>> Barbara Liskov, with the essential ideas behind the Spad
>>>> language. Barbara gave a talk (a partial transcript below)
>>>> that gives the rational behind the ``where clause'' used by
>>>> Spad.
>>>>
>>>> She talks about the limits of the compile time capablity.
>>>> In particular, she says:
>>>>
>>>>    To go further, where we would say that T,
>>>>    in addition, has to be an equality relation, that requires
>>>>    much more sophisticated techniques that, even today, are
>>>>    beyond the capabilities of the compiler.
>>>>
>>>> Showing that the ``equal'' function satisfies the equality
>>>> relation is no longer ``beyond the capabilities of the compiler''.
>>>> We have the required formalisms and mechanisms to
>>>> prove properties at compile time.
>>>>
>>>> The SANE effort is essentially trying to push compile
>>>> time checking into proving that, for categories that use
>>>> ``equal'', we prove that the equal function implements
>>>> equality.
>>>>
>>>> I strongly encourage you to watch her video.
>>>>
>>>> Tim
>>>>
>>>> Barbara Liskov
>>>> May 2012
>>>> MIT CSAIL
>>>> Programming the Turing Machine
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com=
_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1e=
GY&e=3D
>>>>
>>>> POLYMORPHISM
>>>>
>>>> We don't just want a set, we want polymorphism or
>>>> generics, as they are called today. We wanted to
>>>> have a generic set which was paramaterized by type
>>>> so you could instantiate it as:
>>>>
>>>> Set =3D [T:type] create, insert,...
>>>>   % representation for Set object
>>>>   % implementation of Set operations
>>>>   Set
>>>>
>>>> Set[int] s :=3D Set[int]$create()
>>>> Set[int]$insert(s,3)
>>>>
>>>> We wanted a static solution to this problem. The
>>>> problem is, not every type makes sense as a parameter
>>>> to Set of T. For sets, per se, you need an equality
>>>> relation. If it has been a sorted set we would have
>>>> some ordering relation. And a type that didn't have
>>>> one of those things would not have been a legitimate
>>>> parameter. We needed a way of expressing that in a
>>>> compile-time, checkable manner. Otherwise we would
>>>> have had to resort to runtime checking.
>>>>
>>>> Our solution was
>>>>
>>>> Set =3D [T:  ] create, insert,...
>>>>   T equal: (T,T) (bool)
>>>>
>>>>
>>>> Our solution, what we call the ``where clause''. So we
>>>> added this to the header. The ``where clause'' tells you
>>>> what operations the parameter type has to have.
>>>>
>>>> If you have the ``where'' clause you can do the static
>>>> checking because when you instantiate, when you provide
>>>> an actual type, the compiler can check that the type has
>>>> the operations that are required. And then, when you write
>>>> the implementation of Set the compiler knows it's ok to
>>>> call those operations because you can guarantee they are
>>>> actually there when you get around to running.
>>>>
>>>> Of course, you notice that there's just syntax here; there's
>>>> no semantics.
>>>>
>>>> As I'm sure you all know, compile-time type checking is
>>>> basically a proof technique of a very limited sort and
>>>> this was about as far as we can push what you could get out of the
>>>> static analysis. To go further, where we would say that T,
>>>> in addition, has to be an equality relation, that requires
>>>> much more sophisticated techniques that, even today, are
>>>> beyond the capabilities of the compiler.
>>>>
>>>>
>>>>
>>>>
>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> I've spent entirely too much time studing the legal issues
>>>>> of free and open source software. There are copyright,
>>>>> trademark, and intellectual property laws. I have read
>>>>> several books, listened to lectures, and read papers on
>>>>> the subject. I've spoken to lawyers about it. I've even
>>>>> been required, by law, to coerce people I respect.
>>>>> You would think it was all perfectly clear. It isn't.
>>>>>
>>>>> The most entertaining and enlightening lectures were
>>>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>>>> "The Semasiology of Open Source", which sounds
>>>>> horrible but I assure you, this is a real treat.
>>>>>
>>>>> THE THESIS
>>>>>
>>>>> Semasiology, n. The science of meanings or
>>>>> sense development (of words); the explanation
>>>>> of the development and changes of the meanings
>>>>> of words. Source: Webster's Revised Unabridged
>>>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>>>
>>>>> "Open source doesn't just mean access to the
>>>>> source code." So begins the Open Source Definition.
>>>>> What then, does access to the source code mean?
>>>>> Seen through the lens of an Enterprise user, what
>>>>> does open source mean? When is (or isn't) it
>>>>> significant? And a catalogue of open source
>>>>> related arbitrage opportunities.
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversa=
tionsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520o=
f-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZX=
HRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXN=
ZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnEb=
usM&e=3D
>>>>>
>>>>> Computer source code has words and sentence
>>>>> structure like actual prose or even poetry. Writing
>>>>> code for the computer is like writing an essay. It
>>>>> should be written for other people to read,
>>>>> understand and modify. These are some of the
>>>>> thoughts behind literate programming proposed
>>>>> by Donald Knuth. This is also one of the ideas
>>>>> behind Open Source.
>>>>>
>>>>>  THE ANTITHESIS
>>>>>
>>>>> "Open Source" is a phrase like "Object Oriented"
>>>>> - weird at first, but when it became popular, the
>>>>> meaning began to depend on the context of the
>>>>> speaker or listener. "Object Oriented" meant that
>>>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>>>> version of Cobol are all "Object Oriented" - for some
>>>>> specific definition of "Object Oriented". Similar is
>>>>> the case of the phrase "Open Source".
>>>>>
>>>>> In Part I, Lefkowitz talked about the shift of the
>>>>> meaning of "Open Source" away from any reference
>>>>> to the actual "source code," and more towards other
>>>>> phases of the software development life cycle. In
>>>>> Part II, he returns to the consideration of the
>>>>> relationship between "open source" and the actual
>>>>> "source code," and reflects upon both the way
>>>>> forward and the road behind, drawing inspiration
>>>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>>>> and others.
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversa=
tionsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ&=
c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ=
79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DLT=
gLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D
>>>>>
>>>>> THE SYNTHESIS
>>>>>
>>>>> In a fascinating synthesis, Robert =E2=80=9Cr0ml=E2=80=9D Lefkowitz
>>>>> polishes up his exposition on the evolving meaning
>>>>> of the term =E2=80=98open source=E2=80=99. This intellectual joy-ride
>>>>> draws on some of the key ideas in artificial intelligence
>>>>> to probe the role of language, meaning and context
>>>>> in computing and the software development process.
>>>>> Like Wittgenstein=E2=80=99s famous thought experiment, the
>>>>> open source =E2=80=98beetle in a box=E2=80=99 can represent different
>>>>> things to different people, bearing interesting fruit for
>>>>> philosophers and software creators alike.
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversatio=
nsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4Nma=
mNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMR=
xNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIwO=
N-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D
>>>>>
>>>>>
>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>>>> so far, is to push once a month on the 7th.
>>>>>>
>>>>>> After some chat room interactions it was brought home
>>>>>> again that the proof world really does not seem to like the
>>>>>> idea of proving programs correct. And, given that it was is
>>>>>> of the main Axiom goals and a point of friction during the fork,
>>>>>> the computer algebra world does not like the idea of proving
>>>>>> programs correct either.
>>>>>>
>>>>>> So the idea of "computational mathematics", which includes
>>>>>> both disciplines (as well as type theory) seems still a long
>>>>>> way off.
>>>>>>
>>>>>> Nevertheless, the primary change in these past and future
>>>>>> updates is focused on merging proof and computer algebra.
>>>>>>
>>>>>> Proof systems are able to split the problem of creating a
>>>>>> proof and the problem of verifying a proof, which is much
>>>>>> cheaper. Ideally the proof checker would run on verified
>>>>>> hardware so the proof is checked "down to the metal".
>>>>>>
>>>>>> I have a background in Field Programmable Gate Arrays
>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>>>> looking at creating a hardware proof checker using a
>>>>>> dedicated instruction set, one designed to be verifed.
>>>>>> New CPUs used in data centers (not yet available to us
>>>>>> mortals) have built-in FPGAs so it would be possible to
>>>>>> "side-load" a proof of a program to be checked while the
>>>>>> program is run. I have the FPGA and am doing a gate-level
>>>>>> special instruction design for such a proof checker.
>>>>>>
>>>>>>
>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>>>> mostly because it keeps muttering about Types. If you're not
>>>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>>>> seems pointless and painful.
>>>>>>>
>>>>>>> So Axiom has a steep learning curve.
>>>>>>>
>>>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>>>> to use a system like Axiom, mostly because you have to find
>>>>>>> or create "domains" or "packages", understand categories
>>>>>>> with their inheritance model, and learn a new language with
>>>>>>> a painful compiler always complaining about types.
>>>>>>>
>>>>>>> So Axiom has a steep learning curve.
>>>>>>>
>>>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>>>> It also assumes a background in type theory, inductive logic,
>>>>>>> homotopy type theory, ML (meta-language, not machine
>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>>>> and tacticals. Also assumed is knowledge of specification languages=
,
>>>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>>>> libraries of the same.
>>>>>>>
>>>>>>> So Axiom Sane has a steep learning curve.
>>>>>>>
>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>>>> learning to read the leading edge literature (also known
>>>>>>> as "greek studies", since every paper has pages of greek).
>>>>>>>
>>>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>>>> "computational mathematics" framework. I suspect that the only
>>>>>>> way this system will ever be useful is after Universities have a
>>>>>>> "Computational Mathematics" major course of study and degree.
>>>>>>>
>>>>>>> Creating a new department is harder than creating Axiom Sane
>>>>>>> because, you know, ... people.
>>>>>>>
>>>>>>> I think such a department is inevitable given the deep and wide
>>>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>>>> started programming there was no computer science degree.
>>>>>>>
>>>>>>> Somebody has to be the first lemming over the cliff.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>>>> there is a certain amount of verification that is involved.
>>>>>>>>
>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>>>>> computationally more efficient if Axiom and Lean use a cryptograph=
ic
>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be
>>>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>>>> computation request from Lean might involve many algorithms
>>>>>>>> there would be considerable overhead to recompute each proof.
>>>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>>>
>>>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>>>> information about the domain and range of a resulting formula.
>>>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>>>> SuchThat domain).
>>>>>>>>>
>>>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>>>> information is difficult if not impossible in the current system.
>>>>>>>>> The information isn't available and isn't computed. In that sense=
,
>>>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>>>
>>>>>>>>> In the Sane implementation the information is available. It is
>>>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>>>> careful design it will be possible to provide provisos for each
>>>>>>>>> given result that are carried with the result for use in further
>>>>>>>>> computation.
>>>>>>>>>
>>>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>>>> if the formula is defined over an interval, how is the interval
>>>>>>>>> arithmetic handled?
>>>>>>>>>
>>>>>>>>> Exciting research ahead!
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>>>
>>>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>>>> trust at all levels.
>>>>>>>>>>
>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>>>> trusted kernel through which all other computations must
>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>>>> something similar.
>>>>>>>>>>
>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>>>> the nucleus code.
>>>>>>>>>>
>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>>>> history of verifying hardware logic.
>>>>>>>>>>
>>>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>>>> form factor of a USB stick.
>>>>>>>>>>
>>>>>>>>>> Trust "down to the metal".
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>>>
>>>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>>>> the appropriate categories.
>>>>>>>>>>>
>>>>>>>>>>> But this is an interesting design question.
>>>>>>>>>>>
>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>>>> say, the Integer category.
>>>>>>>>>>>
>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>>>> ApproximateAttribute,
>>>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>>>
>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>>>
>>>>>>>>>>> An "axiom" category would also export a function. This function
>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would modif=
y
>>>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>>>
>>>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>>>
>>>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>>>
>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>>>
>>>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>>>> the same mechanism.
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.=
kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqO=
IDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5xs=
Nk1_eii0&e=3D
>>>>>>>>>>>> ) on
>>>>>>>>>>>> Seven deadly sins of talking about =E2=80=9Ctypes=E2=80=9D
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.=
kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62f=
Tbqv-K98dBQv0oMmB82kE8mXo&e=3D
>>>>>>>>>>>>
>>>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>>>
>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>>>
>>>>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>>>
>>>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are many goals. One of the primary goals is creating a
>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>>>>> error (links to where errors are defined), signatures (links =
to
>>>>>>>>>>>>> the signatures of lisp functions), figures (links to figures)=
,
>>>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>>>>> eventually define at least the syntax of the language. In the
>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>>>> not that clever.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>>>
>>>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>>>
>>>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>>>> Spad code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>>>> .
>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.and=
rew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6=
InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&=
m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx-=
3GFVk62hxr53YKr4naRk&e=3D
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>>>> The underlying technology to use for building such an algebr=
a
>>>>>>>>>>>>>> library
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>>>>> Theories:
>>>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.ca=
s.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryVe=
FoBjl0AZs2cuQZhKuIxk8NUw&e=3D
>>>>>>>>>>>>>> [which
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a
>>>>>>>>>>>>>> journal].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well document=
ed
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhas=
sy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html&=
d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sW=
EVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bD=
zgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (source at
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__githu=
b.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC=
6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc=
&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZBB5=
fBQOj0-Q48CUKRS1VNLao&e=3D
>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>> It
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> literate source.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__githu=
b.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tb=
VKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryq=
OIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITFQ=
RpkFBgg8c&e=3D
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it do=
es
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alha=
ssy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5F=
feature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0z=
its8pEczWsib7Q7_mxyRIxhk&e=3D
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>>>>> theories
>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> systems
>>>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas
>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It should =
be
>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like the
>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") develope=
d
>>>>>>>>>>>>>>>>> a dependently typed general parser for context free gramm=
ar
>>>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tim

\start
Date: Tue, 21 Jul 2020 17:36:32 +0000
From: William Sit <wsit@ccny.cuny.edu>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [EXTERNAL] Re: Axiom musings...

Dear Tim:=0A=
=0A=
You have expanded on the issues I raised. While you are right that a comput=
ational algorithm can be proved if the specifications are completely and pr=
ecisely coded for the proof systems like Coq. The catch is not the precisel=
y part but the completely part.=0A=
=0A=
Yes, I do remember we worked on the "symbolic integer" (or "symbolic polyno=
mial", etc.) domains. I think I might have actually some notes and ideas an=
d perhaps code, but it would take me more searching than I can do now from =
obsoleted and perhaps non-functional computers. A few days ago, I was tryin=
g to recover tex files from a Raspberry Pi that I used while in a hotel in =
China (2015), but nothing (meaning ftp and other transfer methods or even m=
ailing programs) works because of security. I have also forgotten all my kn=
owledge on Linux.=0A=
=0A=
Too bad we did not continue that effort. Does such a domain (in any compute=
r algebra system) exist these days? After all, nearly three decades have pa=
ssed.=0A=
=0A=
William=0A=
=0A=
William Sit=0A=
Professor Emeritus=0A=
Department of Mathematics=0A=
The City College of The City University of New York=0A=
New York, NY 10031=0A=
homepage: wsit.ccny.cuny.edu=0A=
=0A=
________________________________________=0A=
From: Tim Daly <axiomcas@gmail.com>=0A=
Sent: Monday, July 20, 2020 4:44 PM=0A=
To: William Sit=0A=
Cc: axiom-dev=0A=
Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
=0A=
> So there are two kinds of algorithms, one that is purely mathematical=0A=
> and one that is computational, the latter including a particular (class o=
f)=0A=
> data representation(s) (perhaps even the computer language and=0A=
> system of the implementation). It is proofs for the latter type of=0A=
> algorithms that is lacking.=0A=
=0A=
There are ,as you point out, several kinds of proofs to consider.=0A=
=0A=
One is the proof of the algorithm. An example is Buchberger's=0A=
Groebner Basis algorithm which was proven in Coq:=0A=
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ricam.oeaw.ac.at=
_specsem_srs_groeb_download_coq-2Dlinz.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6=
InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&=
m=3DqJcX0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3D48_B3YVCzXBpYUWOgsuSY0m=
MrrZd9SpQzWVZki-c6d4&e=3D=0A=
=0A=
The Coq proof establishes that the formal algorithm is correct.=0A=
=0A=
Even in proof one runs into limits of what can be proved. For example,=0A=
if the convergence is non-uniform one can, at best, do a proof that=0A=
assumes bounds on the non-uniform behavior. So this isn't strictly=0A=
a computer algorithm issue.=0A=
=0A=
> Since data representations (like REP in Axiom) are built recursively,=0A=
> a computational algorithm (in the sense above) for Groebner basis=0A=
> may have to be designed to take care of just a few of the ways=0A=
> integers can be represented. Axiom is built with that in mind (that's=0A=
> where type theory comes in), but I bet no one SPECIFIES their=0A=
> computational algorithms with the limitations of data representation=0A=
> in mind, much less proves the algorithm anew for each new=0A=
> representation.=0A=
=0A=
If you remember, while we were both at CCNY, I worked on a=0A=
grant project to construct a "symbolic integer" domain so that=0A=
computations could occur over non-numeric integers. The=0A=
symbolic form did not have a numeric limitation. Unfortunatly=0A=
the current Axiom has no way to support such a domain.=0A=
=0A=
I'm glad you brought this up. I will have to give some thought=0A=
to representing and computing with symbolic integers again.=0A=
=0A=
> So if a computation of a Groebner basis halts=0A=
> because of an intermediate LCM computation (say of two integer=0A=
> coefficients), should we consider the implementation as proven=0A=
> correct? What if the overflow condition was not detected and the=0A=
> computation continues? Indeed, since there may be different=0A=
> implementations of the integer domain, we must be sure that=0A=
> every implementation of the LCM algorithm handles overflows=0A=
> correctly AND specified in the documentation.=0A=
=0A=
Establishing that the algorithm is correct (e.g Groebner) is=0A=
clearly in the proof side of computational math=0A=
.=0A=
Establishing that there is an implementation of Groebner is=0A=
clearly in the computer algebra side of computational math.=0A=
=0A=
The game is to unite the two.=0A=
=0A=
Such a proof becomes a PART of the specification of a program=0A=
that implements the algorithm, such as in Axiom.=0A=
=0A=
The definitions and axioms of the proof have to be put into=0A=
the system both at the category and domain levels. They=0A=
need to be available at the implementation code.=0A=
=0A=
On the other hand, there are non-logical 'axioms' of=0A=
categories and domains, such as limits to the size of a=0A=
floating point number. One could have many FLOAT=0A=
domains, such as Gustafson's UNUMs.=0A=
https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.johngustafson.net=
_pdfs_BeatingFloatingPoint.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DqJcX0eyw=
VfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3Dwrah9xCIC0aDYjDhQgMxrQb_NM6HKkKp_Qb=
W91Vx4Y4&e=3D=0A=
=0A=
There are non-logical limits to the implementation, such as=0A=
intermediate expression swell that uses up all of memory.=0A=
It isn't possible to write a specification that can detect all of=0A=
these kinds of failures before they occur. But there are logical=0A=
ways to handle such boundaries.=0A=
=0A=
In logic there are 'product types' which are basically=0A=
multi-field records. There are 'sum types' which are disjoint=0A=
unions.=0A=
=0A=
Axiom's approach to reaching limits of computation is to=0A=
return a 'sum type' that is either the result or 'failed'. The=0A=
'failed' result needs to be explicitly carried in the proof.=0A=
Because 'failed' is a valid result, the specification can be=0A=
expanded to include this as a valid result.=0A=
=0A=
Just because a program can fail there is no reason to say=0A=
that it can't be proven, given that 'failed' is a valid result.=0A=
=0A=
One could even expand the sum types to include information=0A=
about the failure so that 'failed' would be a product type that=0A=
said why it failed. That allows another domain to be used.=0A=
In fact, one could introduce a FAILED domain in Axiom=0A=
with a 'why?' function. Local domains could extend FAILED=0A=
with their own 'why?' function specific to their possible=0A=
failures.=0A=
=0A=
Axiom has the ability to have muttiple domains that can=0A=
overcome limits, e.g. small floats, large floats, unums.=0A=
These would allow users to 'retry' a computation with=0A=
different assumptions.=0A=
=0A=
The issue you raise is important. Some algorithms in=0A=
Axiom have "hand-waving' specifications that need=0A=
to be expanded to properly return 'failed' when that is=0A=
expected. I think this is a 'good thing' and a useful=0A=
by-product of combining proof and computer algebra.=0A=
=0A=
Am I closer to understanding your objections?=0A=
=0A=
Tim=0A=
=0A=
=0A=
=0A=
On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
> Hi Tim:=0A=
>=0A=
> Perhaps I did not make myself clear in the short comment.=0A=
> What I wanted to say is that a data representation is not the same as the=
=0A=
> abstract mathematical objects because there are finite bounds on the=0A=
> representation. Take for example, an algorithm to compute the LCM of two=
=0A=
> integers. The LCM can cause overflow and not be representable. Of course,=
=0A=
> you can change the data representation to have "infinite precision", but=
=0A=
> that would still be bounded by actual physical memory of the machine. The=
=0A=
> careful programmer of the LCM algorithm would add throws and catches to=
=0A=
> handle the "error",but the implementation will have to add code that is n=
ot=0A=
> considered in the theoretical LCM algorithm (unless the LCM algorithm is=
=0A=
> meant for bounded integers of a fixed data representation and not abstrac=
t=0A=
> integers). So there are two kinds of algorithms, one that is purely=0A=
> mathematical and one that is computational, the latter including a=0A=
> particular (class of) data representation(s) (perhaps even the computer=
=0A=
> language and system of the implementation). It is proofs for the latter t=
ype=0A=
> of algorithms that is lacking. Since data representations (like REP in=0A=
> Axiom) are built recursively, a computational algorithm (in the sense abo=
ve)=0A=
> for Groebner basis may have to be designed to take care of just a few of =
the=0A=
> ways integers can be represented. Axiom is built with that in mind (that'=
s=0A=
> where type theory comes in), but I bet no one SPECIFIES their computation=
al=0A=
> algorithms with the limitations of data representation in mind, much less=
=0A=
> proves the algorithm anew for each new representation. So if a computatio=
n=0A=
> of a Groebner basis halts because of an intermediate LCM computation (say=
 of=0A=
> two integer coefficients), should we consider the implementation as prove=
n=0A=
> correct? What if the overflow condition was not detected and the computat=
ion=0A=
> continues? Indeed, since there may be different implementations of the=0A=
> integer domain, we must be sure that every implementation of the LCM=0A=
> algorithm handles overflows correctly AND specified in the documentation.=
=0A=
>=0A=
> I am sure I am just being ignorant to pose these questions, because they=
=0A=
> must have been considered and perhaps solved. In that case, please ignore=
=0A=
> them and just tell me so.=0A=
>=0A=
> William=0A=
>=0A=
> William Sit=0A=
> Professor Emeritus=0A=
> Department of Mathematics=0A=
> The City College of The City University of New York=0A=
> New York, NY 10031=0A=
> homepage: wsit.ccny.cuny.edu=0A=
>=0A=
> ________________________________________=0A=
> From: Tim Daly <axiomcas@gmail.com>=0A=
> Sent: Sunday, July 19, 2020 5:33 PM=0A=
> To: William Sit=0A=
> Cc: axiom-dev=0A=
> Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
>=0A=
> There are several "problems" with proving programs correct that=0A=
> I don't quite know how to solve, or even approach. But that's the=0A=
> fun of "research", right?=0A=
>=0A=
> For the data representation question I've been looking at types.=0A=
> I took 10 courses at CMU. I am eyebrow deep in type theory.=0A=
> I'm looking at category theory and homotopy type theory. So=0A=
> far I haven't seen anyone looking at the data problem. Most of=0A=
> the focus is on strict code typing.=0A=
>=0A=
> There is an old MIT course by Abelson and Sussman "Structure=0A=
> and Interpretation of Computer Programs" (SICP). They rewrite=0A=
> data as programs which, in Lisp, is trivial to do, Dan Friedman=0A=
> seems to have some interesting ideas too.=0A=
>=0A=
> All of Axiom's SANE types are now CLOS objects which gives=0A=
> two benefits. First, they can be inherited. But second, they=0A=
> are basically Lisp data structures with associated code.=0A=
>=0A=
> I'm thinking of associating "data axioms" with the representation=0A=
> (REP) object of a domain as well as with the functions.=0A=
>=0A=
> For example, DenavitHartenbergMatrix encodes 4x4 matrices=0A=
> used in graphics and robotics. They are 4x4 matrices where=0A=
> the upper left 3x3 encodes rotations, the right column encodes=0A=
> translations, and the lower row includes scaling, skewing, etc.=0A=
>=0A=
> (As an aside, DHMATRIX matrices have an associated=0A=
> Jacobian which encodes the dynamics in things like robots.=0A=
> Since I'm also programming a robot I'm tempted to work on=0A=
> extending the domain with related functions... but, as=0A=
> Hamming said, new algebra code isn't "the most important=0A=
> problem in computational mathematics").=0A=
>=0A=
> Axioms associated with the REP can assume that they are=0A=
> 4x4, that they can be inverted, that they have a "space" of=0A=
> rotations, etc. The axioms provide "facts" known to be true=0A=
> about the REP. (I also need to think about a "specification"=0A=
> for the REP but I'm not there yet).=0A=
>=0A=
> Since every category and domain is a CLOS data structure=0A=
> the DHMATRIX data structure inherits REP axioms from its=0A=
> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX=0A=
> adds domain-specific REP axioms (as well as domain-specific=0A=
> function axioms). Thus a DHMATRIX rotate function can=0A=
> base its proof on the fact that it only affects the upper 3x3=0A=
> and lives in a space of rotations, all of which can be assumed=0A=
> by the proof.=0A=
>=0A=
> If I use the SICP "trick" of representing data as code I can=0A=
> "expand" the data as part of the program proof.=0A=
>=0A=
> It is all Omphaloskepsis (navel gazing) at this point though.=0A=
> I'm still writing the new SANE compiler (which is wildly=0A=
> different from the compiler course I taught).=0A=
>=0A=
> I did give a talk at Notre Dame but I haven't attempted to=0A=
> publish. All of my work shows up in literate programming=0A=
> Axiom books on github.=0A=
> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly_P=
DFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcT=
vR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQIcL=
fvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D=0A=
> )=0A=
>=0A=
> It is all pretty pointless since nobody cares about computer=0A=
> algebra, proving math programs correct, or Axiom itself.=0A=
> Wolfram is taking up all the oxygen in the discussions.=0A=
>=0A=
> But I have to say, this research is great fun. It reminds me=0A=
> of the Scratchpad days, although I miss the give-and-take=0A=
> of the group. It is hard to recreate my role as the dumbest=0A=
> guy in the room when I'm stuck here by myself :-)=0A=
>=0A=
> Hope you and your family are safe and healthy.=0A=
>=0A=
> Tim=0A=
>=0A=
> PS. I think we should redefine the "Hamming Distance" as=0A=
> the distance between an idea and its implementation.=0A=
>=0A=
>=0A=
>=0A=
> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
>> Hi Tim:=0A=
>>=0A=
>> Glad to hear from you now and then, promoting and working towards your=
=0A=
>> ideas=0A=
>> and ideals.=0A=
>>=0A=
>>  >>We need proven algorithms.=0A=
>>=0A=
>> Just one short comment: it is often possible to prove algorithms (that i=
s,=0A=
>> providing the theoretical foundation for the algorithm), but it is much=
=0A=
>> harder to prove that an implementation of the algorithm is correct. As y=
ou=0A=
>> well know, the distinction lies in that implementation involves data=0A=
>> representations whereas proofs of algorithms normally ignore them.=0A=
>> Introducing (finite) data representations means introducing boundary=0A=
>> situations that a programmer implementing an algorithm must deal with. S=
o=0A=
>> perhaps what we need to prove should include the correctness of=0A=
>> implementations (to the bare metal, as you often say) and we should have=
 a=0A=
>> different set of analytic tools that can deal with the correctness (or=
=0A=
>> completeness) of data representations. Of course, these tools must also =
be=0A=
>> proven with the same rigor since behind every program is an algorithm.=
=0A=
>>=0A=
>> William=0A=
>>=0A=
>> William Sit=0A=
>> Professor Emeritus=0A=
>> Department of Mathematics=0A=
>> The City College of The City University of New York=0A=
>> New York, NY 10031=0A=
>> homepage: wsit.ccny.cuny.edu=0A=
>>=0A=
>> ________________________________________=0A=
>> From: Axiom-developer=0A=
>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behalf=
 of=0A=
>> Tim Daly <axiomcas@gmail.com>=0A=
>> Sent: Saturday, July 18, 2020 6:28 PM=0A=
>> To: axiom-dev; Tim Daly=0A=
>> Subject: [EXTERNAL] Re: Axiom musings...=0A=
>>=0A=
>> Richard Hamming gave a great talk. "You and Your Research"=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_w=
atch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZeP=
X0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0U=
&e=3D=0A=
>>=0A=
>> His big question is:=0A=
>>=0A=
>> "What is the most important problem in your field=0A=
>> and why aren't you working on it?"=0A=
>>=0A=
>> To my mind, the most important problem in the field of=0A=
>> computational mathematics is grounding computer=0A=
>> algebra in proofs.=0A=
>>=0A=
>> Computer mathematical algorithms that "maybe,=0A=
>> possibly, give correct answers sometimes" is a problem.=0A=
>> Indeed, for computer algebra, it is the most important=0A=
>> problem. We need proven algorithms.=0A=
>>=0A=
>> New algorithms, better graphics, better documentation,=0A=
>> are all "nice to have" but, as Hamming would say,=0A=
>> they are not "the most important problem".=0A=
>>=0A=
>> Tim=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>> Time for another update.=0A=
>>>=0A=
>>> The latest Intel processors, available only to data centers=0A=
>>> so far, have a built-in FPGA. This allows you to design=0A=
>>> your own circuits and have them loaded "on the fly",=0A=
>>> running in parallel with the CPU.=0A=
>>>=0A=
>>> I bought a Lattice ICEstick FPGA development board. For=0A=
>>> the first time there are open source tools that support it so=0A=
>>> it is a great test bench for ideas and development. It is a=0A=
>>> USB drive so it can be easily ported to any PC.=0A=
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesemi=
.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQz=
2HFhAAAymG-QswIjRao_YTwz4&e=3D=0A=
>>> )=0A=
>>>=0A=
>>> I also bought a large Intel Cyclone FPGA development board.=0A=
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com.=
tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW=
6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D=0A=
>>> )=0A=
>>> which has 2 embedded ARM processors. Unfortunately=0A=
>>> the tools (which are freely available) are not open source.=0A=
>>> It has sufficient size and power to do anything.=0A=
>>>=0A=
>>>=0A=
>>> I've got 2 threads of work in progress, both of which=0A=
>>> involve FPGAs (Field Programmable Gate Arrays).=0A=
>>>=0A=
>>> Thread 1=0A=
>>>=0A=
>>> The first thread involves proving programs correct. Once=0A=
>>> a proof has been made it is rather easier to check the proof.=0A=
>>> If code is shipped with a proof, the proof can be loaded into=0A=
>>> an FPGA running a proof-checker which verifies the program=0A=
>>> in parallel with running the code on the CPU.=0A=
>>>=0A=
>>> I am researching the question of writing a proof checker that=0A=
>>> runs on an FPGA, thus verifying the code "down to the metal".=0A=
>>> The Lean proof checker is the current target.=0A=
>>>=0A=
>>> The idea is to make "Oracle" algorithms that, because they=0A=
>>> are proven correct and verified at runtime, can be trusted=0A=
>>> by other mathematical software (e.g. Lean, Coq, Agda)=0A=
>>> when used in proofs.=0A=
>>>=0A=
>>> Thread 2=0A=
>>>=0A=
>>>=0A=
>>> The second thread involves arithmetic. Axiom currently ships=0A=
>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).=0A=
>>> These routines have a known set of numeric failures such as=0A=
>>> cancellation, underflow, and scaling.=0A=
>>>=0A=
>>> John Gustafson has designed a 'unum' numeric format that can=0A=
>>> eliminate many of these errors. (See=0A=
>>> Gustafson, John "The End of Error" CRC Press 2015=0A=
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_E=
nd-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F1=
-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D1=
593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZeP=
X0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0A=
&e=3D=0A=
>>> )=0A=
>>>=0A=
>>> The research goal is to implement Axiom's floating-point=0A=
>>> arithmetic that can be offloaded onto an FPGA implementing=0A=
>>> the unum format. Such a system would radically simplify=0A=
>>> the implementation of BLAS and LAPACK as most of the=0A=
>>> errors can't occur. The impact would be similar to using=0A=
>>> multi-precision integer arithmetic, only now its floating-point.=0A=
>>>=0A=
>>> SANE, the greater goal.=0A=
>>>=0A=
>>> The Axiom SANE compiler / interpreter can use both of=0A=
>>> these tools to implement trusted mathematical software.=0A=
>>> It's a long, ambitious research effort but even if only pieces=0A=
>>> of it succeed, it changes computational mathematics.=0A=
>>>=0A=
>>> Tim=0A=
>>>=0A=
>>> "A person's reach should exceed their grasp,=0A=
>>> or what's a computer for?"  (misquoting Robert Browning)=0A=
>>>=0A=
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.co=
m_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexcee=
d-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_O=
qsfcYl4z14qlYS02TBNmnaHUY&e=3D=0A=
>>> )=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>> WHY PROVE AXIOM CORRECT (SANE)?=0A=
>>>>=0A=
>>>> Historically, Axiom credits CLU, the Cluster language by=0A=
>>>> Barbara Liskov, with the essential ideas behind the Spad=0A=
>>>> language. Barbara gave a talk (a partial transcript below)=0A=
>>>> that gives the rational behind the ``where clause'' used by=0A=
>>>> Spad.=0A=
>>>>=0A=
>>>> She talks about the limits of the compile time capablity.=0A=
>>>> In particular, she says:=0A=
>>>>=0A=
>>>>    To go further, where we would say that T,=0A=
>>>>    in addition, has to be an equality relation, that requires=0A=
>>>>    much more sophisticated techniques that, even today, are=0A=
>>>>    beyond the capabilities of the compiler.=0A=
>>>>=0A=
>>>> Showing that the ``equal'' function satisfies the equality=0A=
>>>> relation is no longer ``beyond the capabilities of the compiler''.=0A=
>>>> We have the required formalisms and mechanisms to=0A=
>>>> prove properties at compile time.=0A=
>>>>=0A=
>>>> The SANE effort is essentially trying to push compile=0A=
>>>> time checking into proving that, for categories that use=0A=
>>>> ``equal'', we prove that the equal function implements=0A=
>>>> equality.=0A=
>>>>=0A=
>>>> I strongly encourage you to watch her video.=0A=
>>>>=0A=
>>>> Tim=0A=
>>>>=0A=
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
>>>> Barbara Liskov=0A=
>>>> May 2012=0A=
>>>> MIT CSAIL=0A=
>>>> Programming the Turing Machine=0A=
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com=
_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1e=
GY&e=3D=0A=
>>>>=0A=
>>>> POLYMORPHISM=0A=
>>>>=0A=
>>>> We don't just want a set, we want polymorphism or=0A=
>>>> generics, as they are called today. We wanted to=0A=
>>>> have a generic set which was paramaterized by type=0A=
>>>> so you could instantiate it as:=0A=
>>>>=0A=
>>>> Set =3D [T:type] create, insert,...=0A=
>>>>   % representation for Set object=0A=
>>>>   % implementation of Set operations=0A=
>>>>   Set=0A=
>>>>=0A=
>>>> Set[int] s :=3D Set[int]$create()=0A=
>>>> Set[int]$insert(s,3)=0A=
>>>>=0A=
>>>> We wanted a static solution to this problem. The=0A=
>>>> problem is, not every type makes sense as a parameter=0A=
>>>> to Set of T. For sets, per se, you need an equality=0A=
>>>> relation. If it has been a sorted set we would have=0A=
>>>> some ordering relation. And a type that didn't have=0A=
>>>> one of those things would not have been a legitimate=0A=
>>>> parameter. We needed a way of expressing that in a=0A=
>>>> compile-time, checkable manner. Otherwise we would=0A=
>>>> have had to resort to runtime checking.=0A=
>>>>=0A=
>>>> Our solution was=0A=
>>>>=0A=
>>>> Set =3D [T:  ] create, insert,...=0A=
>>>>   T equal: (T,T) (bool)=0A=
>>>>=0A=
>>>>=0A=
>>>> Our solution, what we call the ``where clause''. So we=0A=
>>>> added this to the header. The ``where clause'' tells you=0A=
>>>> what operations the parameter type has to have.=0A=
>>>>=0A=
>>>> If you have the ``where'' clause you can do the static=0A=
>>>> checking because when you instantiate, when you provide=0A=
>>>> an actual type, the compiler can check that the type has=0A=
>>>> the operations that are required. And then, when you write=0A=
>>>> the implementation of Set the compiler knows it's ok to=0A=
>>>> call those operations because you can guarantee they are=0A=
>>>> actually there when you get around to running.=0A=
>>>>=0A=
>>>> Of course, you notice that there's just syntax here; there's=0A=
>>>> no semantics.=0A=
>>>>=0A=
>>>> As I'm sure you all know, compile-time type checking is=0A=
>>>> basically a proof technique of a very limited sort and=0A=
>>>> this was about as far as we can push what you could get out of the=0A=
>>>> static analysis. To go further, where we would say that T,=0A=
>>>> in addition, has to be an equality relation, that requires=0A=
>>>> much more sophisticated techniques that, even today, are=0A=
>>>> beyond the capabilities of the compiler.=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>> I've spent entirely too much time studing the legal issues=0A=
>>>>> of free and open source software. There are copyright,=0A=
>>>>> trademark, and intellectual property laws. I have read=0A=
>>>>> several books, listened to lectures, and read papers on=0A=
>>>>> the subject. I've spoken to lawyers about it. I've even=0A=
>>>>> been required, by law, to coerce people I respect.=0A=
>>>>> You would think it was all perfectly clear. It isn't.=0A=
>>>>>=0A=
>>>>> The most entertaining and enlightening lectures were=0A=
>>>>> by Robert Lefkowitz at OSCON 2004. His talk is=0A=
>>>>> "The Semasiology of Open Source", which sounds=0A=
>>>>> horrible but I assure you, this is a real treat.=0A=
>>>>>=0A=
>>>>> THE THESIS=0A=
>>>>>=0A=
>>>>> Semasiology, n. The science of meanings or=0A=
>>>>> sense development (of words); the explanation=0A=
>>>>> of the development and changes of the meanings=0A=
>>>>> of words. Source: Webster's Revised Unabridged=0A=
>>>>> Dictionary, =EF=BF=BD 1996, 1998 MICRA, Inc.=0A=
>>>>>=0A=
>>>>> "Open source doesn't just mean access to the=0A=
>>>>> source code." So begins the Open Source Definition.=0A=
>>>>> What then, does access to the source code mean?=0A=
>>>>> Seen through the lens of an Enterprise user, what=0A=
>>>>> does open source mean? When is (or isn't) it=0A=
>>>>> significant? And a catalogue of open source=0A=
>>>>> related arbitrage opportunities.=0A=
>>>>>=0A=
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversa=
tionsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520o=
f-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZX=
HRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXN=
ZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnEb=
usM&e=3D=0A=
>>>>>=0A=
>>>>> Computer source code has words and sentence=0A=
>>>>> structure like actual prose or even poetry. Writing=0A=
>>>>> code for the computer is like writing an essay. It=0A=
>>>>> should be written for other people to read,=0A=
>>>>> understand and modify. These are some of the=0A=
>>>>> thoughts behind literate programming proposed=0A=
>>>>> by Donald Knuth. This is also one of the ideas=0A=
>>>>> behind Open Source.=0A=
>>>>>=0A=
>>>>>  THE ANTITHESIS=0A=
>>>>>=0A=
>>>>> "Open Source" is a phrase like "Object Oriented"=0A=
>>>>> - weird at first, but when it became popular, the=0A=
>>>>> meaning began to depend on the context of the=0A=
>>>>> speaker or listener. "Object Oriented" meant that=0A=
>>>>> PERL, C++, Java, Smalltalk, Basic and the newest=0A=
>>>>> version of Cobol are all "Object Oriented" - for some=0A=
>>>>> specific definition of "Object Oriented". Similar is=0A=
>>>>> the case of the phrase "Open Source".=0A=
>>>>>=0A=
>>>>> In Part I, Lefkowitz talked about the shift of the=0A=
>>>>> meaning of "Open Source" away from any reference=0A=
>>>>> to the actual "source code," and more towards other=0A=
>>>>> phases of the software development life cycle. In=0A=
>>>>> Part II, he returns to the consideration of the=0A=
>>>>> relationship between "open source" and the actual=0A=
>>>>> "source code," and reflects upon both the way=0A=
>>>>> forward and the road behind, drawing inspiration=0A=
>>>>> from Charlemagne, King Louis XIV, Donald Knuth,=0A=
>>>>> and others.=0A=
>>>>>=0A=
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conversa=
tionsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ&=
c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ=
79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DLT=
gLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D=0A=
>>>>>=0A=
>>>>> THE SYNTHESIS=0A=
>>>>>=0A=
>>>>> In a fascinating synthesis, Robert "r0ml" Lefkowitz=0A=
>>>>> polishes up his exposition on the evolving meaning=0A=
>>>>> of the term 'open source'. This intellectual joy-ride=0A=
>>>>> draws on some of the key ideas in artificial intelligence=0A=
>>>>> to probe the role of language, meaning and context=0A=
>>>>> in computing and the software development process.=0A=
>>>>> Like Wittgenstein's famous thought experiment, the=0A=
>>>>> open source 'beetle in a box' can represent different=0A=
>>>>> things to different people, bearing interesting fruit for=0A=
>>>>> philosophers and software creators alike.=0A=
>>>>>=0A=
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversatio=
nsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4Nma=
mNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMR=
xNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIwO=
N-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>> I've pushed the lastest version of Axiom. The plan, followed=0A=
>>>>>> so far, is to push once a month on the 7th.=0A=
>>>>>>=0A=
>>>>>> After some chat room interactions it was brought home=0A=
>>>>>> again that the proof world really does not seem to like the=0A=
>>>>>> idea of proving programs correct. And, given that it was is=0A=
>>>>>> of the main Axiom goals and a point of friction during the fork,=0A=
>>>>>> the computer algebra world does not like the idea of proving=0A=
>>>>>> programs correct either.=0A=
>>>>>>=0A=
>>>>>> So the idea of "computational mathematics", which includes=0A=
>>>>>> both disciplines (as well as type theory) seems still a long=0A=
>>>>>> way off.=0A=
>>>>>>=0A=
>>>>>> Nevertheless, the primary change in these past and future=0A=
>>>>>> updates is focused on merging proof and computer algebra.=0A=
>>>>>>=0A=
>>>>>> Proof systems are able to split the problem of creating a=0A=
>>>>>> proof and the problem of verifying a proof, which is much=0A=
>>>>>> cheaper. Ideally the proof checker would run on verified=0A=
>>>>>> hardware so the proof is checked "down to the metal".=0A=
>>>>>>=0A=
>>>>>> I have a background in Field Programmable Gate Arrays=0A=
>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm=0A=
>>>>>> looking at creating a hardware proof checker using a=0A=
>>>>>> dedicated instruction set, one designed to be verifed.=0A=
>>>>>> New CPUs used in data centers (not yet available to us=0A=
>>>>>> mortals) have built-in FPGAs so it would be possible to=0A=
>>>>>> "side-load" a proof of a program to be checked while the=0A=
>>>>>> program is run. I have the FPGA and am doing a gate-level=0A=
>>>>>> special instruction design for such a proof checker.=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>> As a mathematician, it is difficult to use a system like Axiom,=0A=
>>>>>>> mostly because it keeps muttering about Types. If you're not=0A=
>>>>>>> familiar with type theory (most mathematicians aren't) then it=0A=
>>>>>>> seems pointless and painful.=0A=
>>>>>>>=0A=
>>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>>=0A=
>>>>>>> As a mathematician with an algorithmic approach, it is difficult=0A=
>>>>>>> to use a system like Axiom, mostly because you have to find=0A=
>>>>>>> or create "domains" or "packages", understand categories=0A=
>>>>>>> with their inheritance model, and learn a new language with=0A=
>>>>>>> a painful compiler always complaining about types.=0A=
>>>>>>>=0A=
>>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>>=0A=
>>>>>>> The Sane version of Axiom requires knowing the mathematics.=0A=
>>>>>>> It also assumes a background in type theory, inductive logic,=0A=
>>>>>>> homotopy type theory, ML (meta-language, not machine=0A=
>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,=0A=
>>>>>>> and tacticals. Also assumed is knowledge of specification languages=
,=0A=
>>>>>>> Hoare triples, proof techniques, soundness, and completeness.=0A=
>>>>>>> Oh, and there is a whole new syntax and semantics added to=0A=
>>>>>>> specify definitions, axioms, and theorems, not to mention whole=0A=
>>>>>>> libraries of the same.=0A=
>>>>>>>=0A=
>>>>>>> So Axiom Sane has a steep learning curve.=0A=
>>>>>>>=0A=
>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years=0A=
>>>>>>> learning to read the leading edge literature (also known=0A=
>>>>>>> as "greek studies", since every paper has pages of greek).=0A=
>>>>>>>=0A=
>>>>>>> I'm trying to unify computer algebra and proof theory into a=0A=
>>>>>>> "computational mathematics" framework. I suspect that the only=0A=
>>>>>>> way this system will ever be useful is after Universities have a=0A=
>>>>>>> "Computational Mathematics" major course of study and degree.=0A=
>>>>>>>=0A=
>>>>>>> Creating a new department is harder than creating Axiom Sane=0A=
>>>>>>> because, you know, ... people.=0A=
>>>>>>>=0A=
>>>>>>> I think such a department is inevitable given the deep and wide=0A=
>>>>>>> impact of computers, just not in my lifetime. That's ok. When I=0A=
>>>>>>> started programming there was no computer science degree.=0A=
>>>>>>>=0A=
>>>>>>> Somebody has to be the first lemming over the cliff.=0A=
>>>>>>>=0A=
>>>>>>> Tim=0A=
>>>>>>>=0A=
>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)=0A=
>>>>>>>> there is a certain amount of verification that is involved.=0A=
>>>>>>>>=0A=
>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its=
=0A=
>>>>>>>> algorithms. Ideally, when a computation is requested from Lean=0A=
>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is=
=0A=
>>>>>>>> returned. Lean can the verify that the proof is valid. But it is=
=0A=
>>>>>>>> computationally more efficient if Axiom and Lean use a cryptograph=
ic=0A=
>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be=0A=
>>>>>>>> 'reproven', only a hash computation over the proof text needs to=
=0A=
>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be=
=0A=
>>>>>>>> exchanged without re-running the proof mechanism. Since a large=0A=
>>>>>>>> computation request from Lean might involve many algorithms=0A=
>>>>>>>> there would be considerable overhead to recompute each proof.=0A=
>>>>>>>> A hash simplifies the issue yet provides proof integrity.=0A=
>>>>>>>>=0A=
>>>>>>>> Tim=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'=0A=
>>>>>>>>>=0A=
>>>>>>>>> A computer algebra system ought to know and ought to provide=0A=
>>>>>>>>> information about the domain and range of a resulting formula.=0A=
>>>>>>>>> I've been pushing this effort since the 1980s (hence the=0A=
>>>>>>>>> SuchThat domain).=0A=
>>>>>>>>>=0A=
>>>>>>>>> It turns out that computing with, carrying, and combining this=0A=
>>>>>>>>> information is difficult if not impossible in the current system.=
=0A=
>>>>>>>>> The information isn't available and isn't computed. In that sense=
,=0A=
>>>>>>>>> the original Axiom system is 'showing its age'.=0A=
>>>>>>>>>=0A=
>>>>>>>>> In the Sane implementation the information is available. It is=0A=
>>>>>>>>> part of the specification and part of the proof steps. With a=0A=
>>>>>>>>> careful design it will be possible to provide provisos for each=
=0A=
>>>>>>>>> given result that are carried with the result for use in further=
=0A=
>>>>>>>>> computation.=0A=
>>>>>>>>>=0A=
>>>>>>>>> This raises interesting questions to be explored. For example,=0A=
>>>>>>>>> if the formula is defined over an interval, how is the interval=
=0A=
>>>>>>>>> arithmetic handled?=0A=
>>>>>>>>>=0A=
>>>>>>>>> Exciting research ahead!=0A=
>>>>>>>>>=0A=
>>>>>>>>> Tim=0A=
>>>>>>>>>=0A=
>>>>>>>>>=0A=
>>>>>>>>>=0A=
>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>> Trusted Kernel... all the way to the metal.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> While building a trusted computer algebra system, the=0A=
>>>>>>>>>> SANE version of Axiom, I've been looking at questions of=0A=
>>>>>>>>>> trust at all levels.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a=0A=
>>>>>>>>>> trusted kernel through which all other computations must=0A=
>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base=0A=
>>>>>>>>>> their kernel  on logic like the Calculus of Construction or=0A=
>>>>>>>>>> something similar.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a=0A=
>>>>>>>>>> nucleus) that separates the trust from the logic. The rules=0A=
>>>>>>>>>> for the logic can be specified as needed but checked by=0A=
>>>>>>>>>> the nucleus code.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)=0A=
>>>>>>>>>> that allow you to create your own hardware in a C-like=0A=
>>>>>>>>>> language (Verilog). It allows you to check the chip you build=0A=
>>>>>>>>>> all the way down to the transistor states. You can create=0A=
>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted=0A=
>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a=0A=
>>>>>>>>>> history of verifying hardware logic.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> It appears that, assuming I can understand Bauers=0A=
>>>>>>>>>> Andromeda system, it would be possible and not that hard=0A=
>>>>>>>>>> to implement a trusted kernel on an FPGA the size and=0A=
>>>>>>>>>> form factor of a USB stick.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Trust "down to the metal".=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Tim=0A=
>>>>>>>>>>=0A=
>>>>>>>>>>=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Recently I've been musing about methods to insert axioms=0A=
>>>>>>>>>>> into categories so they could be inherited like signatures.=0A=
>>>>>>>>>>> At the moment I've been thinking about adding axioms in=0A=
>>>>>>>>>>> the same way that signatures are written, adding them to=0A=
>>>>>>>>>>> the appropriate categories.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> But this is an interesting design question.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures=0A=
>>>>>>>>>>> from categories. That is, we can bet a plus signature from,=0A=
>>>>>>>>>>> say, the Integer category.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom=0A=
>>>>>>>>>>> inherits certain so-called "attributes", such as=0A=
>>>>>>>>>>> ApproximateAttribute,=0A=
>>>>>>>>>>> which implies that the results are only approximate.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive=0A=
>>>>>>>>>>> property by defining it in its own category. In fact, if we=0A=
>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,=0A=
>>>>>>>>>>> where each property has its own inheritable category,=0A=
>>>>>>>>>>> we can "mix and match" the axioms at will.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> An "axiom" category would also export a function. This function=
=0A=
>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would modif=
y=0A=
>>>>>>>>>>> the proof step by applying the function to the step.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Theorems would have the same structure.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> This allows theorems to be constructed at run time (since=0A=
>>>>>>>>>>> Axiom supports "First Class Dynamic Types".=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad=0A=
>>>>>>>>>>> language so that Spad statements (e.g. assignment) had=0A=
>>>>>>>>>>> proof-related properties. A range such as [1..10] would=0A=
>>>>>>>>>>> provide explicit bounds in a proof "by language definition".=0A=
>>>>>>>>>>> Defining the logical properties of language statements in=0A=
>>>>>>>>>>> this way would make it easier to construct proofs since the=0A=
>>>>>>>>>>> invariants would be partially constructed already.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> This design merges the computer algebra inheritance=0A=
>>>>>>>>>>> structure with the proof of algorithms structure, all under=0A=
>>>>>>>>>>> the same mechanism.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.=
kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqO=
IDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5xs=
Nk1_eii0&e=3D=0A=
>>>>>>>>>>>> ) on=0A=
>>>>>>>>>>>> Seven deadly sins of talking about "types"=0A=
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs.=
kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62f=
Tbqv-K98dBQv0oMmB82kE8mXo&e=3D=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> He raised an interesting idea toward the end of the essay=0A=
>>>>>>>>>>>> that type-checking could be done outside the compiler.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.=0A=
>>>>>>>>>>>> It would be possible to run a program over the source code=0A=
>>>>>>>>>>>> to collect the information and write a stand-alone type=0A=
>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Taken further I can think of several other kinds of checkers=
=0A=
>>>>>>>>>>>> (aka 'linters') that could be unbundled.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> It is certainly something to explore.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer=0A=
>>>>>>>>>>>>> blows of reality", to coin a phrase.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> There are many goals. One of the primary goals is creating a=
=0A=
>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> So the latest changes involved adding multiple index files.=
=0A=
>>>>>>>>>>>>> These are documentation (links to where terms are mentioned=
=0A=
>>>>>>>>>>>>> in the text), code (links to the implementation of things),=
=0A=
>>>>>>>>>>>>> error (links to where errors are defined), signatures (links =
to=0A=
>>>>>>>>>>>>> the signatures of lisp functions), figures (links to figures)=
,=0A=
>>>>>>>>>>>>> and separate category, domain, and package indexes.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"=0A=
>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of=0A=
>>>>>>>>>>>>> those diagrams follows immediately. Collectively these will=
=0A=
>>>>>>>>>>>>> eventually define at least the syntax of the language. In the=
=0A=
>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm=0A=
>>>>>>>>>>>>> not that clever.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Reality shows up with the curent constraint that the=0A=
>>>>>>>>>>>>> compiler should accept the current Spad language as=0A=
>>>>>>>>>>>>> closely as possible. Of course, plans are to include new=0A=
>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)=0A=
>>>>>>>>>>>>> but these are being postponed until "syntax complete".=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> All parse information is stored in a parse object, which=0A=
>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)=0A=
>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also=0A=
>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).=0A=
>>>>>>>>>>>>> It's types all the way down.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> These types are being used as 'signatures' for the=0A=
>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the=0A=
>>>>>>>>>>>>> compiler implementation as well as the Sane language.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> The parser is designed to "wrap around" so that the=0A=
>>>>>>>>>>>>> user-level output of a parse should be the user-level=0A=
>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"=0A=
>>>>>>>>>>>>> should make it easy to see that the parser properly=0A=
>>>>>>>>>>>>> parsed the user input.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> The parser is "first class" so it will be available at=0A=
>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct=0A=
>>>>>>>>>>>>> Spad code.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some=0A=
>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How=0A=
>>>>>>>>>>>>> this will happen is still in the land of design. This would=
=0A=
>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is=0A=
>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp=0A=
>>>>>>>>>>>>> functions (with CLOS types as signatures) would be=0A=
>>>>>>>>>>>>> avaiable for implementing Spad functions. This not=0A=
>>>>>>>>>>>>> only improves the efficiency, it would make the=0A=
>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.=0A=
>>>>>>>>>>>>> .=0A=
>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods=0A=
>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to=0A=
>>>>>>>>>>>>> know how little I know, especially that I need to know.=0A=
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.and=
rew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6=
InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&=
m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx-=
3GFVk62hxr53YKr4naRk&e=3D=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:=0A=
>>>>>>>>>>>>>> The underlying technology to use for building such an algebr=
a=0A=
>>>>>>>>>>>>>> library=0A=
>>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between=
=0A=
>>>>>>>>>>>>>> Theories:=0A=
>>>>>>>>>>>>>> Theory Presentation Combinators"=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.ca=
s.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryVe=
FoBjl0AZs2cuQZhKuIxk8NUw&e=3D=0A=
>>>>>>>>>>>>>> [which=0A=
>>>>>>>>>>>>>> will=0A=
>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a=
=0A=
>>>>>>>>>>>>>> journal].=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well document=
ed=0A=
>>>>>>>>>>>>>> at=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alhas=
sy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html&=
d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sW=
EVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bD=
zgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> (source at=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__githu=
b.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC=
6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc=
&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZBB5=
fBQOj0-Q48CUKRS1VNLao&e=3D=0A=
>>>>>>>>>>>>>> ).=0A=
>>>>>>>>>>>>>> It=0A=
>>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>>> literate source.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> The old prototype was hard to find - it is now at=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__githu=
b.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tb=
VKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryq=
OIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITFQ=
RpkFBgg8c&e=3D=0A=
>>>>>>>>>>>>>> .=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it do=
es=0A=
>>>>>>>>>>>>>> not=0A=
>>>>>>>>>>>>>> quite=0A=
>>>>>>>>>>>>>> function properly today, it is under repair.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"=0A=
>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alha=
ssy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5F=
feature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0z=
its8pEczWsib7Q7_mxyRIxhk&e=3D=0A=
>>>>>>>>>>>>>> )=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized=
=0A=
>>>>>>>>>>>>>> theories=0A=
>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all=0A=
>>>>>>>>>>>>>> current=0A=
>>>>>>>>>>>>>> systems=0A=
>>>>>>>>>>>>>> suffer from.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Jacques=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:=0A=
>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas=
=0A=
>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but=0A=
>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It should =
be=0A=
>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"=
=0A=
>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much=0A=
>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like the=
=0A=
>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports=
=0A=
>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU=0A=
>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just=0A=
>>>>>>>>>>>>>>>> another front-end language" supported by GCC.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)=0A=
>>>>>>>>>>>>>>>> make any decision about the runtime implementation.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") develope=
d=0A=
>>>>>>>>>>>>>>>>> a dependently typed general parser for context free gramm=
ar=0A=
>>>>>>>>>>>>>>>>> in Coq.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.=0A=
>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider=0A=
>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> Tim=0A=

\start
Date: Tue, 21 Jul 2020 19:34:29 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>
Subject: Re: [EXTERNAL] Re: Axiom musings...

> Yes, I do remember we worked on the "symbolic integer"
> (or "symbolic polynomial", etc.) domains.

Sadly only the idea survives.

I spent almost all of my time at that time trying to get a
version of Axiom to bootstrap. Starting Axiom, at the time,
required an already running version of Axiom (the NAG
version) and NAG would not let me distribute their code.

Building a self-booting version involved (among a lot of
other things) breaking circular definitions in the category
and domain hierarchy. That took several months and all
of my time (much to Baumslag's annoyance).

That effort also involved re-writing code from Norman's
Lisp back to Common Lisp (much to Norman's annoyance)

As a result, the free version of Axiom wasn't released until
about 2003 even though I got a copy in 2001. As part of my
employment agreement with CCNY they wouldn't make any
claim on Axiom and I would only work on it in my free time
unless Gilbert said otherwise. My work time was spent as
the Magnus lead developer and open sourcing it. Gilbert
eventually wanted Axiom and asked me to do it for work
also. That's what led to the grant proposal.

My thoughts on the subject of symbolic integers were, as a
consequence, only "paper experiments". I have several
thousand technical papers stacked in my office and library.
The CCNY notes are in there somewhere. Unfortunately,
every time I pick up a pile to search I find other things I
"need to know now" and get lost in that subject. It is like
trying to get a glass of water when the three gorges dam
burst.

It seems feasible to create a SYMINT Symbolic Integer
domain that used symbols rather than numbers for the
arithmetic, creating a ring that could be used by POLY.
Using SYMINT in SYMFRAC Symboiic Fraction would
provide a field that could be used by POLY.

The idea is still worth the effort but, as usual, I am deep
into rebuilding Axiom from the ground up. The issues I'm
struggling with now make the bootstrap effort look like a
weekend hack. Bootstrapping took about several months.
The current effort has taken 6 years so far. There is SO
much to know and I am a slow learner.

This is where I wish I had graduate students :-)

Tim


On 7/21/20, William Sit <wsit@ccny.cuny.edu> wrote:
> Dear Tim:
>
> You have expanded on the issues I raised. While you are right that a
> computational algorithm can be proved if the specifications are completel=
y
> and precisely coded for the proof systems like Coq. The catch is not the
> precisely part but the completely part.
>
> Yes, I do remember we worked on the "symbolic integer" (or "symbolic
> polynomial", etc.) domains. I think I might have actually some notes and
> ideas and perhaps code, but it would take me more searching than I can do
> now from obsoleted and perhaps non-functional computers. A few days ago, =
I
> was trying to recover tex files from a Raspberry Pi that I used while in =
a
> hotel in China (2015), but nothing (meaning ftp and other transfer method=
s
> or even mailing programs) works because of security. I have also forgotte=
n
> all my knowledge on Linux.
>
> Too bad we did not continue that effort. Does such a domain (in any compu=
ter
> algebra system) exist these days? After all, nearly three decades have
> passed.
>
> William
>
> William Sit
> Professor Emeritus
> Department of Mathematics
> The City College of The City University of New York
> New York, NY 10031
> homepage: wsit.ccny.cuny.edu
>
> ________________________________________
> From: Tim Daly <axiomcas@gmail.com>
> Sent: Monday, July 20, 2020 4:44 PM
> To: William Sit
> Cc: axiom-dev
> Subject: Re: [EXTERNAL] Re: Axiom musings...
>
>> So there are two kinds of algorithms, one that is purely mathematical
>> and one that is computational, the latter including a particular (class
>> of)
>> data representation(s) (perhaps even the computer language and
>> system of the implementation). It is proofs for the latter type of
>> algorithms that is lacking.
>
> There are ,as you point out, several kinds of proofs to consider.
>
> One is the proof of the algorithm. An example is Buchberger's
> Groebner Basis algorithm which was proven in Coq:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ricam.oeaw.ac.=
at_specsem_srs_groeb_download_coq-2Dlinz.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYI=
U&m=3DqJcX0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3D48_B3YVCzXBpYUWOgsuSY=
0mMrrZd9SpQzWVZki-c6d4&e=3D
>
> The Coq proof establishes that the formal algorithm is correct.
>
> Even in proof one runs into limits of what can be proved. For example,
> if the convergence is non-uniform one can, at best, do a proof that
> assumes bounds on the non-uniform behavior. So this isn't strictly
> a computer algorithm issue.
>
>> Since data representations (like REP in Axiom) are built recursively,
>> a computational algorithm (in the sense above) for Groebner basis
>> may have to be designed to take care of just a few of the ways
>> integers can be represented. Axiom is built with that in mind (that's
>> where type theory comes in), but I bet no one SPECIFIES their
>> computational algorithms with the limitations of data representation
>> in mind, much less proves the algorithm anew for each new
>> representation.
>
> If you remember, while we were both at CCNY, I worked on a
> grant project to construct a "symbolic integer" domain so that
> computations could occur over non-numeric integers. The
> symbolic form did not have a numeric limitation. Unfortunatly
> the current Axiom has no way to support such a domain.
>
> I'm glad you brought this up. I will have to give some thought
> to representing and computing with symbolic integers again.
>
>> So if a computation of a Groebner basis halts
>> because of an intermediate LCM computation (say of two integer
>> coefficients), should we consider the implementation as proven
>> correct? What if the overflow condition was not detected and the
>> computation continues? Indeed, since there may be different
>> implementations of the integer domain, we must be sure that
>> every implementation of the LCM algorithm handles overflows
>> correctly AND specified in the documentation.
>
> Establishing that the algorithm is correct (e.g Groebner) is
> clearly in the proof side of computational math
> .
> Establishing that there is an implementation of Groebner is
> clearly in the computer algebra side of computational math.
>
> The game is to unite the two.
>
> Such a proof becomes a PART of the specification of a program
> that implements the algorithm, such as in Axiom.
>
> The definitions and axioms of the proof have to be put into
> the system both at the category and domain levels. They
> need to be available at the implementation code.
>
> On the other hand, there are non-logical 'axioms' of
> categories and domains, such as limits to the size of a
> floating point number. One could have many FLOAT
> domains, such as Gustafson's UNUMs.
> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.johngustafson.n=
et_pdfs_BeatingFloatingPoint.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1t=
bVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DqJcX0e=
ywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3Dwrah9xCIC0aDYjDhQgMxrQb_NM6HKkKp_=
QbW91Vx4Y4&e=3D
>
> There are non-logical limits to the implementation, such as
> intermediate expression swell that uses up all of memory.
> It isn't possible to write a specification that can detect all of
> these kinds of failures before they occur. But there are logical
> ways to handle such boundaries.
>
> In logic there are 'product types' which are basically
> multi-field records. There are 'sum types' which are disjoint
> unions.
>
> Axiom's approach to reaching limits of computation is to
> return a 'sum type' that is either the result or 'failed'. The
> 'failed' result needs to be explicitly carried in the proof.
> Because 'failed' is a valid result, the specification can be
> expanded to include this as a valid result.
>
> Just because a program can fail there is no reason to say
> that it can't be proven, given that 'failed' is a valid result.
>
> One could even expand the sum types to include information
> about the failure so that 'failed' would be a product type that
> said why it failed. That allows another domain to be used.
> In fact, one could introduce a FAILED domain in Axiom
> with a 'why?' function. Local domains could extend FAILED
> with their own 'why?' function specific to their possible
> failures.
>
> Axiom has the ability to have muttiple domains that can
> overcome limits, e.g. small floats, large floats, unums.
> These would allow users to 'retry' a computation with
> different assumptions.
>
> The issue you raise is important. Some algorithms in
> Axiom have "hand-waving' specifications that need
> to be expanded to properly return 'failed' when that is
> expected. I think this is a 'good thing' and a useful
> by-product of combining proof and computer algebra.
>
> Am I closer to understanding your objections?
>
> Tim
>
>
>
> On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:
>> Hi Tim:
>>
>> Perhaps I did not make myself clear in the short comment.
>> What I wanted to say is that a data representation is not the same as th=
e
>> abstract mathematical objects because there are finite bounds on the
>> representation. Take for example, an algorithm to compute the LCM of two
>> integers. The LCM can cause overflow and not be representable. Of course=
,
>> you can change the data representation to have "infinite precision", but
>> that would still be bounded by actual physical memory of the machine. Th=
e
>> careful programmer of the LCM algorithm would add throws and catches to
>> handle the "error",but the implementation will have to add code that is
>> not
>> considered in the theoretical LCM algorithm (unless the LCM algorithm is
>> meant for bounded integers of a fixed data representation and not abstra=
ct
>> integers). So there are two kinds of algorithms, one that is purely
>> mathematical and one that is computational, the latter including a
>> particular (class of) data representation(s) (perhaps even the computer
>> language and system of the implementation). It is proofs for the latter
>> type
>> of algorithms that is lacking. Since data representations (like REP in
>> Axiom) are built recursively, a computational algorithm (in the sense
>> above)
>> for Groebner basis may have to be designed to take care of just a few of
>> the
>> ways integers can be represented. Axiom is built with that in mind (that=
's
>> where type theory comes in), but I bet no one SPECIFIES their
>> computational
>> algorithms with the limitations of data representation in mind, much les=
s
>> proves the algorithm anew for each new representation. So if a computati=
on
>> of a Groebner basis halts because of an intermediate LCM computation (sa=
y
>> of
>> two integer coefficients), should we consider the implementation as prov=
en
>> correct? What if the overflow condition was not detected and the
>> computation
>> continues? Indeed, since there may be different implementations of the
>> integer domain, we must be sure that every implementation of the LCM
>> algorithm handles overflows correctly AND specified in the documentation=
.
>>
>> I am sure I am just being ignorant to pose these questions, because they
>> must have been considered and perhaps solved. In that case, please ignor=
e
>> them and just tell me so.
>>
>> William
>>
>> William Sit
>> Professor Emeritus
>> Department of Mathematics
>> The City College of The City University of New York
>> New York, NY 10031
>> homepage: wsit.ccny.cuny.edu
>>
>> ________________________________________
>> From: Tim Daly <axiomcas@gmail.com>
>> Sent: Sunday, July 19, 2020 5:33 PM
>> To: William Sit
>> Cc: axiom-dev
>> Subject: Re: [EXTERNAL] Re: Axiom musings...
>>
>> There are several "problems" with proving programs correct that
>> I don't quite know how to solve, or even approach. But that's the
>> fun of "research", right?
>>
>> For the data representation question I've been looking at types.
>> I took 10 courses at CMU. I am eyebrow deep in type theory.
>> I'm looking at category theory and homotopy type theory. So
>> far I haven't seen anyone looking at the data problem. Most of
>> the focus is on strict code typing.
>>
>> There is an old MIT course by Abelson and Sussman "Structure
>> and Interpretation of Computer Programs" (SICP). They rewrite
>> data as programs which, in Lisp, is trivial to do, Dan Friedman
>> seems to have some interesting ideas too.
>>
>> All of Axiom's SANE types are now CLOS objects which gives
>> two benefits. First, they can be inherited. But second, they
>> are basically Lisp data structures with associated code.
>>
>> I'm thinking of associating "data axioms" with the representation
>> (REP) object of a domain as well as with the functions.
>>
>> For example, DenavitHartenbergMatrix encodes 4x4 matrices
>> used in graphics and robotics. They are 4x4 matrices where
>> the upper left 3x3 encodes rotations, the right column encodes
>> translations, and the lower row includes scaling, skewing, etc.
>>
>> (As an aside, DHMATRIX matrices have an associated
>> Jacobian which encodes the dynamics in things like robots.
>> Since I'm also programming a robot I'm tempted to work on
>> extending the domain with related functions... but, as
>> Hamming said, new algebra code isn't "the most important
>> problem in computational mathematics").
>>
>> Axioms associated with the REP can assume that they are
>> 4x4, that they can be inverted, that they have a "space" of
>> rotations, etc. The axioms provide "facts" known to be true
>> about the REP. (I also need to think about a "specification"
>> for the REP but I'm not there yet).
>>
>> Since every category and domain is a CLOS data structure
>> the DHMATRIX data structure inherits REP axioms from its
>> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX
>> adds domain-specific REP axioms (as well as domain-specific
>> function axioms). Thus a DHMATRIX rotate function can
>> base its proof on the fact that it only affects the upper 3x3
>> and lives in a space of rotations, all of which can be assumed
>> by the proof.
>>
>> If I use the SICP "trick" of representing data as code I can
>> "expand" the data as part of the program proof.
>>
>> It is all Omphaloskepsis (navel gazing) at this point though.
>> I'm still writing the new SANE compiler (which is wildly
>> different from the compiler course I taught).
>>
>> I did give a talk at Notre Dame but I haven't attempted to
>> publish. All of my work shows up in literate programming
>> Axiom books on github.
>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly_=
PDFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwc=
TvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQIc=
LfvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D
>> )
>>
>> It is all pretty pointless since nobody cares about computer
>> algebra, proving math programs correct, or Axiom itself.
>> Wolfram is taking up all the oxygen in the discussions.
>>
>> But I have to say, this research is great fun. It reminds me
>> of the Scratchpad days, although I miss the give-and-take
>> of the group. It is hard to recreate my role as the dumbest
>> guy in the room when I'm stuck here by myself :-)
>>
>> Hope you and your family are safe and healthy.
>>
>> Tim
>>
>> PS. I think we should redefine the "Hamming Distance" as
>> the distance between an idea and its implementation.
>>
>>
>>
>> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>> Hi Tim:
>>>
>>> Glad to hear from you now and then, promoting and working towards your
>>> ideas
>>> and ideals.
>>>
>>>  >>We need proven algorithms.
>>>
>>> Just one short comment: it is often possible to prove algorithms (that
>>> is,
>>> providing the theoretical foundation for the algorithm), but it is much
>>> harder to prove that an implementation of the algorithm is correct. As
>>> you
>>> well know, the distinction lies in that implementation involves data
>>> representations whereas proofs of algorithms normally ignore them.
>>> Introducing (finite) data representations means introducing boundary
>>> situations that a programmer implementing an algorithm must deal with. =
So
>>> perhaps what we need to prove should include the correctness of
>>> implementations (to the bare metal, as you often say) and we should hav=
e
>>> a
>>> different set of analytic tools that can deal with the correctness (or
>>> completeness) of data representations. Of course, these tools must also
>>> be
>>> proven with the same rigor since behind every program is an algorithm.
>>>
>>> William
>>>
>>> William Sit
>>> Professor Emeritus
>>> Department of Mathematics
>>> The City College of The City University of New York
>>> New York, NY 10031
>>> homepage: wsit.ccny.cuny.edu
>>>
>>> ________________________________________
>>> From: Axiom-developer
>>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behal=
f of
>>> Tim Daly <axiomcas@gmail.com>
>>> Sent: Saturday, July 18, 2020 6:28 PM
>>> To: axiom-dev; Tim Daly
>>> Subject: [EXTERNAL] Re: Axiom musings...
>>>
>>> Richard Hamming gave a great talk. "You and Your Research"
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_=
watch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZe=
PX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm0=
U&e=3D
>>>
>>> His big question is:
>>>
>>> "What is the most important problem in your field
>>> and why aren't you working on it?"
>>>
>>> To my mind, the most important problem in the field of
>>> computational mathematics is grounding computer
>>> algebra in proofs.
>>>
>>> Computer mathematical algorithms that "maybe,
>>> possibly, give correct answers sometimes" is a problem.
>>> Indeed, for computer algebra, it is the most important
>>> problem. We need proven algorithms.
>>>
>>> New algorithms, better graphics, better documentation,
>>> are all "nice to have" but, as Hamming would say,
>>> they are not "the most important problem".
>>>
>>> Tim
>>>
>>>
>>>
>>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>> Time for another update.
>>>>
>>>> The latest Intel processors, available only to data centers
>>>> so far, have a built-in FPGA. This allows you to design
>>>> your own circuits and have them loaded "on the fly",
>>>> running in parallel with the CPU.
>>>>
>>>> I bought a Lattice ICEstick FPGA development board. For
>>>> the first time there are open source tools that support it so
>>>> it is a great test bench for ideas and development. It is a
>>>> USB drive so it can be easily ported to any PC.
>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticesem=
i.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbutQ=
z2HFhAAAymG-QswIjRao_YTwz4&e=3D
>>>> )
>>>>
>>>> I also bought a large Intel Cyclone FPGA development board.
>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.com=
.tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW=
6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D
>>>> )
>>>> which has 2 embedded ARM processors. Unfortunately
>>>> the tools (which are freely available) are not open source.
>>>> It has sufficient size and power to do anything.
>>>>
>>>>
>>>> I've got 2 threads of work in progress, both of which
>>>> involve FPGAs (Field Programmable Gate Arrays).
>>>>
>>>> Thread 1
>>>>
>>>> The first thread involves proving programs correct. Once
>>>> a proof has been made it is rather easier to check the proof.
>>>> If code is shipped with a proof, the proof can be loaded into
>>>> an FPGA running a proof-checker which verifies the program
>>>> in parallel with running the code on the CPU.
>>>>
>>>> I am researching the question of writing a proof checker that
>>>> runs on an FPGA, thus verifying the code "down to the metal".
>>>> The Lean proof checker is the current target.
>>>>
>>>> The idea is to make "Oracle" algorithms that, because they
>>>> are proven correct and verified at runtime, can be trusted
>>>> by other mathematical software (e.g. Lean, Coq, Agda)
>>>> when used in proofs.
>>>>
>>>> Thread 2
>>>>
>>>>
>>>> The second thread involves arithmetic. Axiom currently ships
>>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).
>>>> These routines have a known set of numeric failures such as
>>>> cancellation, underflow, and scaling.
>>>>
>>>> John Gustafson has designed a 'unum' numeric format that can
>>>> eliminate many of these errors. (See
>>>> Gustafson, John "The End of Error" CRC Press 2015
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com_=
End-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5F=
1-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3D=
1593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZe=
PX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa0=
A&e=3D
>>>> )
>>>>
>>>> The research goal is to implement Axiom's floating-point
>>>> arithmetic that can be offloaded onto an FPGA implementing
>>>> the unum format. Such a system would radically simplify
>>>> the implementation of BLAS and LAPACK as most of the
>>>> errors can't occur. The impact would be similar to using
>>>> multi-precision integer arithmetic, only now its floating-point.
>>>>
>>>> SANE, the greater goal.
>>>>
>>>> The Axiom SANE compiler / interpreter can use both of
>>>> these tools to implement trusted mathematical software.
>>>> It's a long, ambitious research effort but even if only pieces
>>>> of it succeed, it changes computational mathematics.
>>>>
>>>> Tim
>>>>
>>>> "A person's reach should exceed their grasp,
>>>> or what's a computer for?"  (misquoting Robert Browning)
>>>>
>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.c=
om_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexce=
ed-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx_=
OqsfcYl4z14qlYS02TBNmnaHUY&e=3D
>>>> )
>>>>
>>>>
>>>>
>>>>
>>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> WHY PROVE AXIOM CORRECT (SANE)?
>>>>>
>>>>> Historically, Axiom credits CLU, the Cluster language by
>>>>> Barbara Liskov, with the essential ideas behind the Spad
>>>>> language. Barbara gave a talk (a partial transcript below)
>>>>> that gives the rational behind the ``where clause'' used by
>>>>> Spad.
>>>>>
>>>>> She talks about the limits of the compile time capablity.
>>>>> In particular, she says:
>>>>>
>>>>>    To go further, where we would say that T,
>>>>>    in addition, has to be an equality relation, that requires
>>>>>    much more sophisticated techniques that, even today, are
>>>>>    beyond the capabilities of the compiler.
>>>>>
>>>>> Showing that the ``equal'' function satisfies the equality
>>>>> relation is no longer ``beyond the capabilities of the compiler''.
>>>>> We have the required formalisms and mechanisms to
>>>>> prove properties at compile time.
>>>>>
>>>>> The SANE effort is essentially trying to push compile
>>>>> time checking into proving that, for categories that use
>>>>> ``equal'', we prove that the equal function implements
>>>>> equality.
>>>>>
>>>>> I strongly encourage you to watch her video.
>>>>>
>>>>> Tim
>>>>>
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>> Barbara Liskov
>>>>> May 2012
>>>>> MIT CSAIL
>>>>> Programming the Turing Machine
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.co=
m_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZX=
HRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXN=
ZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS1=
eGY&e=3D
>>>>>
>>>>> POLYMORPHISM
>>>>>
>>>>> We don't just want a set, we want polymorphism or
>>>>> generics, as they are called today. We wanted to
>>>>> have a generic set which was paramaterized by type
>>>>> so you could instantiate it as:
>>>>>
>>>>> Set =3D [T:type] create, insert,...
>>>>>   % representation for Set object
>>>>>   % implementation of Set operations
>>>>>   Set
>>>>>
>>>>> Set[int] s :=3D Set[int]$create()
>>>>> Set[int]$insert(s,3)
>>>>>
>>>>> We wanted a static solution to this problem. The
>>>>> problem is, not every type makes sense as a parameter
>>>>> to Set of T. For sets, per se, you need an equality
>>>>> relation. If it has been a sorted set we would have
>>>>> some ordering relation. And a type that didn't have
>>>>> one of those things would not have been a legitimate
>>>>> parameter. We needed a way of expressing that in a
>>>>> compile-time, checkable manner. Otherwise we would
>>>>> have had to resort to runtime checking.
>>>>>
>>>>> Our solution was
>>>>>
>>>>> Set =3D [T:  ] create, insert,...
>>>>>   T equal: (T,T) (bool)
>>>>>
>>>>>
>>>>> Our solution, what we call the ``where clause''. So we
>>>>> added this to the header. The ``where clause'' tells you
>>>>> what operations the parameter type has to have.
>>>>>
>>>>> If you have the ``where'' clause you can do the static
>>>>> checking because when you instantiate, when you provide
>>>>> an actual type, the compiler can check that the type has
>>>>> the operations that are required. And then, when you write
>>>>> the implementation of Set the compiler knows it's ok to
>>>>> call those operations because you can guarantee they are
>>>>> actually there when you get around to running.
>>>>>
>>>>> Of course, you notice that there's just syntax here; there's
>>>>> no semantics.
>>>>>
>>>>> As I'm sure you all know, compile-time type checking is
>>>>> basically a proof technique of a very limited sort and
>>>>> this was about as far as we can push what you could get out of the
>>>>> static analysis. To go further, where we would say that T,
>>>>> in addition, has to be an equality relation, that requires
>>>>> much more sophisticated techniques that, even today, are
>>>>> beyond the capabilities of the compiler.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> I've spent entirely too much time studing the legal issues
>>>>>> of free and open source software. There are copyright,
>>>>>> trademark, and intellectual property laws. I have read
>>>>>> several books, listened to lectures, and read papers on
>>>>>> the subject. I've spoken to lawyers about it. I've even
>>>>>> been required, by law, to coerce people I respect.
>>>>>> You would think it was all perfectly clear. It isn't.
>>>>>>
>>>>>> The most entertaining and enlightening lectures were
>>>>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>>>>> "The Semasiology of Open Source", which sounds
>>>>>> horrible but I assure you, this is a real treat.
>>>>>>
>>>>>> THE THESIS
>>>>>>
>>>>>> Semasiology, n. The science of meanings or
>>>>>> sense development (of words); the explanation
>>>>>> of the development and changes of the meanings
>>>>>> of words. Source: Webster's Revised Unabridged
>>>>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>>>>
>>>>>> "Open source doesn't just mean access to the
>>>>>> source code." So begins the Open Source Definition.
>>>>>> What then, does access to the source code mean?
>>>>>> Seen through the lens of an Enterprise user, what
>>>>>> does open source mean? When is (or isn't) it
>>>>>> significant? And a catalogue of open source
>>>>>> related arbitrage opportunities.
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.convers=
ationsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-2520=
of-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZ=
XHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfX=
NZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcnE=
busM&e=3D
>>>>>>
>>>>>> Computer source code has words and sentence
>>>>>> structure like actual prose or even poetry. Writing
>>>>>> code for the computer is like writing an essay. It
>>>>>> should be written for other people to read,
>>>>>> understand and modify. These are some of the
>>>>>> thoughts behind literate programming proposed
>>>>>> by Donald Knuth. This is also one of the ideas
>>>>>> behind Open Source.
>>>>>>
>>>>>>  THE ANTITHESIS
>>>>>>
>>>>>> "Open Source" is a phrase like "Object Oriented"
>>>>>> - weird at first, but when it became popular, the
>>>>>> meaning began to depend on the context of the
>>>>>> speaker or listener. "Object Oriented" meant that
>>>>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>>>>> version of Cobol are all "Object Oriented" - for some
>>>>>> specific definition of "Object Oriented". Similar is
>>>>>> the case of the phrase "Open Source".
>>>>>>
>>>>>> In Part I, Lefkowitz talked about the shift of the
>>>>>> meaning of "Open Source" away from any reference
>>>>>> to the actual "source code," and more towards other
>>>>>> phases of the software development life cycle. In
>>>>>> Part II, he returns to the consideration of the
>>>>>> relationship between "open source" and the actual
>>>>>> "source code," and reflects upon both the way
>>>>>> forward and the road behind, drawing inspiration
>>>>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>>>>> and others.
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.convers=
ationsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFaQ=
&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWY=
Z79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DL=
TgLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D
>>>>>>
>>>>>> THE SYNTHESIS
>>>>>>
>>>>>> In a fascinating synthesis, Robert "r0ml" Lefkowitz
>>>>>> polishes up his exposition on the evolving meaning
>>>>>> of the term 'open source'. This intellectual joy-ride
>>>>>> draws on some of the key ideas in artificial intelligence
>>>>>> to probe the role of language, meaning and context
>>>>>> in computing and the software development process.
>>>>>> Like Wittgenstein's famous thought experiment, the
>>>>>> open source 'beetle in a box' can represent different
>>>>>> things to different people, bearing interesting fruit for
>>>>>> philosophers and software creators alike.
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversati=
onsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4Nm=
amNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWM=
RxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoIw=
ON-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D
>>>>>>
>>>>>>
>>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>>>>> so far, is to push once a month on the 7th.
>>>>>>>
>>>>>>> After some chat room interactions it was brought home
>>>>>>> again that the proof world really does not seem to like the
>>>>>>> idea of proving programs correct. And, given that it was is
>>>>>>> of the main Axiom goals and a point of friction during the fork,
>>>>>>> the computer algebra world does not like the idea of proving
>>>>>>> programs correct either.
>>>>>>>
>>>>>>> So the idea of "computational mathematics", which includes
>>>>>>> both disciplines (as well as type theory) seems still a long
>>>>>>> way off.
>>>>>>>
>>>>>>> Nevertheless, the primary change in these past and future
>>>>>>> updates is focused on merging proof and computer algebra.
>>>>>>>
>>>>>>> Proof systems are able to split the problem of creating a
>>>>>>> proof and the problem of verifying a proof, which is much
>>>>>>> cheaper. Ideally the proof checker would run on verified
>>>>>>> hardware so the proof is checked "down to the metal".
>>>>>>>
>>>>>>> I have a background in Field Programmable Gate Arrays
>>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>>>>> looking at creating a hardware proof checker using a
>>>>>>> dedicated instruction set, one designed to be verifed.
>>>>>>> New CPUs used in data centers (not yet available to us
>>>>>>> mortals) have built-in FPGAs so it would be possible to
>>>>>>> "side-load" a proof of a program to be checked while the
>>>>>>> program is run. I have the FPGA and am doing a gate-level
>>>>>>> special instruction design for such a proof checker.
>>>>>>>
>>>>>>>
>>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>>>>> mostly because it keeps muttering about Types. If you're not
>>>>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>>>>> seems pointless and painful.
>>>>>>>>
>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>
>>>>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>>>>> to use a system like Axiom, mostly because you have to find
>>>>>>>> or create "domains" or "packages", understand categories
>>>>>>>> with their inheritance model, and learn a new language with
>>>>>>>> a painful compiler always complaining about types.
>>>>>>>>
>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>
>>>>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>>>>> It also assumes a background in type theory, inductive logic,
>>>>>>>> homotopy type theory, ML (meta-language, not machine
>>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>>>>> and tacticals. Also assumed is knowledge of specification language=
s,
>>>>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>>>>> libraries of the same.
>>>>>>>>
>>>>>>>> So Axiom Sane has a steep learning curve.
>>>>>>>>
>>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>>>>> learning to read the leading edge literature (also known
>>>>>>>> as "greek studies", since every paper has pages of greek).
>>>>>>>>
>>>>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>>>>> "computational mathematics" framework. I suspect that the only
>>>>>>>> way this system will ever be useful is after Universities have a
>>>>>>>> "Computational Mathematics" major course of study and degree.
>>>>>>>>
>>>>>>>> Creating a new department is harder than creating Axiom Sane
>>>>>>>> because, you know, ... people.
>>>>>>>>
>>>>>>>> I think such a department is inevitable given the deep and wide
>>>>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>>>>> started programming there was no computer science degree.
>>>>>>>>
>>>>>>>> Somebody has to be the first lemming over the cliff.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>>>>> there is a certain amount of verification that is involved.
>>>>>>>>>
>>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>>>>>> computationally more efficient if Axiom and Lean use a
>>>>>>>>> cryptographic
>>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to be
>>>>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>>>>> computation request from Lean might involve many algorithms
>>>>>>>>> there would be considerable overhead to recompute each proof.
>>>>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>>>>
>>>>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>>>>> information about the domain and range of a resulting formula.
>>>>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>>>>> SuchThat domain).
>>>>>>>>>>
>>>>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>>>>> information is difficult if not impossible in the current system=
.
>>>>>>>>>> The information isn't available and isn't computed. In that sens=
e,
>>>>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>>>>
>>>>>>>>>> In the Sane implementation the information is available. It is
>>>>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>>>>> careful design it will be possible to provide provisos for each
>>>>>>>>>> given result that are carried with the result for use in further
>>>>>>>>>> computation.
>>>>>>>>>>
>>>>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>>>>> if the formula is defined over an interval, how is the interval
>>>>>>>>>> arithmetic handled?
>>>>>>>>>>
>>>>>>>>>> Exciting research ahead!
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>>>>
>>>>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>>>>> trust at all levels.
>>>>>>>>>>>
>>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>>>>> trusted kernel through which all other computations must
>>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>>>>> something similar.
>>>>>>>>>>>
>>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>>>>> the nucleus code.
>>>>>>>>>>>
>>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>>>>> history of verifying hardware logic.
>>>>>>>>>>>
>>>>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>>>>> form factor of a USB stick.
>>>>>>>>>>>
>>>>>>>>>>> Trust "down to the metal".
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>>>>
>>>>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>>>>> the appropriate categories.
>>>>>>>>>>>>
>>>>>>>>>>>> But this is an interesting design question.
>>>>>>>>>>>>
>>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>>>>> say, the Integer category.
>>>>>>>>>>>>
>>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>>>>> ApproximateAttribute,
>>>>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>>>>
>>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>>>>
>>>>>>>>>>>> An "axiom" category would also export a function. This functio=
n
>>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would modi=
fy
>>>>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>>>>
>>>>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>>>>
>>>>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>>>>
>>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>>>>
>>>>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>>>>> the same mechanism.
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs=
.kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tb=
VKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryq=
OIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5x=
sNk1_eii0&e=3D
>>>>>>>>>>>>> ) on
>>>>>>>>>>>>> Seven deadly sins of talking about "types"
>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cs=
.kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt62=
fTbqv-K98dBQv0oMmB82kE8mXo&e=3D
>>>>>>>>>>>>>
>>>>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are many goals. One of the primary goals is creating a
>>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>>>>>> error (links to where errors are defined), signatures (links
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> the signatures of lisp functions), figures (links to figures=
),
>>>>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>>>>>> eventually define at least the syntax of the language. In th=
e
>>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>>>>> not that clever.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>>>>> Spad code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.an=
drew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC=
6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc=
&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHCx=
-3GFVk62hxr53YKr4naRk&e=3D
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>>>>> The underlying technology to use for building such an algeb=
ra
>>>>>>>>>>>>>>> library
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>>>>>> Theories:
>>>>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.c=
as.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ryV=
eFoBjl0AZs2cuQZhKuIxk8NUw&e=3D
>>>>>>>>>>>>>>> [which
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to a
>>>>>>>>>>>>>>> journal].
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well
>>>>>>>>>>>>>>> documented
>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alha=
ssy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.html=
&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6s=
WEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8b=
DzgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (source at
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gith=
ub.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkx=
c&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZBB=
5fBQOj0-Q48CUKRS1VNLao&e=3D
>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> literate source.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gith=
ub.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1t=
bVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ry=
qOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDITF=
QRpkFBgg8c&e=3D
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it
>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alh=
assy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-5=
Ffeature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTn=
UCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0=
Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B0=
zits8pEczWsib7Q7_mxyRIxhk&e=3D
>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>>>>>> theories
>>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>> systems
>>>>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fricas
>>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It should
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like the
>>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses") develop=
ed
>>>>>>>>>>>>>>>>>> a dependently typed general parser for context free
>>>>>>>>>>>>>>>>>> grammar
>>>>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tim

\start
Date: Sat, 25 Jul 2020 05:18:59 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>
Subject: Re: [EXTERNAL] Re: Axiom musings...

The further I get into this game, the harder it becomes.

For example, equality. In the easiest case Axiom has
propositional equality. That is, the equality function is
defined by the type, e.g. for the type Integer, 2 =3D 2.

However, there is also judgmental equality, which
would apply at the type level. If floating point numbers
match the usual IEEE definition and UNUMs match
Gustafson's Type I defintion, is there an equality
between the types? Does FLOAT =3D UNUM?
https://en.wikipedia.org/wiki/Unum_(number_format)

Axiom's coerce provides a (poorly) defined kind of
judgmental equality but its not actually defined as an
equality at the type level. You can coerce from
POLY(FRAC(INT)) to FRAC(POLY(INT)) but are they
equal? Cubical type theory would seem to say yes.

And don't get me started on the Univalent axiom.

There are lots of interesting equality questions. If there
is a proof of a program and you can regenerate the
program from the proof, are the proof and program equal?

Presumably the chap behind the SANE effort will be
able to handle both kinds of equality (as well as giving
universes for types).

But I suspect he's not that clever.



On 7/21/20, Tim Daly <axiomcas@gmail.com> wrote:
>> Yes, I do remember we worked on the "symbolic integer"
>> (or "symbolic polynomial", etc.) domains.
>
> Sadly only the idea survives.
>
> I spent almost all of my time at that time trying to get a
> version of Axiom to bootstrap. Starting Axiom, at the time,
> required an already running version of Axiom (the NAG
> version) and NAG would not let me distribute their code.
>
> Building a self-booting version involved (among a lot of
> other things) breaking circular definitions in the category
> and domain hierarchy. That took several months and all
> of my time (much to Baumslag's annoyance).
>
> That effort also involved re-writing code from Norman's
> Lisp back to Common Lisp (much to Norman's annoyance)
>
> As a result, the free version of Axiom wasn't released until
> about 2003 even though I got a copy in 2001. As part of my
> employment agreement with CCNY they wouldn't make any
> claim on Axiom and I would only work on it in my free time
> unless Gilbert said otherwise. My work time was spent as
> the Magnus lead developer and open sourcing it. Gilbert
> eventually wanted Axiom and asked me to do it for work
> also. That's what led to the grant proposal.
>
> My thoughts on the subject of symbolic integers were, as a
> consequence, only "paper experiments". I have several
> thousand technical papers stacked in my office and library.
> The CCNY notes are in there somewhere. Unfortunately,
> every time I pick up a pile to search I find other things I
> "need to know now" and get lost in that subject. It is like
> trying to get a glass of water when the three gorges dam
> burst.
>
> It seems feasible to create a SYMINT Symbolic Integer
> domain that used symbols rather than numbers for the
> arithmetic, creating a ring that could be used by POLY.
> Using SYMINT in SYMFRAC Symboiic Fraction would
> provide a field that could be used by POLY.
>
> The idea is still worth the effort but, as usual, I am deep
> into rebuilding Axiom from the ground up. The issues I'm
> struggling with now make the bootstrap effort look like a
> weekend hack. Bootstrapping took about several months.
> The current effort has taken 6 years so far. There is SO
> much to know and I am a slow learner.
>
> This is where I wish I had graduate students :-)
>
> Tim
>
>
> On 7/21/20, William Sit <wsit@ccny.cuny.edu> wrote:
>> Dear Tim:
>>
>> You have expanded on the issues I raised. While you are right that a
>> computational algorithm can be proved if the specifications are
>> completely
>> and precisely coded for the proof systems like Coq. The catch is not the
>> precisely part but the completely part.
>>
>> Yes, I do remember we worked on the "symbolic integer" (or "symbolic
>> polynomial", etc.) domains. I think I might have actually some notes and
>> ideas and perhaps code, but it would take me more searching than I can d=
o
>> now from obsoleted and perhaps non-functional computers. A few days ago,
>> I
>> was trying to recover tex files from a Raspberry Pi that I used while in
>> a
>> hotel in China (2015), but nothing (meaning ftp and other transfer
>> methods
>> or even mailing programs) works because of security. I have also
>> forgotten
>> all my knowledge on Linux.
>>
>> Too bad we did not continue that effort. Does such a domain (in any
>> computer
>> algebra system) exist these days? After all, nearly three decades have
>> passed.
>>
>> William
>>
>> William Sit
>> Professor Emeritus
>> Department of Mathematics
>> The City College of The City University of New York
>> New York, NY 10031
>> homepage: wsit.ccny.cuny.edu
>>
>> ________________________________________
>> From: Tim Daly <axiomcas@gmail.com>
>> Sent: Monday, July 20, 2020 4:44 PM
>> To: William Sit
>> Cc: axiom-dev
>> Subject: Re: [EXTERNAL] Re: Axiom musings...
>>
>>> So there are two kinds of algorithms, one that is purely mathematical
>>> and one that is computational, the latter including a particular (class
>>> of)
>>> data representation(s) (perhaps even the computer language and
>>> system of the implementation). It is proofs for the latter type of
>>> algorithms that is lacking.
>>
>> There are ,as you point out, several kinds of proofs to consider.
>>
>> One is the proof of the algorithm. An example is Buchberger's
>> Groebner Basis algorithm which was proven in Coq:
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ricam.oeaw.ac=
.at_specsem_srs_groeb_download_coq-2Dlinz.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmY=
IU&m=3DqJcX0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3D48_B3YVCzXBpYUWOgsuS=
Y0mMrrZd9SpQzWVZki-c6d4&e=3D
>>
>> The Coq proof establishes that the formal algorithm is correct.
>>
>> Even in proof one runs into limits of what can be proved. For example,
>> if the convergence is non-uniform one can, at best, do a proof that
>> assumes bounds on the non-uniform behavior. So this isn't strictly
>> a computer algorithm issue.
>>
>>> Since data representations (like REP in Axiom) are built recursively,
>>> a computational algorithm (in the sense above) for Groebner basis
>>> may have to be designed to take care of just a few of the ways
>>> integers can be represented. Axiom is built with that in mind (that's
>>> where type theory comes in), but I bet no one SPECIFIES their
>>> computational algorithms with the limitations of data representation
>>> in mind, much less proves the algorithm anew for each new
>>> representation.
>>
>> If you remember, while we were both at CCNY, I worked on a
>> grant project to construct a "symbolic integer" domain so that
>> computations could occur over non-numeric integers. The
>> symbolic form did not have a numeric limitation. Unfortunatly
>> the current Axiom has no way to support such a domain.
>>
>> I'm glad you brought this up. I will have to give some thought
>> to representing and computing with symbolic integers again.
>>
>>> So if a computation of a Groebner basis halts
>>> because of an intermediate LCM computation (say of two integer
>>> coefficients), should we consider the implementation as proven
>>> correct? What if the overflow condition was not detected and the
>>> computation continues? Indeed, since there may be different
>>> implementations of the integer domain, we must be sure that
>>> every implementation of the LCM algorithm handles overflows
>>> correctly AND specified in the documentation.
>>
>> Establishing that the algorithm is correct (e.g Groebner) is
>> clearly in the proof side of computational math
>> .
>> Establishing that there is an implementation of Groebner is
>> clearly in the computer algebra side of computational math.
>>
>> The game is to unite the two.
>>
>> Such a proof becomes a PART of the specification of a program
>> that implements the algorithm, such as in Axiom.
>>
>> The definitions and axioms of the proof have to be put into
>> the system both at the category and domain levels. They
>> need to be available at the implementation code.
>>
>> On the other hand, there are non-logical 'axioms' of
>> categories and domains, such as limits to the size of a
>> floating point number. One could have many FLOAT
>> domains, such as Gustafson's UNUMs.
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.johngustafson.=
net_pdfs_BeatingFloatingPoint.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1=
tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DqJcX0=
eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3Dwrah9xCIC0aDYjDhQgMxrQb_NM6HKkKp=
_QbW91Vx4Y4&e=3D
>>
>> There are non-logical limits to the implementation, such as
>> intermediate expression swell that uses up all of memory.
>> It isn't possible to write a specification that can detect all of
>> these kinds of failures before they occur. But there are logical
>> ways to handle such boundaries.
>>
>> In logic there are 'product types' which are basically
>> multi-field records. There are 'sum types' which are disjoint
>> unions.
>>
>> Axiom's approach to reaching limits of computation is to
>> return a 'sum type' that is either the result or 'failed'. The
>> 'failed' result needs to be explicitly carried in the proof.
>> Because 'failed' is a valid result, the specification can be
>> expanded to include this as a valid result.
>>
>> Just because a program can fail there is no reason to say
>> that it can't be proven, given that 'failed' is a valid result.
>>
>> One could even expand the sum types to include information
>> about the failure so that 'failed' would be a product type that
>> said why it failed. That allows another domain to be used.
>> In fact, one could introduce a FAILED domain in Axiom
>> with a 'why?' function. Local domains could extend FAILED
>> with their own 'why?' function specific to their possible
>> failures.
>>
>> Axiom has the ability to have muttiple domains that can
>> overcome limits, e.g. small floats, large floats, unums.
>> These would allow users to 'retry' a computation with
>> different assumptions.
>>
>> The issue you raise is important. Some algorithms in
>> Axiom have "hand-waving' specifications that need
>> to be expanded to properly return 'failed' when that is
>> expected. I think this is a 'good thing' and a useful
>> by-product of combining proof and computer algebra.
>>
>> Am I closer to understanding your objections?
>>
>> Tim
>>
>>
>>
>> On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>> Hi Tim:
>>>
>>> Perhaps I did not make myself clear in the short comment.
>>> What I wanted to say is that a data representation is not the same as
>>> the
>>> abstract mathematical objects because there are finite bounds on the
>>> representation. Take for example, an algorithm to compute the LCM of tw=
o
>>> integers. The LCM can cause overflow and not be representable. Of
>>> course,
>>> you can change the data representation to have "infinite precision", bu=
t
>>> that would still be bounded by actual physical memory of the machine.
>>> The
>>> careful programmer of the LCM algorithm would add throws and catches to
>>> handle the "error",but the implementation will have to add code that is
>>> not
>>> considered in the theoretical LCM algorithm (unless the LCM algorithm i=
s
>>> meant for bounded integers of a fixed data representation and not
>>> abstract
>>> integers). So there are two kinds of algorithms, one that is purely
>>> mathematical and one that is computational, the latter including a
>>> particular (class of) data representation(s) (perhaps even the computer
>>> language and system of the implementation). It is proofs for the latter
>>> type
>>> of algorithms that is lacking. Since data representations (like REP in
>>> Axiom) are built recursively, a computational algorithm (in the sense
>>> above)
>>> for Groebner basis may have to be designed to take care of just a few o=
f
>>> the
>>> ways integers can be represented. Axiom is built with that in mind
>>> (that's
>>> where type theory comes in), but I bet no one SPECIFIES their
>>> computational
>>> algorithms with the limitations of data representation in mind, much
>>> less
>>> proves the algorithm anew for each new representation. So if a
>>> computation
>>> of a Groebner basis halts because of an intermediate LCM computation
>>> (say
>>> of
>>> two integer coefficients), should we consider the implementation as
>>> proven
>>> correct? What if the overflow condition was not detected and the
>>> computation
>>> continues? Indeed, since there may be different implementations of the
>>> integer domain, we must be sure that every implementation of the LCM
>>> algorithm handles overflows correctly AND specified in the
>>> documentation.
>>>
>>> I am sure I am just being ignorant to pose these questions, because the=
y
>>> must have been considered and perhaps solved. In that case, please
>>> ignore
>>> them and just tell me so.
>>>
>>> William
>>>
>>> William Sit
>>> Professor Emeritus
>>> Department of Mathematics
>>> The City College of The City University of New York
>>> New York, NY 10031
>>> homepage: wsit.ccny.cuny.edu
>>>
>>> ________________________________________
>>> From: Tim Daly <axiomcas@gmail.com>
>>> Sent: Sunday, July 19, 2020 5:33 PM
>>> To: William Sit
>>> Cc: axiom-dev
>>> Subject: Re: [EXTERNAL] Re: Axiom musings...
>>>
>>> There are several "problems" with proving programs correct that
>>> I don't quite know how to solve, or even approach. But that's the
>>> fun of "research", right?
>>>
>>> For the data representation question I've been looking at types.
>>> I took 10 courses at CMU. I am eyebrow deep in type theory.
>>> I'm looking at category theory and homotopy type theory. So
>>> far I haven't seen anyone looking at the data problem. Most of
>>> the focus is on strict code typing.
>>>
>>> There is an old MIT course by Abelson and Sussman "Structure
>>> and Interpretation of Computer Programs" (SICP). They rewrite
>>> data as programs which, in Lisp, is trivial to do, Dan Friedman
>>> seems to have some interesting ideas too.
>>>
>>> All of Axiom's SANE types are now CLOS objects which gives
>>> two benefits. First, they can be inherited. But second, they
>>> are basically Lisp data structures with associated code.
>>>
>>> I'm thinking of associating "data axioms" with the representation
>>> (REP) object of a domain as well as with the functions.
>>>
>>> For example, DenavitHartenbergMatrix encodes 4x4 matrices
>>> used in graphics and robotics. They are 4x4 matrices where
>>> the upper left 3x3 encodes rotations, the right column encodes
>>> translations, and the lower row includes scaling, skewing, etc.
>>>
>>> (As an aside, DHMATRIX matrices have an associated
>>> Jacobian which encodes the dynamics in things like robots.
>>> Since I'm also programming a robot I'm tempted to work on
>>> extending the domain with related functions... but, as
>>> Hamming said, new algebra code isn't "the most important
>>> problem in computational mathematics").
>>>
>>> Axioms associated with the REP can assume that they are
>>> 4x4, that they can be inverted, that they have a "space" of
>>> rotations, etc. The axioms provide "facts" known to be true
>>> about the REP. (I also need to think about a "specification"
>>> for the REP but I'm not there yet).
>>>
>>> Since every category and domain is a CLOS data structure
>>> the DHMATRIX data structure inherits REP axioms from its
>>> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX
>>> adds domain-specific REP axioms (as well as domain-specific
>>> function axioms). Thus a DHMATRIX rotate function can
>>> base its proof on the fact that it only affects the upper 3x3
>>> and lives in a space of rotations, all of which can be assumed
>>> by the proof.
>>>
>>> If I use the SICP "trick" of representing data as code I can
>>> "expand" the data as part of the program proof.
>>>
>>> It is all Omphaloskepsis (navel gazing) at this point though.
>>> I'm still writing the new SANE compiler (which is wildly
>>> different from the compiler course I taught).
>>>
>>> I did give a talk at Notre Dame but I haven't attempted to
>>> publish. All of my work shows up in literate programming
>>> Axiom books on github.
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly=
_PDFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxw=
cTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQI=
cLfvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D
>>> )
>>>
>>> It is all pretty pointless since nobody cares about computer
>>> algebra, proving math programs correct, or Axiom itself.
>>> Wolfram is taking up all the oxygen in the discussions.
>>>
>>> But I have to say, this research is great fun. It reminds me
>>> of the Scratchpad days, although I miss the give-and-take
>>> of the group. It is hard to recreate my role as the dumbest
>>> guy in the room when I'm stuck here by myself :-)
>>>
>>> Hope you and your family are safe and healthy.
>>>
>>> Tim
>>>
>>> PS. I think we should redefine the "Hamming Distance" as
>>> the distance between an idea and its implementation.
>>>
>>>
>>>
>>> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>>> Hi Tim:
>>>>
>>>> Glad to hear from you now and then, promoting and working towards your
>>>> ideas
>>>> and ideals.
>>>>
>>>>  >>We need proven algorithms.
>>>>
>>>> Just one short comment: it is often possible to prove algorithms (that
>>>> is,
>>>> providing the theoretical foundation for the algorithm), but it is muc=
h
>>>> harder to prove that an implementation of the algorithm is correct. As
>>>> you
>>>> well know, the distinction lies in that implementation involves data
>>>> representations whereas proofs of algorithms normally ignore them.
>>>> Introducing (finite) data representations means introducing boundary
>>>> situations that a programmer implementing an algorithm must deal with.
>>>> So
>>>> perhaps what we need to prove should include the correctness of
>>>> implementations (to the bare metal, as you often say) and we should
>>>> have
>>>> a
>>>> different set of analytic tools that can deal with the correctness (or
>>>> completeness) of data representations. Of course, these tools must als=
o
>>>> be
>>>> proven with the same rigor since behind every program is an algorithm.
>>>>
>>>> William
>>>>
>>>> William Sit
>>>> Professor Emeritus
>>>> Department of Mathematics
>>>> The City College of The City University of New York
>>>> New York, NY 10031
>>>> homepage: wsit.ccny.cuny.edu
>>>>
>>>> ________________________________________
>>>> From: Axiom-developer
>>>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on beha=
lf
>>>> of
>>>> Tim Daly <axiomcas@gmail.com>
>>>> Sent: Saturday, July 18, 2020 6:28 PM
>>>> To: axiom-dev; Tim Daly
>>>> Subject: [EXTERNAL] Re: Axiom musings...
>>>>
>>>> Richard Hamming gave a great talk. "You and Your Research"
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com=
_watch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm=
0U&e=3D
>>>>
>>>> His big question is:
>>>>
>>>> "What is the most important problem in your field
>>>> and why aren't you working on it?"
>>>>
>>>> To my mind, the most important problem in the field of
>>>> computational mathematics is grounding computer
>>>> algebra in proofs.
>>>>
>>>> Computer mathematical algorithms that "maybe,
>>>> possibly, give correct answers sometimes" is a problem.
>>>> Indeed, for computer algebra, it is the most important
>>>> problem. We need proven algorithms.
>>>>
>>>> New algorithms, better graphics, better documentation,
>>>> are all "nice to have" but, as Hamming would say,
>>>> they are not "the most important problem".
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> Time for another update.
>>>>>
>>>>> The latest Intel processors, available only to data centers
>>>>> so far, have a built-in FPGA. This allows you to design
>>>>> your own circuits and have them loaded "on the fly",
>>>>> running in parallel with the CPU.
>>>>>
>>>>> I bought a Lattice ICEstick FPGA development board. For
>>>>> the first time there are open source tools that support it so
>>>>> it is a great test bench for ideas and development. It is a
>>>>> USB drive so it can be easily ported to any PC.
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticese=
mi.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbut=
Qz2HFhAAAymG-QswIjRao_YTwz4&e=3D
>>>>> )
>>>>>
>>>>> I also bought a large Intel Cyclone FPGA development board.
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.co=
m.tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW=
6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D
>>>>> )
>>>>> which has 2 embedded ARM processors. Unfortunately
>>>>> the tools (which are freely available) are not open source.
>>>>> It has sufficient size and power to do anything.
>>>>>
>>>>>
>>>>> I've got 2 threads of work in progress, both of which
>>>>> involve FPGAs (Field Programmable Gate Arrays).
>>>>>
>>>>> Thread 1
>>>>>
>>>>> The first thread involves proving programs correct. Once
>>>>> a proof has been made it is rather easier to check the proof.
>>>>> If code is shipped with a proof, the proof can be loaded into
>>>>> an FPGA running a proof-checker which verifies the program
>>>>> in parallel with running the code on the CPU.
>>>>>
>>>>> I am researching the question of writing a proof checker that
>>>>> runs on an FPGA, thus verifying the code "down to the metal".
>>>>> The Lean proof checker is the current target.
>>>>>
>>>>> The idea is to make "Oracle" algorithms that, because they
>>>>> are proven correct and verified at runtime, can be trusted
>>>>> by other mathematical software (e.g. Lean, Coq, Agda)
>>>>> when used in proofs.
>>>>>
>>>>> Thread 2
>>>>>
>>>>>
>>>>> The second thread involves arithmetic. Axiom currently ships
>>>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).
>>>>> These routines have a known set of numeric failures such as
>>>>> cancellation, underflow, and scaling.
>>>>>
>>>>> John Gustafson has designed a 'unum' numeric format that can
>>>>> eliminate many of these errors. (See
>>>>> Gustafson, John "The End of Error" CRC Press 2015
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com=
_End-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5=
F1-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3=
D1593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa=
0A&e=3D
>>>>> )
>>>>>
>>>>> The research goal is to implement Axiom's floating-point
>>>>> arithmetic that can be offloaded onto an FPGA implementing
>>>>> the unum format. Such a system would radically simplify
>>>>> the implementation of BLAS and LAPACK as most of the
>>>>> errors can't occur. The impact would be similar to using
>>>>> multi-precision integer arithmetic, only now its floating-point.
>>>>>
>>>>> SANE, the greater goal.
>>>>>
>>>>> The Axiom SANE compiler / interpreter can use both of
>>>>> these tools to implement trusted mathematical software.
>>>>> It's a long, ambitious research effort but even if only pieces
>>>>> of it succeed, it changes computational mathematics.
>>>>>
>>>>> Tim
>>>>>
>>>>> "A person's reach should exceed their grasp,
>>>>> or what's a computer for?"  (misquoting Robert Browning)
>>>>>
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.=
com_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexc=
eed-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx=
_OqsfcYl4z14qlYS02TBNmnaHUY&e=3D
>>>>> )
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> WHY PROVE AXIOM CORRECT (SANE)?
>>>>>>
>>>>>> Historically, Axiom credits CLU, the Cluster language by
>>>>>> Barbara Liskov, with the essential ideas behind the Spad
>>>>>> language. Barbara gave a talk (a partial transcript below)
>>>>>> that gives the rational behind the ``where clause'' used by
>>>>>> Spad.
>>>>>>
>>>>>> She talks about the limits of the compile time capablity.
>>>>>> In particular, she says:
>>>>>>
>>>>>>    To go further, where we would say that T,
>>>>>>    in addition, has to be an equality relation, that requires
>>>>>>    much more sophisticated techniques that, even today, are
>>>>>>    beyond the capabilities of the compiler.
>>>>>>
>>>>>> Showing that the ``equal'' function satisfies the equality
>>>>>> relation is no longer ``beyond the capabilities of the compiler''.
>>>>>> We have the required formalisms and mechanisms to
>>>>>> prove properties at compile time.
>>>>>>
>>>>>> The SANE effort is essentially trying to push compile
>>>>>> time checking into proving that, for categories that use
>>>>>> ``equal'', we prove that the equal function implements
>>>>>> equality.
>>>>>>
>>>>>> I strongly encourage you to watch her video.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>> Barbara Liskov
>>>>>> May 2012
>>>>>> MIT CSAIL
>>>>>> Programming the Turing Machine
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.c=
om_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZ=
XHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfX=
NZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS=
1eGY&e=3D
>>>>>>
>>>>>> POLYMORPHISM
>>>>>>
>>>>>> We don't just want a set, we want polymorphism or
>>>>>> generics, as they are called today. We wanted to
>>>>>> have a generic set which was paramaterized by type
>>>>>> so you could instantiate it as:
>>>>>>
>>>>>> Set =3D [T:type] create, insert,...
>>>>>>   % representation for Set object
>>>>>>   % implementation of Set operations
>>>>>>   Set
>>>>>>
>>>>>> Set[int] s :=3D Set[int]$create()
>>>>>> Set[int]$insert(s,3)
>>>>>>
>>>>>> We wanted a static solution to this problem. The
>>>>>> problem is, not every type makes sense as a parameter
>>>>>> to Set of T. For sets, per se, you need an equality
>>>>>> relation. If it has been a sorted set we would have
>>>>>> some ordering relation. And a type that didn't have
>>>>>> one of those things would not have been a legitimate
>>>>>> parameter. We needed a way of expressing that in a
>>>>>> compile-time, checkable manner. Otherwise we would
>>>>>> have had to resort to runtime checking.
>>>>>>
>>>>>> Our solution was
>>>>>>
>>>>>> Set =3D [T:  ] create, insert,...
>>>>>>   T equal: (T,T) (bool)
>>>>>>
>>>>>>
>>>>>> Our solution, what we call the ``where clause''. So we
>>>>>> added this to the header. The ``where clause'' tells you
>>>>>> what operations the parameter type has to have.
>>>>>>
>>>>>> If you have the ``where'' clause you can do the static
>>>>>> checking because when you instantiate, when you provide
>>>>>> an actual type, the compiler can check that the type has
>>>>>> the operations that are required. And then, when you write
>>>>>> the implementation of Set the compiler knows it's ok to
>>>>>> call those operations because you can guarantee they are
>>>>>> actually there when you get around to running.
>>>>>>
>>>>>> Of course, you notice that there's just syntax here; there's
>>>>>> no semantics.
>>>>>>
>>>>>> As I'm sure you all know, compile-time type checking is
>>>>>> basically a proof technique of a very limited sort and
>>>>>> this was about as far as we can push what you could get out of the
>>>>>> static analysis. To go further, where we would say that T,
>>>>>> in addition, has to be an equality relation, that requires
>>>>>> much more sophisticated techniques that, even today, are
>>>>>> beyond the capabilities of the compiler.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> I've spent entirely too much time studing the legal issues
>>>>>>> of free and open source software. There are copyright,
>>>>>>> trademark, and intellectual property laws. I have read
>>>>>>> several books, listened to lectures, and read papers on
>>>>>>> the subject. I've spoken to lawyers about it. I've even
>>>>>>> been required, by law, to coerce people I respect.
>>>>>>> You would think it was all perfectly clear. It isn't.
>>>>>>>
>>>>>>> The most entertaining and enlightening lectures were
>>>>>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>>>>>> "The Semasiology of Open Source", which sounds
>>>>>>> horrible but I assure you, this is a real treat.
>>>>>>>
>>>>>>> THE THESIS
>>>>>>>
>>>>>>> Semasiology, n. The science of meanings or
>>>>>>> sense development (of words); the explanation
>>>>>>> of the development and changes of the meanings
>>>>>>> of words. Source: Webster's Revised Unabridged
>>>>>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>>>>>
>>>>>>> "Open source doesn't just mean access to the
>>>>>>> source code." So begins the Open Source Definition.
>>>>>>> What then, does access to the source code mean?
>>>>>>> Seen through the lens of an Enterprise user, what
>>>>>>> does open source mean? When is (or isn't) it
>>>>>>> significant? And a catalogue of open source
>>>>>>> related arbitrage opportunities.
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conver=
sationsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-252=
0of-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrk=
ZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDf=
XNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcn=
EbusM&e=3D
>>>>>>>
>>>>>>> Computer source code has words and sentence
>>>>>>> structure like actual prose or even poetry. Writing
>>>>>>> code for the computer is like writing an essay. It
>>>>>>> should be written for other people to read,
>>>>>>> understand and modify. These are some of the
>>>>>>> thoughts behind literate programming proposed
>>>>>>> by Donald Knuth. This is also one of the ideas
>>>>>>> behind Open Source.
>>>>>>>
>>>>>>>  THE ANTITHESIS
>>>>>>>
>>>>>>> "Open Source" is a phrase like "Object Oriented"
>>>>>>> - weird at first, but when it became popular, the
>>>>>>> meaning began to depend on the context of the
>>>>>>> speaker or listener. "Object Oriented" meant that
>>>>>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>>>>>> version of Cobol are all "Object Oriented" - for some
>>>>>>> specific definition of "Object Oriented". Similar is
>>>>>>> the case of the phrase "Open Source".
>>>>>>>
>>>>>>> In Part I, Lefkowitz talked about the shift of the
>>>>>>> meaning of "Open Source" away from any reference
>>>>>>> to the actual "source code," and more towards other
>>>>>>> phases of the software development life cycle. In
>>>>>>> Part II, he returns to the consideration of the
>>>>>>> relationship between "open source" and the actual
>>>>>>> "source code," and reflects upon both the way
>>>>>>> forward and the road behind, drawing inspiration
>>>>>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>>>>>> and others.
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conver=
sationsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFa=
Q&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwW=
YZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D=
LTgLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D
>>>>>>>
>>>>>>> THE SYNTHESIS
>>>>>>>
>>>>>>> In a fascinating synthesis, Robert "r0ml" Lefkowitz
>>>>>>> polishes up his exposition on the evolving meaning
>>>>>>> of the term 'open source'. This intellectual joy-ride
>>>>>>> draws on some of the key ideas in artificial intelligence
>>>>>>> to probe the role of language, meaning and context
>>>>>>> in computing and the software development process.
>>>>>>> Like Wittgenstein's famous thought experiment, the
>>>>>>> open source 'beetle in a box' can represent different
>>>>>>> things to different people, bearing interesting fruit for
>>>>>>> philosophers and software creators alike.
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversat=
ionsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4N=
mamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSW=
MRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoI=
wON-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D
>>>>>>>
>>>>>>>
>>>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>>>>>> so far, is to push once a month on the 7th.
>>>>>>>>
>>>>>>>> After some chat room interactions it was brought home
>>>>>>>> again that the proof world really does not seem to like the
>>>>>>>> idea of proving programs correct. And, given that it was is
>>>>>>>> of the main Axiom goals and a point of friction during the fork,
>>>>>>>> the computer algebra world does not like the idea of proving
>>>>>>>> programs correct either.
>>>>>>>>
>>>>>>>> So the idea of "computational mathematics", which includes
>>>>>>>> both disciplines (as well as type theory) seems still a long
>>>>>>>> way off.
>>>>>>>>
>>>>>>>> Nevertheless, the primary change in these past and future
>>>>>>>> updates is focused on merging proof and computer algebra.
>>>>>>>>
>>>>>>>> Proof systems are able to split the problem of creating a
>>>>>>>> proof and the problem of verifying a proof, which is much
>>>>>>>> cheaper. Ideally the proof checker would run on verified
>>>>>>>> hardware so the proof is checked "down to the metal".
>>>>>>>>
>>>>>>>> I have a background in Field Programmable Gate Arrays
>>>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>>>>>> looking at creating a hardware proof checker using a
>>>>>>>> dedicated instruction set, one designed to be verifed.
>>>>>>>> New CPUs used in data centers (not yet available to us
>>>>>>>> mortals) have built-in FPGAs so it would be possible to
>>>>>>>> "side-load" a proof of a program to be checked while the
>>>>>>>> program is run. I have the FPGA and am doing a gate-level
>>>>>>>> special instruction design for such a proof checker.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>>>>>> mostly because it keeps muttering about Types. If you're not
>>>>>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>>>>>> seems pointless and painful.
>>>>>>>>>
>>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>>
>>>>>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>>>>>> to use a system like Axiom, mostly because you have to find
>>>>>>>>> or create "domains" or "packages", understand categories
>>>>>>>>> with their inheritance model, and learn a new language with
>>>>>>>>> a painful compiler always complaining about types.
>>>>>>>>>
>>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>>
>>>>>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>>>>>> It also assumes a background in type theory, inductive logic,
>>>>>>>>> homotopy type theory, ML (meta-language, not machine
>>>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>>>>>> and tacticals. Also assumed is knowledge of specification
>>>>>>>>> languages,
>>>>>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>>>>>> libraries of the same.
>>>>>>>>>
>>>>>>>>> So Axiom Sane has a steep learning curve.
>>>>>>>>>
>>>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>>>>>> learning to read the leading edge literature (also known
>>>>>>>>> as "greek studies", since every paper has pages of greek).
>>>>>>>>>
>>>>>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>>>>>> "computational mathematics" framework. I suspect that the only
>>>>>>>>> way this system will ever be useful is after Universities have a
>>>>>>>>> "Computational Mathematics" major course of study and degree.
>>>>>>>>>
>>>>>>>>> Creating a new department is harder than creating Axiom Sane
>>>>>>>>> because, you know, ... people.
>>>>>>>>>
>>>>>>>>> I think such a department is inevitable given the deep and wide
>>>>>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>>>>>> started programming there was no computer science degree.
>>>>>>>>>
>>>>>>>>> Somebody has to be the first lemming over the cliff.
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>>>>>> there is a certain amount of verification that is involved.
>>>>>>>>>>
>>>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its
>>>>>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is
>>>>>>>>>> returned. Lean can the verify that the proof is valid. But it is
>>>>>>>>>> computationally more efficient if Axiom and Lean use a
>>>>>>>>>> cryptographic
>>>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>>>>>> 'reproven', only a hash computation over the proof text needs to
>>>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to b=
e
>>>>>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>>>>>> computation request from Lean might involve many algorithms
>>>>>>>>>> there would be considerable overhead to recompute each proof.
>>>>>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>>>>>
>>>>>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>>>>>> information about the domain and range of a resulting formula.
>>>>>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>>>>>> SuchThat domain).
>>>>>>>>>>>
>>>>>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>>>>>> information is difficult if not impossible in the current
>>>>>>>>>>> system.
>>>>>>>>>>> The information isn't available and isn't computed. In that
>>>>>>>>>>> sense,
>>>>>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>>>>>
>>>>>>>>>>> In the Sane implementation the information is available. It is
>>>>>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>>>>>> careful design it will be possible to provide provisos for each
>>>>>>>>>>> given result that are carried with the result for use in furthe=
r
>>>>>>>>>>> computation.
>>>>>>>>>>>
>>>>>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>>>>>> if the formula is defined over an interval, how is the interval
>>>>>>>>>>> arithmetic handled?
>>>>>>>>>>>
>>>>>>>>>>> Exciting research ahead!
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>>>>>
>>>>>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>>>>>> trust at all levels.
>>>>>>>>>>>>
>>>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>>>>>> trusted kernel through which all other computations must
>>>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>>>>>> something similar.
>>>>>>>>>>>>
>>>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>>>>>> the nucleus code.
>>>>>>>>>>>>
>>>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>>>>>> history of verifying hardware logic.
>>>>>>>>>>>>
>>>>>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>>>>>> form factor of a USB stick.
>>>>>>>>>>>>
>>>>>>>>>>>> Trust "down to the metal".
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>>>>>> the appropriate categories.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But this is an interesting design question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>>>>>> say, the Integer category.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>>>>>> ApproximateAttribute,
>>>>>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An "axiom" category would also export a function. This
>>>>>>>>>>>>> function
>>>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would
>>>>>>>>>>>>> modify
>>>>>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>>>>>> the same mechanism.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.c=
s.kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1t=
bVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ry=
qOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5=
xsNk1_eii0&e=3D
>>>>>>>>>>>>>> ) on
>>>>>>>>>>>>>> Seven deadly sins of talking about "types"
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.c=
s.kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt6=
2fTbqv-K98dBQv0oMmB82kE8mXo&e=3D
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Taken further I can think of several other kinds of checkers
>>>>>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are many goals. One of the primary goals is creating =
a
>>>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So the latest changes involved adding multiple index files.
>>>>>>>>>>>>>>> These are documentation (links to where terms are mentioned
>>>>>>>>>>>>>>> in the text), code (links to the implementation of things),
>>>>>>>>>>>>>>> error (links to where errors are defined), signatures (link=
s
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the signatures of lisp functions), figures (links to
>>>>>>>>>>>>>>> figures),
>>>>>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>>>>>> those diagrams follows immediately. Collectively these will
>>>>>>>>>>>>>>> eventually define at least the syntax of the language. In
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>>>>>> not that clever.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>>>>>> Spad code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>>>>>> this will happen is still in the land of design. This would
>>>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.a=
ndrew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkx=
c&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHC=
x-3GFVk62hxr53YKr4naRk&e=3D
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>>>>>> The underlying technology to use for building such an
>>>>>>>>>>>>>>>> algebra
>>>>>>>>>>>>>>>> library
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between
>>>>>>>>>>>>>>>> Theories:
>>>>>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.=
cas.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ry=
VeFoBjl0AZs2cuQZhKuIxk8NUw&e=3D
>>>>>>>>>>>>>>>> [which
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to =
a
>>>>>>>>>>>>>>>> journal].
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well
>>>>>>>>>>>>>>>> documented
>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alh=
assy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.htm=
l&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6=
sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8=
bDzgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (source at
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__git=
hub.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZB=
B5fBQOj0-Q48CUKRS1VNLao&e=3D
>>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> literate source.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__git=
hub.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1=
tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6r=
yqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDIT=
FQRpkFBgg8c&e=3D
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__al=
hassy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-=
5Ffeature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B=
0zits8pEczWsib7Q7_mxyRIxhk&e=3D
>>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized
>>>>>>>>>>>>>>>> theories
>>>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all
>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> systems
>>>>>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Frica=
s
>>>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It shoul=
d
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"
>>>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like th=
e
>>>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports
>>>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses")
>>>>>>>>>>>>>>>>>>> developed
>>>>>>>>>>>>>>>>>>> a dependently typed general parser for context free
>>>>>>>>>>>>>>>>>>> grammar
>>>>>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tim

\start
Date: Sun, 26 Jul 2020 08:18:43 +0000
From: William Sit <wsit@ccny.cuny.edu>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [EXTERNAL] Re: Axiom musings...

The question of equality in computation is very different than equality in =
mathematics and it is basically due to data representations in computation =
(and for this question, we are not even  concerned with equality between tw=
o implementations of the same domain but different representations (types),=
 when coercion is needed). As you pointed out, the key question is: "what s=
hould be the definition of equality?" even within one single domain and one=
 data representation. =0A=
Arithmetic in any floating point number system does not satisfy many of the=
 usual laws. For example, a times (b divided by a) is NOT b in such a syste=
m unless the system is FP(2,1,c).=0A=
Here FP(r,p,c) is the floating point system with radix r, precision p, and =
c for chopping (truncation). =0A=
 The associative laws of addition and multiplication do NOT hold in FP(r,p,=
c). Strict inequality (less than) between two FP(r,p,c) numbers can be weak=
ened to (less than or equal to) after say adding a third number or multipli=
ed by a positive number. Ref: Pat.  H. Sterbenz, Floating Point Computation=
,Sections 1.6, 1.7.=0A=
=0A=
So to prove correctness of implementation for an algorithm, say like taking=
 square roots, will be far more difficult than the same for integers. How c=
an one be convinced that the computation gives the most accurate square roo=
t for all inputs in the system FP(r,p,c)? In fact, is there such an algorit=
hm other than one based on case considerations for every number in FP(r,p,c=
)---you may as well use a lookup table in that case.=0A=
=0A=
In the case of polynomial equality between two domains, one can always do a=
 subtraction in the domain of the target of coercion to verify equality. Fo=
r the specific example you gave, I would agree with Cubical type theory (wh=
atever that is!) that they should be considered equal (unless there is a pr=
oblem with computing the LCM of denominators of the coefficients).=0A=
=0A=
William=0A=
=0A=
William Sit=0A=
Professor Emeritus=0A=
Department of Mathematics=0A=
The City College of The City University of New York=0A=
New York, NY 10031=0A=
homepage: wsit.ccny.cuny.edu=0A=
=0A=
________________________________________=0A=
From: Tim Daly <axiomcas@gmail.com>=0A=
Sent: Saturday, July 25, 2020 5:18 AM=0A=
To: William Sit=0A=
Cc: axiom-dev=0A=
Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
=0A=
The further I get into this game, the harder it becomes.=0A=
=0A=
For example, equality. In the easiest case Axiom has=0A=
propositional equality. That is, the equality function is=0A=
defined by the type, e.g. for the type Integer, 2 =3D 2.=0A=
=0A=
However, there is also judgmental equality, which=0A=
would apply at the type level. If floating point numbers=0A=
match the usual IEEE definition and UNUMs match=0A=
Gustafson's Type I defintion, is there an equality=0A=
between the types? Does FLOAT =3D UNUM?=0A=
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__en.wikipedia.org_wik=
i_Unum-5F-28number-5Fformat-29&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbV=
KrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DY2MBHvio=
PEtIrgddTGyKqAMzQ_VeElXxUnvWAYX19HU&s=3DtIo8U5fkmzZuvhbq0yoSyRwBb-h2udDjfQf=
IkCK6qCY&e=3D=0A=
=0A=
Axiom's coerce provides a (poorly) defined kind of=0A=
judgmental equality but its not actually defined as an=0A=
equality at the type level. You can coerce from=0A=
POLY(FRAC(INT)) to FRAC(POLY(INT)) but are they=0A=
equal? Cubical type theory would seem to say yes.=0A=
=0A=
And don't get me started on the Univalent axiom.=0A=
=0A=
There are lots of interesting equality questions. If there=0A=
is a proof of a program and you can regenerate the=0A=
program from the proof, are the proof and program equal?=0A=
=0A=
Presumably the chap behind the SANE effort will be=0A=
able to handle both kinds of equality (as well as giving=0A=
universes for types).=0A=
=0A=
But I suspect he's not that clever.=0A=
=0A=
=0A=
=0A=
On 7/21/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>> Yes, I do remember we worked on the "symbolic integer"=0A=
>> (or "symbolic polynomial", etc.) domains.=0A=
>=0A=
> Sadly only the idea survives.=0A=
>=0A=
> I spent almost all of my time at that time trying to get a=0A=
> version of Axiom to bootstrap. Starting Axiom, at the time,=0A=
> required an already running version of Axiom (the NAG=0A=
> version) and NAG would not let me distribute their code.=0A=
>=0A=
> Building a self-booting version involved (among a lot of=0A=
> other things) breaking circular definitions in the category=0A=
> and domain hierarchy. That took several months and all=0A=
> of my time (much to Baumslag's annoyance).=0A=
>=0A=
> That effort also involved re-writing code from Norman's=0A=
> Lisp back to Common Lisp (much to Norman's annoyance)=0A=
>=0A=
> As a result, the free version of Axiom wasn't released until=0A=
> about 2003 even though I got a copy in 2001. As part of my=0A=
> employment agreement with CCNY they wouldn't make any=0A=
> claim on Axiom and I would only work on it in my free time=0A=
> unless Gilbert said otherwise. My work time was spent as=0A=
> the Magnus lead developer and open sourcing it. Gilbert=0A=
> eventually wanted Axiom and asked me to do it for work=0A=
> also. That's what led to the grant proposal.=0A=
>=0A=
> My thoughts on the subject of symbolic integers were, as a=0A=
> consequence, only "paper experiments". I have several=0A=
> thousand technical papers stacked in my office and library.=0A=
> The CCNY notes are in there somewhere. Unfortunately,=0A=
> every time I pick up a pile to search I find other things I=0A=
> "need to know now" and get lost in that subject. It is like=0A=
> trying to get a glass of water when the three gorges dam=0A=
> burst.=0A=
>=0A=
> It seems feasible to create a SYMINT Symbolic Integer=0A=
> domain that used symbols rather than numbers for the=0A=
> arithmetic, creating a ring that could be used by POLY.=0A=
> Using SYMINT in SYMFRAC Symboiic Fraction would=0A=
> provide a field that could be used by POLY.=0A=
>=0A=
> The idea is still worth the effort but, as usual, I am deep=0A=
> into rebuilding Axiom from the ground up. The issues I'm=0A=
> struggling with now make the bootstrap effort look like a=0A=
> weekend hack. Bootstrapping took about several months.=0A=
> The current effort has taken 6 years so far. There is SO=0A=
> much to know and I am a slow learner.=0A=
>=0A=
> This is where I wish I had graduate students :-)=0A=
>=0A=
> Tim=0A=
>=0A=
>=0A=
> On 7/21/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
>> Dear Tim:=0A=
>>=0A=
>> You have expanded on the issues I raised. While you are right that a=0A=
>> computational algorithm can be proved if the specifications are=0A=
>> completely=0A=
>> and precisely coded for the proof systems like Coq. The catch is not the=
=0A=
>> precisely part but the completely part.=0A=
>>=0A=
>> Yes, I do remember we worked on the "symbolic integer" (or "symbolic=0A=
>> polynomial", etc.) domains. I think I might have actually some notes and=
=0A=
>> ideas and perhaps code, but it would take me more searching than I can d=
o=0A=
>> now from obsoleted and perhaps non-functional computers. A few days ago,=
=0A=
>> I=0A=
>> was trying to recover tex files from a Raspberry Pi that I used while in=
=0A=
>> a=0A=
>> hotel in China (2015), but nothing (meaning ftp and other transfer=0A=
>> methods=0A=
>> or even mailing programs) works because of security. I have also=0A=
>> forgotten=0A=
>> all my knowledge on Linux.=0A=
>>=0A=
>> Too bad we did not continue that effort. Does such a domain (in any=0A=
>> computer=0A=
>> algebra system) exist these days? After all, nearly three decades have=
=0A=
>> passed.=0A=
>>=0A=
>> William=0A=
>>=0A=
>> William Sit=0A=
>> Professor Emeritus=0A=
>> Department of Mathematics=0A=
>> The City College of The City University of New York=0A=
>> New York, NY 10031=0A=
>> homepage: wsit.ccny.cuny.edu=0A=
>>=0A=
>> ________________________________________=0A=
>> From: Tim Daly <axiomcas@gmail.com>=0A=
>> Sent: Monday, July 20, 2020 4:44 PM=0A=
>> To: William Sit=0A=
>> Cc: axiom-dev=0A=
>> Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
>>=0A=
>>> So there are two kinds of algorithms, one that is purely mathematical=
=0A=
>>> and one that is computational, the latter including a particular (class=
=0A=
>>> of)=0A=
>>> data representation(s) (perhaps even the computer language and=0A=
>>> system of the implementation). It is proofs for the latter type of=0A=
>>> algorithms that is lacking.=0A=
>>=0A=
>> There are ,as you point out, several kinds of proofs to consider.=0A=
>>=0A=
>> One is the proof of the algorithm. An example is Buchberger's=0A=
>> Groebner Basis algorithm which was proven in Coq:=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ricam.oeaw.ac=
.at_specsem_srs_groeb_download_coq-2Dlinz.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmY=
IU&m=3DqJcX0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3D48_B3YVCzXBpYUWOgsuS=
Y0mMrrZd9SpQzWVZki-c6d4&e=3D=0A=
>>=0A=
>> The Coq proof establishes that the formal algorithm is correct.=0A=
>>=0A=
>> Even in proof one runs into limits of what can be proved. For example,=
=0A=
>> if the convergence is non-uniform one can, at best, do a proof that=0A=
>> assumes bounds on the non-uniform behavior. So this isn't strictly=0A=
>> a computer algorithm issue.=0A=
>>=0A=
>>> Since data representations (like REP in Axiom) are built recursively,=
=0A=
>>> a computational algorithm (in the sense above) for Groebner basis=0A=
>>> may have to be designed to take care of just a few of the ways=0A=
>>> integers can be represented. Axiom is built with that in mind (that's=
=0A=
>>> where type theory comes in), but I bet no one SPECIFIES their=0A=
>>> computational algorithms with the limitations of data representation=0A=
>>> in mind, much less proves the algorithm anew for each new=0A=
>>> representation.=0A=
>>=0A=
>> If you remember, while we were both at CCNY, I worked on a=0A=
>> grant project to construct a "symbolic integer" domain so that=0A=
>> computations could occur over non-numeric integers. The=0A=
>> symbolic form did not have a numeric limitation. Unfortunatly=0A=
>> the current Axiom has no way to support such a domain.=0A=
>>=0A=
>> I'm glad you brought this up. I will have to give some thought=0A=
>> to representing and computing with symbolic integers again.=0A=
>>=0A=
>>> So if a computation of a Groebner basis halts=0A=
>>> because of an intermediate LCM computation (say of two integer=0A=
>>> coefficients), should we consider the implementation as proven=0A=
>>> correct? What if the overflow condition was not detected and the=0A=
>>> computation continues? Indeed, since there may be different=0A=
>>> implementations of the integer domain, we must be sure that=0A=
>>> every implementation of the LCM algorithm handles overflows=0A=
>>> correctly AND specified in the documentation.=0A=
>>=0A=
>> Establishing that the algorithm is correct (e.g Groebner) is=0A=
>> clearly in the proof side of computational math=0A=
>> .=0A=
>> Establishing that there is an implementation of Groebner is=0A=
>> clearly in the computer algebra side of computational math.=0A=
>>=0A=
>> The game is to unite the two.=0A=
>>=0A=
>> Such a proof becomes a PART of the specification of a program=0A=
>> that implements the algorithm, such as in Axiom.=0A=
>>=0A=
>> The definitions and axioms of the proof have to be put into=0A=
>> the system both at the category and domain levels. They=0A=
>> need to be available at the implementation code.=0A=
>>=0A=
>> On the other hand, there are non-logical 'axioms' of=0A=
>> categories and domains, such as limits to the size of a=0A=
>> floating point number. One could have many FLOAT=0A=
>> domains, such as Gustafson's UNUMs.=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.johngustafson.=
net_pdfs_BeatingFloatingPoint.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1=
tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DqJcX0=
eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3Dwrah9xCIC0aDYjDhQgMxrQb_NM6HKkKp=
_QbW91Vx4Y4&e=3D=0A=
>>=0A=
>> There are non-logical limits to the implementation, such as=0A=
>> intermediate expression swell that uses up all of memory.=0A=
>> It isn't possible to write a specification that can detect all of=0A=
>> these kinds of failures before they occur. But there are logical=0A=
>> ways to handle such boundaries.=0A=
>>=0A=
>> In logic there are 'product types' which are basically=0A=
>> multi-field records. There are 'sum types' which are disjoint=0A=
>> unions.=0A=
>>=0A=
>> Axiom's approach to reaching limits of computation is to=0A=
>> return a 'sum type' that is either the result or 'failed'. The=0A=
>> 'failed' result needs to be explicitly carried in the proof.=0A=
>> Because 'failed' is a valid result, the specification can be=0A=
>> expanded to include this as a valid result.=0A=
>>=0A=
>> Just because a program can fail there is no reason to say=0A=
>> that it can't be proven, given that 'failed' is a valid result.=0A=
>>=0A=
>> One could even expand the sum types to include information=0A=
>> about the failure so that 'failed' would be a product type that=0A=
>> said why it failed. That allows another domain to be used.=0A=
>> In fact, one could introduce a FAILED domain in Axiom=0A=
>> with a 'why?' function. Local domains could extend FAILED=0A=
>> with their own 'why?' function specific to their possible=0A=
>> failures.=0A=
>>=0A=
>> Axiom has the ability to have muttiple domains that can=0A=
>> overcome limits, e.g. small floats, large floats, unums.=0A=
>> These would allow users to 'retry' a computation with=0A=
>> different assumptions.=0A=
>>=0A=
>> The issue you raise is important. Some algorithms in=0A=
>> Axiom have "hand-waving' specifications that need=0A=
>> to be expanded to properly return 'failed' when that is=0A=
>> expected. I think this is a 'good thing' and a useful=0A=
>> by-product of combining proof and computer algebra.=0A=
>>=0A=
>> Am I closer to understanding your objections?=0A=
>>=0A=
>> Tim=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
>>> Hi Tim:=0A=
>>>=0A=
>>> Perhaps I did not make myself clear in the short comment.=0A=
>>> What I wanted to say is that a data representation is not the same as=
=0A=
>>> the=0A=
>>> abstract mathematical objects because there are finite bounds on the=0A=
>>> representation. Take for example, an algorithm to compute the LCM of tw=
o=0A=
>>> integers. The LCM can cause overflow and not be representable. Of=0A=
>>> course,=0A=
>>> you can change the data representation to have "infinite precision", bu=
t=0A=
>>> that would still be bounded by actual physical memory of the machine.=
=0A=
>>> The=0A=
>>> careful programmer of the LCM algorithm would add throws and catches to=
=0A=
>>> handle the "error",but the implementation will have to add code that is=
=0A=
>>> not=0A=
>>> considered in the theoretical LCM algorithm (unless the LCM algorithm i=
s=0A=
>>> meant for bounded integers of a fixed data representation and not=0A=
>>> abstract=0A=
>>> integers). So there are two kinds of algorithms, one that is purely=0A=
>>> mathematical and one that is computational, the latter including a=0A=
>>> particular (class of) data representation(s) (perhaps even the computer=
=0A=
>>> language and system of the implementation). It is proofs for the latter=
=0A=
>>> type=0A=
>>> of algorithms that is lacking. Since data representations (like REP in=
=0A=
>>> Axiom) are built recursively, a computational algorithm (in the sense=
=0A=
>>> above)=0A=
>>> for Groebner basis may have to be designed to take care of just a few o=
f=0A=
>>> the=0A=
>>> ways integers can be represented. Axiom is built with that in mind=0A=
>>> (that's=0A=
>>> where type theory comes in), but I bet no one SPECIFIES their=0A=
>>> computational=0A=
>>> algorithms with the limitations of data representation in mind, much=0A=
>>> less=0A=
>>> proves the algorithm anew for each new representation. So if a=0A=
>>> computation=0A=
>>> of a Groebner basis halts because of an intermediate LCM computation=0A=
>>> (say=0A=
>>> of=0A=
>>> two integer coefficients), should we consider the implementation as=0A=
>>> proven=0A=
>>> correct? What if the overflow condition was not detected and the=0A=
>>> computation=0A=
>>> continues? Indeed, since there may be different implementations of the=
=0A=
>>> integer domain, we must be sure that every implementation of the LCM=0A=
>>> algorithm handles overflows correctly AND specified in the=0A=
>>> documentation.=0A=
>>>=0A=
>>> I am sure I am just being ignorant to pose these questions, because the=
y=0A=
>>> must have been considered and perhaps solved. In that case, please=0A=
>>> ignore=0A=
>>> them and just tell me so.=0A=
>>>=0A=
>>> William=0A=
>>>=0A=
>>> William Sit=0A=
>>> Professor Emeritus=0A=
>>> Department of Mathematics=0A=
>>> The City College of The City University of New York=0A=
>>> New York, NY 10031=0A=
>>> homepage: wsit.ccny.cuny.edu=0A=
>>>=0A=
>>> ________________________________________=0A=
>>> From: Tim Daly <axiomcas@gmail.com>=0A=
>>> Sent: Sunday, July 19, 2020 5:33 PM=0A=
>>> To: William Sit=0A=
>>> Cc: axiom-dev=0A=
>>> Subject: Re: [EXTERNAL] Re: Axiom musings...=0A=
>>>=0A=
>>> There are several "problems" with proving programs correct that=0A=
>>> I don't quite know how to solve, or even approach. But that's the=0A=
>>> fun of "research", right?=0A=
>>>=0A=
>>> For the data representation question I've been looking at types.=0A=
>>> I took 10 courses at CMU. I am eyebrow deep in type theory.=0A=
>>> I'm looking at category theory and homotopy type theory. So=0A=
>>> far I haven't seen anyone looking at the data problem. Most of=0A=
>>> the focus is on strict code typing.=0A=
>>>=0A=
>>> There is an old MIT course by Abelson and Sussman "Structure=0A=
>>> and Interpretation of Computer Programs" (SICP). They rewrite=0A=
>>> data as programs which, in Lisp, is trivial to do, Dan Friedman=0A=
>>> seems to have some interesting ideas too.=0A=
>>>=0A=
>>> All of Axiom's SANE types are now CLOS objects which gives=0A=
>>> two benefits. First, they can be inherited. But second, they=0A=
>>> are basically Lisp data structures with associated code.=0A=
>>>=0A=
>>> I'm thinking of associating "data axioms" with the representation=0A=
>>> (REP) object of a domain as well as with the functions.=0A=
>>>=0A=
>>> For example, DenavitHartenbergMatrix encodes 4x4 matrices=0A=
>>> used in graphics and robotics. They are 4x4 matrices where=0A=
>>> the upper left 3x3 encodes rotations, the right column encodes=0A=
>>> translations, and the lower row includes scaling, skewing, etc.=0A=
>>>=0A=
>>> (As an aside, DHMATRIX matrices have an associated=0A=
>>> Jacobian which encodes the dynamics in things like robots.=0A=
>>> Since I'm also programming a robot I'm tempted to work on=0A=
>>> extending the domain with related functions... but, as=0A=
>>> Hamming said, new algebra code isn't "the most important=0A=
>>> problem in computational mathematics").=0A=
>>>=0A=
>>> Axioms associated with the REP can assume that they are=0A=
>>> 4x4, that they can be inverted, that they have a "space" of=0A=
>>> rotations, etc. The axioms provide "facts" known to be true=0A=
>>> about the REP. (I also need to think about a "specification"=0A=
>>> for the REP but I'm not there yet).=0A=
>>>=0A=
>>> Since every category and domain is a CLOS data structure=0A=
>>> the DHMATRIX data structure inherits REP axioms from its=0A=
>>> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX=0A=
>>> adds domain-specific REP axioms (as well as domain-specific=0A=
>>> function axioms). Thus a DHMATRIX rotate function can=0A=
>>> base its proof on the fact that it only affects the upper 3x3=0A=
>>> and lives in a space of rotations, all of which can be assumed=0A=
>>> by the proof.=0A=
>>>=0A=
>>> If I use the SICP "trick" of representing data as code I can=0A=
>>> "expand" the data as part of the program proof.=0A=
>>>=0A=
>>> It is all Omphaloskepsis (navel gazing) at this point though.=0A=
>>> I'm still writing the new SANE compiler (which is wildly=0A=
>>> different from the compiler course I taught).=0A=
>>>=0A=
>>> I did give a talk at Notre Dame but I haven't attempted to=0A=
>>> publish. All of my work shows up in literate programming=0A=
>>> Axiom books on github.=0A=
>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_daly=
_PDFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxw=
cTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQI=
cLfvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D=0A=
>>> )=0A=
>>>=0A=
>>> It is all pretty pointless since nobody cares about computer=0A=
>>> algebra, proving math programs correct, or Axiom itself.=0A=
>>> Wolfram is taking up all the oxygen in the discussions.=0A=
>>>=0A=
>>> But I have to say, this research is great fun. It reminds me=0A=
>>> of the Scratchpad days, although I miss the give-and-take=0A=
>>> of the group. It is hard to recreate my role as the dumbest=0A=
>>> guy in the room when I'm stuck here by myself :-)=0A=
>>>=0A=
>>> Hope you and your family are safe and healthy.=0A=
>>>=0A=
>>> Tim=0A=
>>>=0A=
>>> PS. I think we should redefine the "Hamming Distance" as=0A=
>>> the distance between an idea and its implementation.=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:=0A=
>>>> Hi Tim:=0A=
>>>>=0A=
>>>> Glad to hear from you now and then, promoting and working towards your=
=0A=
>>>> ideas=0A=
>>>> and ideals.=0A=
>>>>=0A=
>>>>  >>We need proven algorithms.=0A=
>>>>=0A=
>>>> Just one short comment: it is often possible to prove algorithms (that=
=0A=
>>>> is,=0A=
>>>> providing the theoretical foundation for the algorithm), but it is muc=
h=0A=
>>>> harder to prove that an implementation of the algorithm is correct. As=
=0A=
>>>> you=0A=
>>>> well know, the distinction lies in that implementation involves data=
=0A=
>>>> representations whereas proofs of algorithms normally ignore them.=0A=
>>>> Introducing (finite) data representations means introducing boundary=
=0A=
>>>> situations that a programmer implementing an algorithm must deal with.=
=0A=
>>>> So=0A=
>>>> perhaps what we need to prove should include the correctness of=0A=
>>>> implementations (to the bare metal, as you often say) and we should=0A=
>>>> have=0A=
>>>> a=0A=
>>>> different set of analytic tools that can deal with the correctness (or=
=0A=
>>>> completeness) of data representations. Of course, these tools must als=
o=0A=
>>>> be=0A=
>>>> proven with the same rigor since behind every program is an algorithm.=
=0A=
>>>>=0A=
>>>> William=0A=
>>>>=0A=
>>>> William Sit=0A=
>>>> Professor Emeritus=0A=
>>>> Department of Mathematics=0A=
>>>> The City College of The City University of New York=0A=
>>>> New York, NY 10031=0A=
>>>> homepage: wsit.ccny.cuny.edu=0A=
>>>>=0A=
>>>> ________________________________________=0A=
>>>> From: Axiom-developer=0A=
>>>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on beha=
lf=0A=
>>>> of=0A=
>>>> Tim Daly <axiomcas@gmail.com>=0A=
>>>> Sent: Saturday, July 18, 2020 6:28 PM=0A=
>>>> To: axiom-dev; Tim Daly=0A=
>>>> Subject: [EXTERNAL] Re: Axiom musings...=0A=
>>>>=0A=
>>>> Richard Hamming gave a great talk. "You and Your Research"=0A=
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com=
_watch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNtm=
0U&e=3D=0A=
>>>>=0A=
>>>> His big question is:=0A=
>>>>=0A=
>>>> "What is the most important problem in your field=0A=
>>>> and why aren't you working on it?"=0A=
>>>>=0A=
>>>> To my mind, the most important problem in the field of=0A=
>>>> computational mathematics is grounding computer=0A=
>>>> algebra in proofs.=0A=
>>>>=0A=
>>>> Computer mathematical algorithms that "maybe,=0A=
>>>> possibly, give correct answers sometimes" is a problem.=0A=
>>>> Indeed, for computer algebra, it is the most important=0A=
>>>> problem. We need proven algorithms.=0A=
>>>>=0A=
>>>> New algorithms, better graphics, better documentation,=0A=
>>>> are all "nice to have" but, as Hamming would say,=0A=
>>>> they are not "the most important problem".=0A=
>>>>=0A=
>>>> Tim=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>> Time for another update.=0A=
>>>>>=0A=
>>>>> The latest Intel processors, available only to data centers=0A=
>>>>> so far, have a built-in FPGA. This allows you to design=0A=
>>>>> your own circuits and have them loaded "on the fly",=0A=
>>>>> running in parallel with the CPU.=0A=
>>>>>=0A=
>>>>> I bought a Lattice ICEstick FPGA development board. For=0A=
>>>>> the first time there are open source tools that support it so=0A=
>>>>> it is a great test bench for ideas and development. It is a=0A=
>>>>> USB drive so it can be easily ported to any PC.=0A=
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.latticese=
mi.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbut=
Qz2HFhAAAymG-QswIjRao_YTwz4&e=3D=0A=
>>>>> )=0A=
>>>>>=0A=
>>>>> I also bought a large Intel Cyclone FPGA development board.=0A=
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.co=
m.tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&c=
=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ7=
9PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3wW=
6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D=0A=
>>>>> )=0A=
>>>>> which has 2 embedded ARM processors. Unfortunately=0A=
>>>>> the tools (which are freely available) are not open source.=0A=
>>>>> It has sufficient size and power to do anything.=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> I've got 2 threads of work in progress, both of which=0A=
>>>>> involve FPGAs (Field Programmable Gate Arrays).=0A=
>>>>>=0A=
>>>>> Thread 1=0A=
>>>>>=0A=
>>>>> The first thread involves proving programs correct. Once=0A=
>>>>> a proof has been made it is rather easier to check the proof.=0A=
>>>>> If code is shipped with a proof, the proof can be loaded into=0A=
>>>>> an FPGA running a proof-checker which verifies the program=0A=
>>>>> in parallel with running the code on the CPU.=0A=
>>>>>=0A=
>>>>> I am researching the question of writing a proof checker that=0A=
>>>>> runs on an FPGA, thus verifying the code "down to the metal".=0A=
>>>>> The Lean proof checker is the current target.=0A=
>>>>>=0A=
>>>>> The idea is to make "Oracle" algorithms that, because they=0A=
>>>>> are proven correct and verified at runtime, can be trusted=0A=
>>>>> by other mathematical software (e.g. Lean, Coq, Agda)=0A=
>>>>> when used in proofs.=0A=
>>>>>=0A=
>>>>> Thread 2=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> The second thread involves arithmetic. Axiom currently ships=0A=
>>>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).=0A=
>>>>> These routines have a known set of numeric failures such as=0A=
>>>>> cancellation, underflow, and scaling.=0A=
>>>>>=0A=
>>>>> John Gustafson has designed a 'unum' numeric format that can=0A=
>>>>> eliminate many of these errors. (See=0A=
>>>>> Gustafson, John "The End of Error" CRC Press 2015=0A=
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.com=
_End-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-5=
F1-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-3=
D1593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXH=
RwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZ=
ePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hYa=
0A&e=3D=0A=
>>>>> )=0A=
>>>>>=0A=
>>>>> The research goal is to implement Axiom's floating-point=0A=
>>>>> arithmetic that can be offloaded onto an FPGA implementing=0A=
>>>>> the unum format. Such a system would radically simplify=0A=
>>>>> the implementation of BLAS and LAPACK as most of the=0A=
>>>>> errors can't occur. The impact would be similar to using=0A=
>>>>> multi-precision integer arithmetic, only now its floating-point.=0A=
>>>>>=0A=
>>>>> SANE, the greater goal.=0A=
>>>>>=0A=
>>>>> The Axiom SANE compiler / interpreter can use both of=0A=
>>>>> these tools to implement trusted mathematical software.=0A=
>>>>> It's a long, ambitious research effort but even if only pieces=0A=
>>>>> of it succeed, it changes computational mathematics.=0A=
>>>>>=0A=
>>>>> Tim=0A=
>>>>>=0A=
>>>>> "A person's reach should exceed their grasp,=0A=
>>>>> or what's a computer for?"  (misquoting Robert Browning)=0A=
>>>>>=0A=
>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab.=
com_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dexc=
eed-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctdx=
_OqsfcYl4z14qlYS02TBNmnaHUY&e=3D=0A=
>>>>> )=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>> WHY PROVE AXIOM CORRECT (SANE)?=0A=
>>>>>>=0A=
>>>>>> Historically, Axiom credits CLU, the Cluster language by=0A=
>>>>>> Barbara Liskov, with the essential ideas behind the Spad=0A=
>>>>>> language. Barbara gave a talk (a partial transcript below)=0A=
>>>>>> that gives the rational behind the ``where clause'' used by=0A=
>>>>>> Spad.=0A=
>>>>>>=0A=
>>>>>> She talks about the limits of the compile time capablity.=0A=
>>>>>> In particular, she says:=0A=
>>>>>>=0A=
>>>>>>    To go further, where we would say that T,=0A=
>>>>>>    in addition, has to be an equality relation, that requires=0A=
>>>>>>    much more sophisticated techniques that, even today, are=0A=
>>>>>>    beyond the capabilities of the compiler.=0A=
>>>>>>=0A=
>>>>>> Showing that the ``equal'' function satisfies the equality=0A=
>>>>>> relation is no longer ``beyond the capabilities of the compiler''.=
=0A=
>>>>>> We have the required formalisms and mechanisms to=0A=
>>>>>> prove properties at compile time.=0A=
>>>>>>=0A=
>>>>>> The SANE effort is essentially trying to push compile=0A=
>>>>>> time checking into proving that, for categories that use=0A=
>>>>>> ``equal'', we prove that the equal function implements=0A=
>>>>>> equality.=0A=
>>>>>>=0A=
>>>>>> I strongly encourage you to watch her video.=0A=
>>>>>>=0A=
>>>>>> Tim=0A=
>>>>>>=0A=
>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
>>>>>> Barbara Liskov=0A=
>>>>>> May 2012=0A=
>>>>>> MIT CSAIL=0A=
>>>>>> Programming the Turing Machine=0A=
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.c=
om_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZ=
XHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfX=
NZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZhS=
1eGY&e=3D=0A=
>>>>>>=0A=
>>>>>> POLYMORPHISM=0A=
>>>>>>=0A=
>>>>>> We don't just want a set, we want polymorphism or=0A=
>>>>>> generics, as they are called today. We wanted to=0A=
>>>>>> have a generic set which was paramaterized by type=0A=
>>>>>> so you could instantiate it as:=0A=
>>>>>>=0A=
>>>>>> Set =3D [T:type] create, insert,...=0A=
>>>>>>   % representation for Set object=0A=
>>>>>>   % implementation of Set operations=0A=
>>>>>>   Set=0A=
>>>>>>=0A=
>>>>>> Set[int] s :=3D Set[int]$create()=0A=
>>>>>> Set[int]$insert(s,3)=0A=
>>>>>>=0A=
>>>>>> We wanted a static solution to this problem. The=0A=
>>>>>> problem is, not every type makes sense as a parameter=0A=
>>>>>> to Set of T. For sets, per se, you need an equality=0A=
>>>>>> relation. If it has been a sorted set we would have=0A=
>>>>>> some ordering relation. And a type that didn't have=0A=
>>>>>> one of those things would not have been a legitimate=0A=
>>>>>> parameter. We needed a way of expressing that in a=0A=
>>>>>> compile-time, checkable manner. Otherwise we would=0A=
>>>>>> have had to resort to runtime checking.=0A=
>>>>>>=0A=
>>>>>> Our solution was=0A=
>>>>>>=0A=
>>>>>> Set =3D [T:  ] create, insert,...=0A=
>>>>>>   T equal: (T,T) (bool)=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>> Our solution, what we call the ``where clause''. So we=0A=
>>>>>> added this to the header. The ``where clause'' tells you=0A=
>>>>>> what operations the parameter type has to have.=0A=
>>>>>>=0A=
>>>>>> If you have the ``where'' clause you can do the static=0A=
>>>>>> checking because when you instantiate, when you provide=0A=
>>>>>> an actual type, the compiler can check that the type has=0A=
>>>>>> the operations that are required. And then, when you write=0A=
>>>>>> the implementation of Set the compiler knows it's ok to=0A=
>>>>>> call those operations because you can guarantee they are=0A=
>>>>>> actually there when you get around to running.=0A=
>>>>>>=0A=
>>>>>> Of course, you notice that there's just syntax here; there's=0A=
>>>>>> no semantics.=0A=
>>>>>>=0A=
>>>>>> As I'm sure you all know, compile-time type checking is=0A=
>>>>>> basically a proof technique of a very limited sort and=0A=
>>>>>> this was about as far as we can push what you could get out of the=
=0A=
>>>>>> static analysis. To go further, where we would say that T,=0A=
>>>>>> in addition, has to be an equality relation, that requires=0A=
>>>>>> much more sophisticated techniques that, even today, are=0A=
>>>>>> beyond the capabilities of the compiler.=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>>=0A=
>>>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>> I've spent entirely too much time studing the legal issues=0A=
>>>>>>> of free and open source software. There are copyright,=0A=
>>>>>>> trademark, and intellectual property laws. I have read=0A=
>>>>>>> several books, listened to lectures, and read papers on=0A=
>>>>>>> the subject. I've spoken to lawyers about it. I've even=0A=
>>>>>>> been required, by law, to coerce people I respect.=0A=
>>>>>>> You would think it was all perfectly clear. It isn't.=0A=
>>>>>>>=0A=
>>>>>>> The most entertaining and enlightening lectures were=0A=
>>>>>>> by Robert Lefkowitz at OSCON 2004. His talk is=0A=
>>>>>>> "The Semasiology of Open Source", which sounds=0A=
>>>>>>> horrible but I assure you, this is a real treat.=0A=
>>>>>>>=0A=
>>>>>>> THE THESIS=0A=
>>>>>>>=0A=
>>>>>>> Semasiology, n. The science of meanings or=0A=
>>>>>>> sense development (of words); the explanation=0A=
>>>>>>> of the development and changes of the meanings=0A=
>>>>>>> of words. Source: Webster's Revised Unabridged=0A=
>>>>>>> Dictionary, =EF=BF=BD 1996, 1998 MICRA, Inc.=0A=
>>>>>>>=0A=
>>>>>>> "Open source doesn't just mean access to the=0A=
>>>>>>> source code." So begins the Open Source Definition.=0A=
>>>>>>> What then, does access to the source code mean?=0A=
>>>>>>> Seen through the lens of an Enterprise user, what=0A=
>>>>>>> does open source mean? When is (or isn't) it=0A=
>>>>>>> significant? And a catalogue of open source=0A=
>>>>>>> related arbitrage opportunities.=0A=
>>>>>>>=0A=
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conver=
sationsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-252=
0of-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrk=
ZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDf=
XNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFcn=
EbusM&e=3D=0A=
>>>>>>>=0A=
>>>>>>> Computer source code has words and sentence=0A=
>>>>>>> structure like actual prose or even poetry. Writing=0A=
>>>>>>> code for the computer is like writing an essay. It=0A=
>>>>>>> should be written for other people to read,=0A=
>>>>>>> understand and modify. These are some of the=0A=
>>>>>>> thoughts behind literate programming proposed=0A=
>>>>>>> by Donald Knuth. This is also one of the ideas=0A=
>>>>>>> behind Open Source.=0A=
>>>>>>>=0A=
>>>>>>>  THE ANTITHESIS=0A=
>>>>>>>=0A=
>>>>>>> "Open Source" is a phrase like "Object Oriented"=0A=
>>>>>>> - weird at first, but when it became popular, the=0A=
>>>>>>> meaning began to depend on the context of the=0A=
>>>>>>> speaker or listener. "Object Oriented" meant that=0A=
>>>>>>> PERL, C++, Java, Smalltalk, Basic and the newest=0A=
>>>>>>> version of Cobol are all "Object Oriented" - for some=0A=
>>>>>>> specific definition of "Object Oriented". Similar is=0A=
>>>>>>> the case of the phrase "Open Source".=0A=
>>>>>>>=0A=
>>>>>>> In Part I, Lefkowitz talked about the shift of the=0A=
>>>>>>> meaning of "Open Source" away from any reference=0A=
>>>>>>> to the actual "source code," and more towards other=0A=
>>>>>>> phases of the software development life cycle. In=0A=
>>>>>>> Part II, he returns to the consideration of the=0A=
>>>>>>> relationship between "open source" and the actual=0A=
>>>>>>> "source code," and reflects upon both the way=0A=
>>>>>>> forward and the road behind, drawing inspiration=0A=
>>>>>>> from Charlemagne, King Louis XIV, Donald Knuth,=0A=
>>>>>>> and others.=0A=
>>>>>>>=0A=
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conver=
sationsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIFa=
Q&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwW=
YZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D=
LTgLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D=0A=
>>>>>>>=0A=
>>>>>>> THE SYNTHESIS=0A=
>>>>>>>=0A=
>>>>>>> In a fascinating synthesis, Robert "r0ml" Lefkowitz=0A=
>>>>>>> polishes up his exposition on the evolving meaning=0A=
>>>>>>> of the term 'open source'. This intellectual joy-ride=0A=
>>>>>>> draws on some of the key ideas in artificial intelligence=0A=
>>>>>>> to probe the role of language, meaning and context=0A=
>>>>>>> in computing and the software development process.=0A=
>>>>>>> Like Wittgenstein's famous thought experiment, the=0A=
>>>>>>> open source 'beetle in a box' can represent different=0A=
>>>>>>> things to different people, bearing interesting fruit for=0A=
>>>>>>> philosophers and software creators alike.=0A=
>>>>>>>=0A=
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversat=
ionsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4N=
mamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSW=
MRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8thoI=
wON-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D=0A=
>>>>>>>=0A=
>>>>>>>=0A=
>>>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>> I've pushed the lastest version of Axiom. The plan, followed=0A=
>>>>>>>> so far, is to push once a month on the 7th.=0A=
>>>>>>>>=0A=
>>>>>>>> After some chat room interactions it was brought home=0A=
>>>>>>>> again that the proof world really does not seem to like the=0A=
>>>>>>>> idea of proving programs correct. And, given that it was is=0A=
>>>>>>>> of the main Axiom goals and a point of friction during the fork,=
=0A=
>>>>>>>> the computer algebra world does not like the idea of proving=0A=
>>>>>>>> programs correct either.=0A=
>>>>>>>>=0A=
>>>>>>>> So the idea of "computational mathematics", which includes=0A=
>>>>>>>> both disciplines (as well as type theory) seems still a long=0A=
>>>>>>>> way off.=0A=
>>>>>>>>=0A=
>>>>>>>> Nevertheless, the primary change in these past and future=0A=
>>>>>>>> updates is focused on merging proof and computer algebra.=0A=
>>>>>>>>=0A=
>>>>>>>> Proof systems are able to split the problem of creating a=0A=
>>>>>>>> proof and the problem of verifying a proof, which is much=0A=
>>>>>>>> cheaper. Ideally the proof checker would run on verified=0A=
>>>>>>>> hardware so the proof is checked "down to the metal".=0A=
>>>>>>>>=0A=
>>>>>>>> I have a background in Field Programmable Gate Arrays=0A=
>>>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm=0A=
>>>>>>>> looking at creating a hardware proof checker using a=0A=
>>>>>>>> dedicated instruction set, one designed to be verifed.=0A=
>>>>>>>> New CPUs used in data centers (not yet available to us=0A=
>>>>>>>> mortals) have built-in FPGAs so it would be possible to=0A=
>>>>>>>> "side-load" a proof of a program to be checked while the=0A=
>>>>>>>> program is run. I have the FPGA and am doing a gate-level=0A=
>>>>>>>> special instruction design for such a proof checker.=0A=
>>>>>>>>=0A=
>>>>>>>>=0A=
>>>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>> As a mathematician, it is difficult to use a system like Axiom,=
=0A=
>>>>>>>>> mostly because it keeps muttering about Types. If you're not=0A=
>>>>>>>>> familiar with type theory (most mathematicians aren't) then it=0A=
>>>>>>>>> seems pointless and painful.=0A=
>>>>>>>>>=0A=
>>>>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>>>>=0A=
>>>>>>>>> As a mathematician with an algorithmic approach, it is difficult=
=0A=
>>>>>>>>> to use a system like Axiom, mostly because you have to find=0A=
>>>>>>>>> or create "domains" or "packages", understand categories=0A=
>>>>>>>>> with their inheritance model, and learn a new language with=0A=
>>>>>>>>> a painful compiler always complaining about types.=0A=
>>>>>>>>>=0A=
>>>>>>>>> So Axiom has a steep learning curve.=0A=
>>>>>>>>>=0A=
>>>>>>>>> The Sane version of Axiom requires knowing the mathematics.=0A=
>>>>>>>>> It also assumes a background in type theory, inductive logic,=0A=
>>>>>>>>> homotopy type theory, ML (meta-language, not machine=0A=
>>>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,=
=0A=
>>>>>>>>> and tacticals. Also assumed is knowledge of specification=0A=
>>>>>>>>> languages,=0A=
>>>>>>>>> Hoare triples, proof techniques, soundness, and completeness.=0A=
>>>>>>>>> Oh, and there is a whole new syntax and semantics added to=0A=
>>>>>>>>> specify definitions, axioms, and theorems, not to mention whole=
=0A=
>>>>>>>>> libraries of the same.=0A=
>>>>>>>>>=0A=
>>>>>>>>> So Axiom Sane has a steep learning curve.=0A=
>>>>>>>>>=0A=
>>>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years=0A=
>>>>>>>>> learning to read the leading edge literature (also known=0A=
>>>>>>>>> as "greek studies", since every paper has pages of greek).=0A=
>>>>>>>>>=0A=
>>>>>>>>> I'm trying to unify computer algebra and proof theory into a=0A=
>>>>>>>>> "computational mathematics" framework. I suspect that the only=0A=
>>>>>>>>> way this system will ever be useful is after Universities have a=
=0A=
>>>>>>>>> "Computational Mathematics" major course of study and degree.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Creating a new department is harder than creating Axiom Sane=0A=
>>>>>>>>> because, you know, ... people.=0A=
>>>>>>>>>=0A=
>>>>>>>>> I think such a department is inevitable given the deep and wide=
=0A=
>>>>>>>>> impact of computers, just not in my lifetime. That's ok. When I=
=0A=
>>>>>>>>> started programming there was no computer science degree.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Somebody has to be the first lemming over the cliff.=0A=
>>>>>>>>>=0A=
>>>>>>>>> Tim=0A=
>>>>>>>>>=0A=
>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)=
=0A=
>>>>>>>>>> there is a certain amount of verification that is involved.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for its=
=0A=
>>>>>>>>>> algorithms. Ideally, when a computation is requested from Lean=
=0A=
>>>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm is=
=0A=
>>>>>>>>>> returned. Lean can the verify that the proof is valid. But it is=
=0A=
>>>>>>>>>> computationally more efficient if Axiom and Lean use a=0A=
>>>>>>>>>> cryptographic=0A=
>>>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be=0A=
>>>>>>>>>> 'reproven', only a hash computation over the proof text needs to=
=0A=
>>>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to b=
e=0A=
>>>>>>>>>> exchanged without re-running the proof mechanism. Since a large=
=0A=
>>>>>>>>>> computation request from Lean might involve many algorithms=0A=
>>>>>>>>>> there would be considerable overhead to recompute each proof.=0A=
>>>>>>>>>> A hash simplifies the issue yet provides proof integrity.=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> Tim=0A=
>>>>>>>>>>=0A=
>>>>>>>>>>=0A=
>>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> A computer algebra system ought to know and ought to provide=0A=
>>>>>>>>>>> information about the domain and range of a resulting formula.=
=0A=
>>>>>>>>>>> I've been pushing this effort since the 1980s (hence the=0A=
>>>>>>>>>>> SuchThat domain).=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> It turns out that computing with, carrying, and combining this=
=0A=
>>>>>>>>>>> information is difficult if not impossible in the current=0A=
>>>>>>>>>>> system.=0A=
>>>>>>>>>>> The information isn't available and isn't computed. In that=0A=
>>>>>>>>>>> sense,=0A=
>>>>>>>>>>> the original Axiom system is 'showing its age'.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> In the Sane implementation the information is available. It is=
=0A=
>>>>>>>>>>> part of the specification and part of the proof steps. With a=
=0A=
>>>>>>>>>>> careful design it will be possible to provide provisos for each=
=0A=
>>>>>>>>>>> given result that are carried with the result for use in furthe=
r=0A=
>>>>>>>>>>> computation.=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> This raises interesting questions to be explored. For example,=
=0A=
>>>>>>>>>>> if the formula is defined over an interval, how is the interval=
=0A=
>>>>>>>>>>> arithmetic handled?=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Exciting research ahead!=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>>=0A=
>>>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>> Trusted Kernel... all the way to the metal.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> While building a trusted computer algebra system, the=0A=
>>>>>>>>>>>> SANE version of Axiom, I've been looking at questions of=0A=
>>>>>>>>>>>> trust at all levels.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a=0A=
>>>>>>>>>>>> trusted kernel through which all other computations must=0A=
>>>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base=0A=
>>>>>>>>>>>> their kernel  on logic like the Calculus of Construction or=0A=
>>>>>>>>>>>> something similar.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a=0A=
>>>>>>>>>>>> nucleus) that separates the trust from the logic. The rules=0A=
>>>>>>>>>>>> for the logic can be specified as needed but checked by=0A=
>>>>>>>>>>>> the nucleus code.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)=0A=
>>>>>>>>>>>> that allow you to create your own hardware in a C-like=0A=
>>>>>>>>>>>> language (Verilog). It allows you to check the chip you build=
=0A=
>>>>>>>>>>>> all the way down to the transistor states. You can create=0A=
>>>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted=0A=
>>>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a=0A=
>>>>>>>>>>>> history of verifying hardware logic.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> It appears that, assuming I can understand Bauers=0A=
>>>>>>>>>>>> Andromeda system, it would be possible and not that hard=0A=
>>>>>>>>>>>> to implement a trusted kernel on an FPGA the size and=0A=
>>>>>>>>>>>> form factor of a USB stick.=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Trust "down to the metal".=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>>=0A=
>>>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Recently I've been musing about methods to insert axioms=0A=
>>>>>>>>>>>>> into categories so they could be inherited like signatures.=
=0A=
>>>>>>>>>>>>> At the moment I've been thinking about adding axioms in=0A=
>>>>>>>>>>>>> the same way that signatures are written, adding them to=0A=
>>>>>>>>>>>>> the appropriate categories.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> But this is an interesting design question.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures=0A=
>>>>>>>>>>>>> from categories. That is, we can bet a plus signature from,=
=0A=
>>>>>>>>>>>>> say, the Integer category.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom=0A=
>>>>>>>>>>>>> inherits certain so-called "attributes", such as=0A=
>>>>>>>>>>>>> ApproximateAttribute,=0A=
>>>>>>>>>>>>> which implies that the results are only approximate.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive=
=0A=
>>>>>>>>>>>>> property by defining it in its own category. In fact, if we=
=0A=
>>>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,=0A=
>>>>>>>>>>>>> where each property has its own inheritable category,=0A=
>>>>>>>>>>>>> we can "mix and match" the axioms at will.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> An "axiom" category would also export a function. This=0A=
>>>>>>>>>>>>> function=0A=
>>>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would=0A=
>>>>>>>>>>>>> modify=0A=
>>>>>>>>>>>>> the proof step by applying the function to the step.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Theorems would have the same structure.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> This allows theorems to be constructed at run time (since=0A=
>>>>>>>>>>>>> Axiom supports "First Class Dynamic Types".=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad=
=0A=
>>>>>>>>>>>>> language so that Spad statements (e.g. assignment) had=0A=
>>>>>>>>>>>>> proof-related properties. A range such as [1..10] would=0A=
>>>>>>>>>>>>> provide explicit bounds in a proof "by language definition".=
=0A=
>>>>>>>>>>>>> Defining the logical properties of language statements in=0A=
>>>>>>>>>>>>> this way would make it easier to construct proofs since the=
=0A=
>>>>>>>>>>>>> invariants would be partially constructed already.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> This design merges the computer algebra inheritance=0A=
>>>>>>>>>>>>> structure with the proof of algorithms structure, all under=
=0A=
>>>>>>>>>>>>> the same mechanism.=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.c=
s.kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1t=
bVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ry=
qOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq5=
xsNk1_eii0&e=3D=0A=
>>>>>>>>>>>>>> ) on=0A=
>>>>>>>>>>>>>> Seven deadly sins of talking about "types"=0A=
>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.c=
s.kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt6=
2fTbqv-K98dBQv0oMmB82kE8mXo&e=3D=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> He raised an interesting idea toward the end of the essay=0A=
>>>>>>>>>>>>>> that type-checking could be done outside the compiler.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.=0A=
>>>>>>>>>>>>>> It would be possible to run a program over the source code=
=0A=
>>>>>>>>>>>>>> to collect the information and write a stand-alone type=0A=
>>>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Taken further I can think of several other kinds of checkers=
=0A=
>>>>>>>>>>>>>> (aka 'linters') that could be unbundled.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> It is certainly something to explore.=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer=0A=
>>>>>>>>>>>>>>> blows of reality", to coin a phrase.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> There are many goals. One of the primary goals is creating =
a=0A=
>>>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.=
=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> So the latest changes involved adding multiple index files.=
=0A=
>>>>>>>>>>>>>>> These are documentation (links to where terms are mentioned=
=0A=
>>>>>>>>>>>>>>> in the text), code (links to the implementation of things),=
=0A=
>>>>>>>>>>>>>>> error (links to where errors are defined), signatures (link=
s=0A=
>>>>>>>>>>>>>>> to=0A=
>>>>>>>>>>>>>>> the signatures of lisp functions), figures (links to=0A=
>>>>>>>>>>>>>>> figures),=0A=
>>>>>>>>>>>>>>> and separate category, domain, and package indexes.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"=
=0A=
>>>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of=
=0A=
>>>>>>>>>>>>>>> those diagrams follows immediately. Collectively these will=
=0A=
>>>>>>>>>>>>>>> eventually define at least the syntax of the language. In=
=0A=
>>>>>>>>>>>>>>> the=0A=
>>>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm=
=0A=
>>>>>>>>>>>>>>> not that clever.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Reality shows up with the curent constraint that the=0A=
>>>>>>>>>>>>>>> compiler should accept the current Spad language as=0A=
>>>>>>>>>>>>>>> closely as possible. Of course, plans are to include new=0A=
>>>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)=0A=
>>>>>>>>>>>>>>> but these are being postponed until "syntax complete".=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> All parse information is stored in a parse object, which=0A=
>>>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)=0A=
>>>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also=0A=
>>>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).=0A=
>>>>>>>>>>>>>>> It's types all the way down.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> These types are being used as 'signatures' for the=0A=
>>>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the=0A=
>>>>>>>>>>>>>>> compiler implementation as well as the Sane language.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> The parser is designed to "wrap around" so that the=0A=
>>>>>>>>>>>>>>> user-level output of a parse should be the user-level=0A=
>>>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"=
=0A=
>>>>>>>>>>>>>>> should make it easy to see that the parser properly=0A=
>>>>>>>>>>>>>>> parsed the user input.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> The parser is "first class" so it will be available at=0A=
>>>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct=0A=
>>>>>>>>>>>>>>> Spad code.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some=0A=
>>>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How=0A=
>>>>>>>>>>>>>>> this will happen is still in the land of design. This would=
=0A=
>>>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is=
=0A=
>>>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp=0A=
>>>>>>>>>>>>>>> functions (with CLOS types as signatures) would be=0A=
>>>>>>>>>>>>>>> avaiable for implementing Spad functions. This not=0A=
>>>>>>>>>>>>>>> only improves the efficiency, it would make the=0A=
>>>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.=0A=
>>>>>>>>>>>>>>> .=0A=
>>>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods=0A=
>>>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to=0A=
>>>>>>>>>>>>>>> know how little I know, especially that I need to know.=0A=
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.a=
ndrew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCo=
C6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkx=
c&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkHC=
x-3GFVk62hxr53YKr4naRk&e=3D=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:=
=0A=
>>>>>>>>>>>>>>>> The underlying technology to use for building such an=0A=
>>>>>>>>>>>>>>>> algebra=0A=
>>>>>>>>>>>>>>>> library=0A=
>>>>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds between=
=0A=
>>>>>>>>>>>>>>>> Theories:=0A=
>>>>>>>>>>>>>>>> Theory Presentation Combinators"=0A=
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.=
cas.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3ry=
VeFoBjl0AZs2cuQZhKuIxk8NUw&e=3D=0A=
>>>>>>>>>>>>>>>> [which=0A=
>>>>>>>>>>>>>>>> will=0A=
>>>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to =
a=0A=
>>>>>>>>>>>>>>>> journal].=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well=0A=
>>>>>>>>>>>>>>>> documented=0A=
>>>>>>>>>>>>>>>> at=0A=
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__alh=
assy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.htm=
l&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6=
sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8=
bDzgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> (source at=0A=
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__git=
hub.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZB=
B5fBQOj0-Q48CUKRS1VNLao&e=3D=0A=
>>>>>>>>>>>>>>>> ).=0A=
>>>>>>>>>>>>>>>> It=0A=
>>>>>>>>>>>>>>>> is=0A=
>>>>>>>>>>>>>>>> literate source.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> The old prototype was hard to find - it is now at=0A=
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__git=
hub.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1=
tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6r=
yqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDIT=
FQRpkFBgg8c&e=3D=0A=
>>>>>>>>>>>>>>>> .=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it=
=0A=
>>>>>>>>>>>>>>>> does=0A=
>>>>>>>>>>>>>>>> not=0A=
>>>>>>>>>>>>>>>> quite=0A=
>>>>>>>>>>>>>>>> function properly today, it is under repair.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"=0A=
>>>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__al=
hassy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage-=
5Ffeature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KT=
nUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih=
0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5B=
0zits8pEczWsib7Q7_mxyRIxhk&e=3D=0A=
>>>>>>>>>>>>>>>> )=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrized=
=0A=
>>>>>>>>>>>>>>>> theories=0A=
>>>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all=0A=
>>>>>>>>>>>>>>>> current=0A=
>>>>>>>>>>>>>>>> systems=0A=
>>>>>>>>>>>>>>>> suffer from.=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> Jacques=0A=
>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:=0A=
>>>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Frica=
s=0A=
>>>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but=
=0A=
>>>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It shoul=
d=0A=
>>>>>>>>>>>>>>>>> be=0A=
>>>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories"=
=0A=
>>>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much=0A=
>>>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like th=
e=0A=
>>>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) supports=
=0A=
>>>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.=
=0A=
>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU=0A=
>>>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just=0A=
>>>>>>>>>>>>>>>>>> another front-end language" supported by GCC.=0A=
>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)=
=0A=
>>>>>>>>>>>>>>>>>> make any decision about the runtime implementation.=0A=
>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>> Tim=0A=
>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses")=0A=
>>>>>>>>>>>>>>>>>>> developed=0A=
>>>>>>>>>>>>>>>>>>> a dependently typed general parser for context free=0A=
>>>>>>>>>>>>>>>>>>> grammar=0A=
>>>>>>>>>>>>>>>>>>> in Coq.=0A=
>>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.=0A=
>>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.=0A=
>>>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider=0A=
>>>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.=0A=
>>>>>>>>>>>>>>>>>>>=0A=
>>>>>>>>>>>>>>>>>>> Tim=0A=

\start
Date: Thu, 30 Jul 2020 07:28:59 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-developer@nongnu.org, axiomcas@gmail.com
Subject: Re: Axiom musings...

This is the video related to the Deep Learning for Symbolic
Mathematics paper.

https://www.youtube.com/watch?v=3DO_sHHG5_lr8&list=3DPLoROMvodv4rMWw6rRoeSp=
kiseTHzWj6vu&index=3D5

I've spent a fair amount of time running some of the
generated problems through Axiom for fuzz testing.

Sometimes we get exact results, or exact up to a constant.
More interesting is that it uncovers some bugs.
I expect to push out some of the results in August.

Tim


On 7/26/20, William Sit <wsit@ccny.cuny.edu> wrote:
> The question of equality in computation is very different than equality i=
n
> mathematics and it is basically due to data representations in computatio=
n
> (and for this question, we are not even  concerned with equality between =
two
> implementations of the same domain but different representations (types),
> when coercion is needed). As you pointed out, the key question is: "what
> should be the definition of equality?" even within one single domain and =
one
> data representation.
> Arithmetic in any floating point number system does not satisfy many of t=
he
> usual laws. For example, a times (b divided by a) is NOT b in such a syst=
em
> unless the system is FP(2,1,c).
> Here FP(r,p,c) is the floating point system with radix r, precision p, an=
d c
> for chopping (truncation).
>  The associative laws of addition and multiplication do NOT hold in
> FP(r,p,c). Strict inequality (less than) between two FP(r,p,c) numbers ca=
n
> be weakened to (less than or equal to) after say adding a third number or
> multiplied by a positive number. Ref: Pat.  H. Sterbenz, Floating Point
> Computation,Sections 1.6, 1.7.
>
> So to prove correctness of implementation for an algorithm, say like taki=
ng
> square roots, will be far more difficult than the same for integers. How =
can
> one be convinced that the computation gives the most accurate square root
> for all inputs in the system FP(r,p,c)? In fact, is there such an algorit=
hm
> other than one based on case considerations for every number in
> FP(r,p,c)---you may as well use a lookup table in that case.
>
> In the case of polynomial equality between two domains, one can always do=
 a
> subtraction in the domain of the target of coercion to verify equality. F=
or
> the specific example you gave, I would agree with Cubical type theory
> (whatever that is!) that they should be considered equal (unless there is=
 a
> problem with computing the LCM of denominators of the coefficients).
>
> William
>
> William Sit
> Professor Emeritus
> Department of Mathematics
> The City College of The City University of New York
> New York, NY 10031
> homepage: wsit.ccny.cuny.edu
>
> ________________________________________
> From: Tim Daly <axiomcas@gmail.com>
> Sent: Saturday, July 25, 2020 5:18 AM
> To: William Sit
> Cc: axiom-dev
> Subject: Re: [EXTERNAL] Re: Axiom musings...
>
> The further I get into this game, the harder it becomes.
>
> For example, equality. In the easiest case Axiom has
> propositional equality. That is, the equality function is
> defined by the type, e.g. for the type Integer, 2 =3D 2.
>
> However, there is also judgmental equality, which
> would apply at the type level. If floating point numbers
> match the usual IEEE definition and UNUMs match
> Gustafson's Type I defintion, is there an equality
> between the types? Does FLOAT =3D UNUM?
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__en.wikipedia.org_w=
iki_Unum-5F-28number-5Fformat-29&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1t=
bVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DY2MBHv=
ioPEtIrgddTGyKqAMzQ_VeElXxUnvWAYX19HU&s=3DtIo8U5fkmzZuvhbq0yoSyRwBb-h2udDjf=
QfIkCK6qCY&e=3D
>
> Axiom's coerce provides a (poorly) defined kind of
> judgmental equality but its not actually defined as an
> equality at the type level. You can coerce from
> POLY(FRAC(INT)) to FRAC(POLY(INT)) but are they
> equal? Cubical type theory would seem to say yes.
>
> And don't get me started on the Univalent axiom.
>
> There are lots of interesting equality questions. If there
> is a proof of a program and you can regenerate the
> program from the proof, are the proof and program equal?
>
> Presumably the chap behind the SANE effort will be
> able to handle both kinds of equality (as well as giving
> universes for types).
>
> But I suspect he's not that clever.
>
>
>
> On 7/21/20, Tim Daly <axiomcas@gmail.com> wrote:
>>> Yes, I do remember we worked on the "symbolic integer"
>>> (or "symbolic polynomial", etc.) domains.
>>
>> Sadly only the idea survives.
>>
>> I spent almost all of my time at that time trying to get a
>> version of Axiom to bootstrap. Starting Axiom, at the time,
>> required an already running version of Axiom (the NAG
>> version) and NAG would not let me distribute their code.
>>
>> Building a self-booting version involved (among a lot of
>> other things) breaking circular definitions in the category
>> and domain hierarchy. That took several months and all
>> of my time (much to Baumslag's annoyance).
>>
>> That effort also involved re-writing code from Norman's
>> Lisp back to Common Lisp (much to Norman's annoyance)
>>
>> As a result, the free version of Axiom wasn't released until
>> about 2003 even though I got a copy in 2001. As part of my
>> employment agreement with CCNY they wouldn't make any
>> claim on Axiom and I would only work on it in my free time
>> unless Gilbert said otherwise. My work time was spent as
>> the Magnus lead developer and open sourcing it. Gilbert
>> eventually wanted Axiom and asked me to do it for work
>> also. That's what led to the grant proposal.
>>
>> My thoughts on the subject of symbolic integers were, as a
>> consequence, only "paper experiments". I have several
>> thousand technical papers stacked in my office and library.
>> The CCNY notes are in there somewhere. Unfortunately,
>> every time I pick up a pile to search I find other things I
>> "need to know now" and get lost in that subject. It is like
>> trying to get a glass of water when the three gorges dam
>> burst.
>>
>> It seems feasible to create a SYMINT Symbolic Integer
>> domain that used symbols rather than numbers for the
>> arithmetic, creating a ring that could be used by POLY.
>> Using SYMINT in SYMFRAC Symboiic Fraction would
>> provide a field that could be used by POLY.
>>
>> The idea is still worth the effort but, as usual, I am deep
>> into rebuilding Axiom from the ground up. The issues I'm
>> struggling with now make the bootstrap effort look like a
>> weekend hack. Bootstrapping took about several months.
>> The current effort has taken 6 years so far. There is SO
>> much to know and I am a slow learner.
>>
>> This is where I wish I had graduate students :-)
>>
>> Tim
>>
>>
>> On 7/21/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>> Dear Tim:
>>>
>>> You have expanded on the issues I raised. While you are right that a
>>> computational algorithm can be proved if the specifications are
>>> completely
>>> and precisely coded for the proof systems like Coq. The catch is not th=
e
>>> precisely part but the completely part.
>>>
>>> Yes, I do remember we worked on the "symbolic integer" (or "symbolic
>>> polynomial", etc.) domains. I think I might have actually some notes an=
d
>>> ideas and perhaps code, but it would take me more searching than I can =
do
>>> now from obsoleted and perhaps non-functional computers. A few days ago=
,
>>> I
>>> was trying to recover tex files from a Raspberry Pi that I used while i=
n
>>> a
>>> hotel in China (2015), but nothing (meaning ftp and other transfer
>>> methods
>>> or even mailing programs) works because of security. I have also
>>> forgotten
>>> all my knowledge on Linux.
>>>
>>> Too bad we did not continue that effort. Does such a domain (in any
>>> computer
>>> algebra system) exist these days? After all, nearly three decades have
>>> passed.
>>>
>>> William
>>>
>>> William Sit
>>> Professor Emeritus
>>> Department of Mathematics
>>> The City College of The City University of New York
>>> New York, NY 10031
>>> homepage: wsit.ccny.cuny.edu
>>>
>>> ________________________________________
>>> From: Tim Daly <axiomcas@gmail.com>
>>> Sent: Monday, July 20, 2020 4:44 PM
>>> To: William Sit
>>> Cc: axiom-dev
>>> Subject: Re: [EXTERNAL] Re: Axiom musings...
>>>
>>>> So there are two kinds of algorithms, one that is purely mathematical
>>>> and one that is computational, the latter including a particular (clas=
s
>>>> of)
>>>> data representation(s) (perhaps even the computer language and
>>>> system of the implementation). It is proofs for the latter type of
>>>> algorithms that is lacking.
>>>
>>> There are ,as you point out, several kinds of proofs to consider.
>>>
>>> One is the proof of the algorithm. An example is Buchberger's
>>> Groebner Basis algorithm which was proven in Coq:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ricam.oeaw.a=
c.at_specsem_srs_groeb_download_coq-2Dlinz.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlm=
YIU&m=3DqJcX0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3D48_B3YVCzXBpYUWOgsu=
SY0mMrrZd9SpQzWVZki-c6d4&e=3D
>>>
>>> The Coq proof establishes that the formal algorithm is correct.
>>>
>>> Even in proof one runs into limits of what can be proved. For example,
>>> if the convergence is non-uniform one can, at best, do a proof that
>>> assumes bounds on the non-uniform behavior. So this isn't strictly
>>> a computer algorithm issue.
>>>
>>>> Since data representations (like REP in Axiom) are built recursively,
>>>> a computational algorithm (in the sense above) for Groebner basis
>>>> may have to be designed to take care of just a few of the ways
>>>> integers can be represented. Axiom is built with that in mind (that's
>>>> where type theory comes in), but I bet no one SPECIFIES their
>>>> computational algorithms with the limitations of data representation
>>>> in mind, much less proves the algorithm anew for each new
>>>> representation.
>>>
>>> If you remember, while we were both at CCNY, I worked on a
>>> grant project to construct a "symbolic integer" domain so that
>>> computations could occur over non-numeric integers. The
>>> symbolic form did not have a numeric limitation. Unfortunatly
>>> the current Axiom has no way to support such a domain.
>>>
>>> I'm glad you brought this up. I will have to give some thought
>>> to representing and computing with symbolic integers again.
>>>
>>>> So if a computation of a Groebner basis halts
>>>> because of an intermediate LCM computation (say of two integer
>>>> coefficients), should we consider the implementation as proven
>>>> correct? What if the overflow condition was not detected and the
>>>> computation continues? Indeed, since there may be different
>>>> implementations of the integer domain, we must be sure that
>>>> every implementation of the LCM algorithm handles overflows
>>>> correctly AND specified in the documentation.
>>>
>>> Establishing that the algorithm is correct (e.g Groebner) is
>>> clearly in the proof side of computational math
>>> .
>>> Establishing that there is an implementation of Groebner is
>>> clearly in the computer algebra side of computational math.
>>>
>>> The game is to unite the two.
>>>
>>> Such a proof becomes a PART of the specification of a program
>>> that implements the algorithm, such as in Axiom.
>>>
>>> The definitions and axioms of the proof have to be put into
>>> the system both at the category and domain levels. They
>>> need to be available at the implementation code.
>>>
>>> On the other hand, there are non-logical 'axioms' of
>>> categories and domains, such as limits to the size of a
>>> floating point number. One could have many FLOAT
>>> domains, such as Gustafson's UNUMs.
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.johngustafson=
.net_pdfs_BeatingFloatingPoint.pdf&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV=
1tbVKrkZXHRwtIMGmo&r=3DpGhsxwcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DqJcX=
0eywVfbeyLAuiHayc0VdCrprfGa-v65dRgMKAuE&s=3Dwrah9xCIC0aDYjDhQgMxrQb_NM6HKkK=
p_QbW91Vx4Y4&e=3D
>>>
>>> There are non-logical limits to the implementation, such as
>>> intermediate expression swell that uses up all of memory.
>>> It isn't possible to write a specification that can detect all of
>>> these kinds of failures before they occur. But there are logical
>>> ways to handle such boundaries.
>>>
>>> In logic there are 'product types' which are basically
>>> multi-field records. There are 'sum types' which are disjoint
>>> unions.
>>>
>>> Axiom's approach to reaching limits of computation is to
>>> return a 'sum type' that is either the result or 'failed'. The
>>> 'failed' result needs to be explicitly carried in the proof.
>>> Because 'failed' is a valid result, the specification can be
>>> expanded to include this as a valid result.
>>>
>>> Just because a program can fail there is no reason to say
>>> that it can't be proven, given that 'failed' is a valid result.
>>>
>>> One could even expand the sum types to include information
>>> about the failure so that 'failed' would be a product type that
>>> said why it failed. That allows another domain to be used.
>>> In fact, one could introduce a FAILED domain in Axiom
>>> with a 'why?' function. Local domains could extend FAILED
>>> with their own 'why?' function specific to their possible
>>> failures.
>>>
>>> Axiom has the ability to have muttiple domains that can
>>> overcome limits, e.g. small floats, large floats, unums.
>>> These would allow users to 'retry' a computation with
>>> different assumptions.
>>>
>>> The issue you raise is important. Some algorithms in
>>> Axiom have "hand-waving' specifications that need
>>> to be expanded to properly return 'failed' when that is
>>> expected. I think this is a 'good thing' and a useful
>>> by-product of combining proof and computer algebra.
>>>
>>> Am I closer to understanding your objections?
>>>
>>> Tim
>>>
>>>
>>>
>>> On 7/20/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>>> Hi Tim:
>>>>
>>>> Perhaps I did not make myself clear in the short comment.
>>>> What I wanted to say is that a data representation is not the same as
>>>> the
>>>> abstract mathematical objects because there are finite bounds on the
>>>> representation. Take for example, an algorithm to compute the LCM of t=
wo
>>>> integers. The LCM can cause overflow and not be representable. Of
>>>> course,
>>>> you can change the data representation to have "infinite precision", b=
ut
>>>> that would still be bounded by actual physical memory of the machine.
>>>> The
>>>> careful programmer of the LCM algorithm would add throws and catches t=
o
>>>> handle the "error",but the implementation will have to add code that i=
s
>>>> not
>>>> considered in the theoretical LCM algorithm (unless the LCM algorithm =
is
>>>> meant for bounded integers of a fixed data representation and not
>>>> abstract
>>>> integers). So there are two kinds of algorithms, one that is purely
>>>> mathematical and one that is computational, the latter including a
>>>> particular (class of) data representation(s) (perhaps even the compute=
r
>>>> language and system of the implementation). It is proofs for the latte=
r
>>>> type
>>>> of algorithms that is lacking. Since data representations (like REP in
>>>> Axiom) are built recursively, a computational algorithm (in the sense
>>>> above)
>>>> for Groebner basis may have to be designed to take care of just a few =
of
>>>> the
>>>> ways integers can be represented. Axiom is built with that in mind
>>>> (that's
>>>> where type theory comes in), but I bet no one SPECIFIES their
>>>> computational
>>>> algorithms with the limitations of data representation in mind, much
>>>> less
>>>> proves the algorithm anew for each new representation. So if a
>>>> computation
>>>> of a Groebner basis halts because of an intermediate LCM computation
>>>> (say
>>>> of
>>>> two integer coefficients), should we consider the implementation as
>>>> proven
>>>> correct? What if the overflow condition was not detected and the
>>>> computation
>>>> continues? Indeed, since there may be different implementations of the
>>>> integer domain, we must be sure that every implementation of the LCM
>>>> algorithm handles overflows correctly AND specified in the
>>>> documentation.
>>>>
>>>> I am sure I am just being ignorant to pose these questions, because th=
ey
>>>> must have been considered and perhaps solved. In that case, please
>>>> ignore
>>>> them and just tell me so.
>>>>
>>>> William
>>>>
>>>> William Sit
>>>> Professor Emeritus
>>>> Department of Mathematics
>>>> The City College of The City University of New York
>>>> New York, NY 10031
>>>> homepage: wsit.ccny.cuny.edu
>>>>
>>>> ________________________________________
>>>> From: Tim Daly <axiomcas@gmail.com>
>>>> Sent: Sunday, July 19, 2020 5:33 PM
>>>> To: William Sit
>>>> Cc: axiom-dev
>>>> Subject: Re: [EXTERNAL] Re: Axiom musings...
>>>>
>>>> There are several "problems" with proving programs correct that
>>>> I don't quite know how to solve, or even approach. But that's the
>>>> fun of "research", right?
>>>>
>>>> For the data representation question I've been looking at types.
>>>> I took 10 courses at CMU. I am eyebrow deep in type theory.
>>>> I'm looking at category theory and homotopy type theory. So
>>>> far I haven't seen anyone looking at the data problem. Most of
>>>> the focus is on strict code typing.
>>>>
>>>> There is an old MIT course by Abelson and Sussman "Structure
>>>> and Interpretation of Computer Programs" (SICP). They rewrite
>>>> data as programs which, in Lisp, is trivial to do, Dan Friedman
>>>> seems to have some interesting ideas too.
>>>>
>>>> All of Axiom's SANE types are now CLOS objects which gives
>>>> two benefits. First, they can be inherited. But second, they
>>>> are basically Lisp data structures with associated code.
>>>>
>>>> I'm thinking of associating "data axioms" with the representation
>>>> (REP) object of a domain as well as with the functions.
>>>>
>>>> For example, DenavitHartenbergMatrix encodes 4x4 matrices
>>>> used in graphics and robotics. They are 4x4 matrices where
>>>> the upper left 3x3 encodes rotations, the right column encodes
>>>> translations, and the lower row includes scaling, skewing, etc.
>>>>
>>>> (As an aside, DHMATRIX matrices have an associated
>>>> Jacobian which encodes the dynamics in things like robots.
>>>> Since I'm also programming a robot I'm tempted to work on
>>>> extending the domain with related functions... but, as
>>>> Hamming said, new algebra code isn't "the most important
>>>> problem in computational mathematics").
>>>>
>>>> Axioms associated with the REP can assume that they are
>>>> 4x4, that they can be inverted, that they have a "space" of
>>>> rotations, etc. The axioms provide "facts" known to be true
>>>> about the REP. (I also need to think about a "specification"
>>>> for the REP but I'm not there yet).
>>>>
>>>> Since every category and domain is a CLOS data structure
>>>> the DHMATRIX data structure inherits REP axioms from its
>>>> inheritance graph (e.g. SQMATRIX axioms). But DHMATRIX
>>>> adds domain-specific REP axioms (as well as domain-specific
>>>> function axioms). Thus a DHMATRIX rotate function can
>>>> base its proof on the fact that it only affects the upper 3x3
>>>> and lives in a space of rotations, all of which can be assumed
>>>> by the proof.
>>>>
>>>> If I use the SICP "trick" of representing data as code I can
>>>> "expand" the data as part of the program proof.
>>>>
>>>> It is all Omphaloskepsis (navel gazing) at this point though.
>>>> I'm still writing the new SANE compiler (which is wildly
>>>> different from the compiler course I taught).
>>>>
>>>> I did give a talk at Notre Dame but I haven't attempted to
>>>> publish. All of my work shows up in literate programming
>>>> Axiom books on github.
>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_dal=
y_PDFS&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DpGhsx=
wcTvR8Ap4fl9FnvlW2_HcwzcFuj51GHaBlmYIU&m=3DWOYlKYoZNDGIAC2_SbARFwrWepvVu8EQ=
IcLfvTFz2x8&s=3DVTyfp86PorJlUsYXQh-5H2rc57ovAik1_HcrqxsygWk&e=3D
>>>> )
>>>>
>>>> It is all pretty pointless since nobody cares about computer
>>>> algebra, proving math programs correct, or Axiom itself.
>>>> Wolfram is taking up all the oxygen in the discussions.
>>>>
>>>> But I have to say, this research is great fun. It reminds me
>>>> of the Scratchpad days, although I miss the give-and-take
>>>> of the group. It is hard to recreate my role as the dumbest
>>>> guy in the room when I'm stuck here by myself :-)
>>>>
>>>> Hope you and your family are safe and healthy.
>>>>
>>>> Tim
>>>>
>>>> PS. I think we should redefine the "Hamming Distance" as
>>>> the distance between an idea and its implementation.
>>>>
>>>>
>>>>
>>>> On 7/19/20, William Sit <wsit@ccny.cuny.edu> wrote:
>>>>> Hi Tim:
>>>>>
>>>>> Glad to hear from you now and then, promoting and working towards you=
r
>>>>> ideas
>>>>> and ideals.
>>>>>
>>>>>  >>We need proven algorithms.
>>>>>
>>>>> Just one short comment: it is often possible to prove algorithms (tha=
t
>>>>> is,
>>>>> providing the theoretical foundation for the algorithm), but it is mu=
ch
>>>>> harder to prove that an implementation of the algorithm is correct. A=
s
>>>>> you
>>>>> well know, the distinction lies in that implementation involves data
>>>>> representations whereas proofs of algorithms normally ignore them.
>>>>> Introducing (finite) data representations means introducing boundary
>>>>> situations that a programmer implementing an algorithm must deal with=
.
>>>>> So
>>>>> perhaps what we need to prove should include the correctness of
>>>>> implementations (to the bare metal, as you often say) and we should
>>>>> have
>>>>> a
>>>>> different set of analytic tools that can deal with the correctness (o=
r
>>>>> completeness) of data representations. Of course, these tools must al=
so
>>>>> be
>>>>> proven with the same rigor since behind every program is an algorithm=
.
>>>>>
>>>>> William
>>>>>
>>>>> William Sit
>>>>> Professor Emeritus
>>>>> Department of Mathematics
>>>>> The City College of The City University of New York
>>>>> New York, NY 10031
>>>>> homepage: wsit.ccny.cuny.edu
>>>>>
>>>>> ________________________________________
>>>>> From: Axiom-developer
>>>>> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on beh=
alf
>>>>> of
>>>>> Tim Daly <axiomcas@gmail.com>
>>>>> Sent: Saturday, July 18, 2020 6:28 PM
>>>>> To: axiom-dev; Tim Daly
>>>>> Subject: [EXTERNAL] Re: Axiom musings...
>>>>>
>>>>> Richard Hamming gave a great talk. "You and Your Research"
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.co=
m_watch-3Fv-3Da1zDuOPkMSw&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZX=
HRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXN=
ZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DkSXlFiPNCbYVZvoZ62OUVd_40kcVviTxSKF3vNNt=
m0U&e=3D
>>>>>
>>>>> His big question is:
>>>>>
>>>>> "What is the most important problem in your field
>>>>> and why aren't you working on it?"
>>>>>
>>>>> To my mind, the most important problem in the field of
>>>>> computational mathematics is grounding computer
>>>>> algebra in proofs.
>>>>>
>>>>> Computer mathematical algorithms that "maybe,
>>>>> possibly, give correct answers sometimes" is a problem.
>>>>> Indeed, for computer algebra, it is the most important
>>>>> problem. We need proven algorithms.
>>>>>
>>>>> New algorithms, better graphics, better documentation,
>>>>> are all "nice to have" but, as Hamming would say,
>>>>> they are not "the most important problem".
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>>
>>>>> On 7/2/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> Time for another update.
>>>>>>
>>>>>> The latest Intel processors, available only to data centers
>>>>>> so far, have a built-in FPGA. This allows you to design
>>>>>> your own circuits and have them loaded "on the fly",
>>>>>> running in parallel with the CPU.
>>>>>>
>>>>>> I bought a Lattice ICEstick FPGA development board. For
>>>>>> the first time there are open source tools that support it so
>>>>>> it is a great test bench for ideas and development. It is a
>>>>>> USB drive so it can be easily ported to any PC.
>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.lattices=
emi.com_products_developmentboardsandkits_icestick&d=3DDwIFaQ&c=3D4NmamNZG3=
KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvT=
ih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DQxcJcE1BdIMqDbu=
tQz2HFhAAAymG-QswIjRao_YTwz4&e=3D
>>>>>> )
>>>>>>
>>>>>> I also bought a large Intel Cyclone FPGA development board.
>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.terasic.c=
om.tw_cgi-2Dbin_page_archive.pl-3FLanguage-3DEnglish-26No-3D836&d=3DDwIFaQ&=
c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ=
79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D3w=
W6BueAeyVTQi0xGqoeE7xIA5EREDmvQR4fPw5zAXo&e=3D
>>>>>> )
>>>>>> which has 2 embedded ARM processors. Unfortunately
>>>>>> the tools (which are freely available) are not open source.
>>>>>> It has sufficient size and power to do anything.
>>>>>>
>>>>>>
>>>>>> I've got 2 threads of work in progress, both of which
>>>>>> involve FPGAs (Field Programmable Gate Arrays).
>>>>>>
>>>>>> Thread 1
>>>>>>
>>>>>> The first thread involves proving programs correct. Once
>>>>>> a proof has been made it is rather easier to check the proof.
>>>>>> If code is shipped with a proof, the proof can be loaded into
>>>>>> an FPGA running a proof-checker which verifies the program
>>>>>> in parallel with running the code on the CPU.
>>>>>>
>>>>>> I am researching the question of writing a proof checker that
>>>>>> runs on an FPGA, thus verifying the code "down to the metal".
>>>>>> The Lean proof checker is the current target.
>>>>>>
>>>>>> The idea is to make "Oracle" algorithms that, because they
>>>>>> are proven correct and verified at runtime, can be trusted
>>>>>> by other mathematical software (e.g. Lean, Coq, Agda)
>>>>>> when used in proofs.
>>>>>>
>>>>>> Thread 2
>>>>>>
>>>>>>
>>>>>> The second thread involves arithmetic. Axiom currently ships
>>>>>> with numeric routines (BLAS and LAPACK, see bookvol10.5).
>>>>>> These routines have a known set of numeric failures such as
>>>>>> cancellation, underflow, and scaling.
>>>>>>
>>>>>> John Gustafson has designed a 'unum' numeric format that can
>>>>>> eliminate many of these errors. (See
>>>>>> Gustafson, John "The End of Error" CRC Press 2015
>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.amazon.co=
m_End-2DError-2DComputing-2DChapman-2DComputational_dp_1482239868_ref-3Dsr-=
5F1-5F1-3Fdchild-3D1-26keywords-3Dgustafson-2Bthe-2Bend-2Bof-2Berror-26qid-=
3D1593685423-26sr-3D8-2D1&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZX=
HRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXN=
ZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DcxcqXTqQQjOFj6wRWKcaCMutCt0BYJ0WwJnlo0hY=
a0A&e=3D
>>>>>> )
>>>>>>
>>>>>> The research goal is to implement Axiom's floating-point
>>>>>> arithmetic that can be offloaded onto an FPGA implementing
>>>>>> the unum format. Such a system would radically simplify
>>>>>> the implementation of BLAS and LAPACK as most of the
>>>>>> errors can't occur. The impact would be similar to using
>>>>>> multi-precision integer arithmetic, only now its floating-point.
>>>>>>
>>>>>> SANE, the greater goal.
>>>>>>
>>>>>> The Axiom SANE compiler / interpreter can use both of
>>>>>> these tools to implement trusted mathematical software.
>>>>>> It's a long, ambitious research effort but even if only pieces
>>>>>> of it succeed, it changes computational mathematics.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> "A person's reach should exceed their grasp,
>>>>>> or what's a computer for?"  (misquoting Robert Browning)
>>>>>>
>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.quotetab=
.com_quote_by-2Drobert-2Dbrowning_ah-2Dbut-2Da-2Dmans-2Dreach-2Dshould-2Dex=
ceed-2Dhis-2Dgrasp-2Dor-2Dwhats-2Da-2Dheaven-2Dfor&d=3DDwIFaQ&c=3D4NmamNZG3=
KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvT=
ih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DayZkzXC9ekESctd=
x_OqsfcYl4z14qlYS02TBNmnaHUY&e=3D
>>>>>> )
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/16/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>> WHY PROVE AXIOM CORRECT (SANE)?
>>>>>>>
>>>>>>> Historically, Axiom credits CLU, the Cluster language by
>>>>>>> Barbara Liskov, with the essential ideas behind the Spad
>>>>>>> language. Barbara gave a talk (a partial transcript below)
>>>>>>> that gives the rational behind the ``where clause'' used by
>>>>>>> Spad.
>>>>>>>
>>>>>>> She talks about the limits of the compile time capablity.
>>>>>>> In particular, she says:
>>>>>>>
>>>>>>>    To go further, where we would say that T,
>>>>>>>    in addition, has to be an equality relation, that requires
>>>>>>>    much more sophisticated techniques that, even today, are
>>>>>>>    beyond the capabilities of the compiler.
>>>>>>>
>>>>>>> Showing that the ``equal'' function satisfies the equality
>>>>>>> relation is no longer ``beyond the capabilities of the compiler''.
>>>>>>> We have the required formalisms and mechanisms to
>>>>>>> prove properties at compile time.
>>>>>>>
>>>>>>> The SANE effort is essentially trying to push compile
>>>>>>> time checking into proving that, for categories that use
>>>>>>> ``equal'', we prove that the equal function implements
>>>>>>> equality.
>>>>>>>
>>>>>>> I strongly encourage you to watch her video.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>> Barbara Liskov
>>>>>>> May 2012
>>>>>>> MIT CSAIL
>>>>>>> Programming the Turing Machine
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.=
com_watch-3Fv-3DibRar7sWulM&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrk=
ZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDf=
XNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DmKaSE2deFF_wqq9yriqo-s51oF6c3-ksS2_IZh=
S1eGY&e=3D
>>>>>>>
>>>>>>> POLYMORPHISM
>>>>>>>
>>>>>>> We don't just want a set, we want polymorphism or
>>>>>>> generics, as they are called today. We wanted to
>>>>>>> have a generic set which was paramaterized by type
>>>>>>> so you could instantiate it as:
>>>>>>>
>>>>>>> Set =3D [T:type] create, insert,...
>>>>>>>   % representation for Set object
>>>>>>>   % implementation of Set operations
>>>>>>>   Set
>>>>>>>
>>>>>>> Set[int] s :=3D Set[int]$create()
>>>>>>> Set[int]$insert(s,3)
>>>>>>>
>>>>>>> We wanted a static solution to this problem. The
>>>>>>> problem is, not every type makes sense as a parameter
>>>>>>> to Set of T. For sets, per se, you need an equality
>>>>>>> relation. If it has been a sorted set we would have
>>>>>>> some ordering relation. And a type that didn't have
>>>>>>> one of those things would not have been a legitimate
>>>>>>> parameter. We needed a way of expressing that in a
>>>>>>> compile-time, checkable manner. Otherwise we would
>>>>>>> have had to resort to runtime checking.
>>>>>>>
>>>>>>> Our solution was
>>>>>>>
>>>>>>> Set =3D [T:  ] create, insert,...
>>>>>>>   T equal: (T,T) (bool)
>>>>>>>
>>>>>>>
>>>>>>> Our solution, what we call the ``where clause''. So we
>>>>>>> added this to the header. The ``where clause'' tells you
>>>>>>> what operations the parameter type has to have.
>>>>>>>
>>>>>>> If you have the ``where'' clause you can do the static
>>>>>>> checking because when you instantiate, when you provide
>>>>>>> an actual type, the compiler can check that the type has
>>>>>>> the operations that are required. And then, when you write
>>>>>>> the implementation of Set the compiler knows it's ok to
>>>>>>> call those operations because you can guarantee they are
>>>>>>> actually there when you get around to running.
>>>>>>>
>>>>>>> Of course, you notice that there's just syntax here; there's
>>>>>>> no semantics.
>>>>>>>
>>>>>>> As I'm sure you all know, compile-time type checking is
>>>>>>> basically a proof technique of a very limited sort and
>>>>>>> this was about as far as we can push what you could get out of the
>>>>>>> static analysis. To go further, where we would say that T,
>>>>>>> in addition, has to be an equality relation, that requires
>>>>>>> much more sophisticated techniques that, even today, are
>>>>>>> beyond the capabilities of the compiler.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/24/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>> I've spent entirely too much time studing the legal issues
>>>>>>>> of free and open source software. There are copyright,
>>>>>>>> trademark, and intellectual property laws. I have read
>>>>>>>> several books, listened to lectures, and read papers on
>>>>>>>> the subject. I've spoken to lawyers about it. I've even
>>>>>>>> been required, by law, to coerce people I respect.
>>>>>>>> You would think it was all perfectly clear. It isn't.
>>>>>>>>
>>>>>>>> The most entertaining and enlightening lectures were
>>>>>>>> by Robert Lefkowitz at OSCON 2004. His talk is
>>>>>>>> "The Semasiology of Open Source", which sounds
>>>>>>>> horrible but I assure you, this is a real treat.
>>>>>>>>
>>>>>>>> THE THESIS
>>>>>>>>
>>>>>>>> Semasiology, n. The science of meanings or
>>>>>>>> sense development (of words); the explanation
>>>>>>>> of the development and changes of the meanings
>>>>>>>> of words. Source: Webster's Revised Unabridged
>>>>>>>> Dictionary, =C3=AF=C2=BF=C2=BD 1996, 1998 MICRA, Inc.
>>>>>>>>
>>>>>>>> "Open source doesn't just mean access to the
>>>>>>>> source code." So begins the Open Source Definition.
>>>>>>>> What then, does access to the source code mean?
>>>>>>>> Seen through the lens of an Enterprise user, what
>>>>>>>> does open source mean? When is (or isn't) it
>>>>>>>> significant? And a catalogue of open source
>>>>>>>> related arbitrage opportunities.
>>>>>>>>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conve=
rsationsnetwork.org_Robert-2520Lefkowitz-2520-2D-2520The-2520Semasiology-25=
20of-2520Open-2520Source.mp3&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKr=
kZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOID=
fXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DIpKqNvLCWxaxdmI9ATBmNX0r3h_3giwDJVTFc=
nEbusM&e=3D
>>>>>>>>
>>>>>>>> Computer source code has words and sentence
>>>>>>>> structure like actual prose or even poetry. Writing
>>>>>>>> code for the computer is like writing an essay. It
>>>>>>>> should be written for other people to read,
>>>>>>>> understand and modify. These are some of the
>>>>>>>> thoughts behind literate programming proposed
>>>>>>>> by Donald Knuth. This is also one of the ideas
>>>>>>>> behind Open Source.
>>>>>>>>
>>>>>>>>  THE ANTITHESIS
>>>>>>>>
>>>>>>>> "Open Source" is a phrase like "Object Oriented"
>>>>>>>> - weird at first, but when it became popular, the
>>>>>>>> meaning began to depend on the context of the
>>>>>>>> speaker or listener. "Object Oriented" meant that
>>>>>>>> PERL, C++, Java, Smalltalk, Basic and the newest
>>>>>>>> version of Cobol are all "Object Oriented" - for some
>>>>>>>> specific definition of "Object Oriented". Similar is
>>>>>>>> the case of the phrase "Open Source".
>>>>>>>>
>>>>>>>> In Part I, Lefkowitz talked about the shift of the
>>>>>>>> meaning of "Open Source" away from any reference
>>>>>>>> to the actual "source code," and more towards other
>>>>>>>> phases of the software development life cycle. In
>>>>>>>> Part II, he returns to the consideration of the
>>>>>>>> relationship between "open source" and the actual
>>>>>>>> "source code," and reflects upon both the way
>>>>>>>> forward and the road behind, drawing inspiration
>>>>>>>> from Charlemagne, King Louis XIV, Donald Knuth,
>>>>>>>> and others.
>>>>>>>>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__origin.conve=
rsationsnetwork.org_ITC.OSCON05-2DRobertLefkowitz-2D2005.08.03.mp3&d=3DDwIF=
aQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7ww=
WYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=
=3DLTgLxuL_diAdUFVj96fbcZJ08IEv_MGf28Vlk0InNQI&e=3D
>>>>>>>>
>>>>>>>> THE SYNTHESIS
>>>>>>>>
>>>>>>>> In a fascinating synthesis, Robert "r0ml" Lefkowitz
>>>>>>>> polishes up his exposition on the evolving meaning
>>>>>>>> of the term 'open source'. This intellectual joy-ride
>>>>>>>> draws on some of the key ideas in artificial intelligence
>>>>>>>> to probe the role of language, meaning and context
>>>>>>>> in computing and the software development process.
>>>>>>>> Like Wittgenstein's famous thought experiment, the
>>>>>>>> open source 'beetle in a box' can represent different
>>>>>>>> things to different people, bearing interesting fruit for
>>>>>>>> philosophers and software creators alike.
>>>>>>>>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__itc.conversa=
tionsnetwork.org_audio_download_itconversations-2D1502.mp3&d=3DDwIFaQ&c=3D4=
NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdS=
WMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DJls8tho=
IwON-5Jr2Rn1_MXWtrohVFn1Ik4c7l2MFsnk&e=3D
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>> I've pushed the lastest version of Axiom. The plan, followed
>>>>>>>>> so far, is to push once a month on the 7th.
>>>>>>>>>
>>>>>>>>> After some chat room interactions it was brought home
>>>>>>>>> again that the proof world really does not seem to like the
>>>>>>>>> idea of proving programs correct. And, given that it was is
>>>>>>>>> of the main Axiom goals and a point of friction during the fork,
>>>>>>>>> the computer algebra world does not like the idea of proving
>>>>>>>>> programs correct either.
>>>>>>>>>
>>>>>>>>> So the idea of "computational mathematics", which includes
>>>>>>>>> both disciplines (as well as type theory) seems still a long
>>>>>>>>> way off.
>>>>>>>>>
>>>>>>>>> Nevertheless, the primary change in these past and future
>>>>>>>>> updates is focused on merging proof and computer algebra.
>>>>>>>>>
>>>>>>>>> Proof systems are able to split the problem of creating a
>>>>>>>>> proof and the problem of verifying a proof, which is much
>>>>>>>>> cheaper. Ideally the proof checker would run on verified
>>>>>>>>> hardware so the proof is checked "down to the metal".
>>>>>>>>>
>>>>>>>>> I have a background in Field Programmable Gate Arrays
>>>>>>>>> (FPGAs) as I tried to do a startup using them. So now I'm
>>>>>>>>> looking at creating a hardware proof checker using a
>>>>>>>>> dedicated instruction set, one designed to be verifed.
>>>>>>>>> New CPUs used in data centers (not yet available to us
>>>>>>>>> mortals) have built-in FPGAs so it would be possible to
>>>>>>>>> "side-load" a proof of a program to be checked while the
>>>>>>>>> program is run. I have the FPGA and am doing a gate-level
>>>>>>>>> special instruction design for such a proof checker.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/7/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>> As a mathematician, it is difficult to use a system like Axiom,
>>>>>>>>>> mostly because it keeps muttering about Types. If you're not
>>>>>>>>>> familiar with type theory (most mathematicians aren't) then it
>>>>>>>>>> seems pointless and painful.
>>>>>>>>>>
>>>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>>>
>>>>>>>>>> As a mathematician with an algorithmic approach, it is difficult
>>>>>>>>>> to use a system like Axiom, mostly because you have to find
>>>>>>>>>> or create "domains" or "packages", understand categories
>>>>>>>>>> with their inheritance model, and learn a new language with
>>>>>>>>>> a painful compiler always complaining about types.
>>>>>>>>>>
>>>>>>>>>> So Axiom has a steep learning curve.
>>>>>>>>>>
>>>>>>>>>> The Sane version of Axiom requires knowing the mathematics.
>>>>>>>>>> It also assumes a background in type theory, inductive logic,
>>>>>>>>>> homotopy type theory, ML (meta-language, not machine
>>>>>>>>>> learning (yet)), interactive theorem proving, kernels, tactics,
>>>>>>>>>> and tacticals. Also assumed is knowledge of specification
>>>>>>>>>> languages,
>>>>>>>>>> Hoare triples, proof techniques, soundness, and completeness.
>>>>>>>>>> Oh, and there is a whole new syntax and semantics added to
>>>>>>>>>> specify definitions, axioms, and theorems, not to mention whole
>>>>>>>>>> libraries of the same.
>>>>>>>>>>
>>>>>>>>>> So Axiom Sane has a steep learning curve.
>>>>>>>>>>
>>>>>>>>>> I've taken 10 courses at CMU and spent the last 4-5 years
>>>>>>>>>> learning to read the leading edge literature (also known
>>>>>>>>>> as "greek studies", since every paper has pages of greek).
>>>>>>>>>>
>>>>>>>>>> I'm trying to unify computer algebra and proof theory into a
>>>>>>>>>> "computational mathematics" framework. I suspect that the only
>>>>>>>>>> way this system will ever be useful is after Universities have a
>>>>>>>>>> "Computational Mathematics" major course of study and degree.
>>>>>>>>>>
>>>>>>>>>> Creating a new department is harder than creating Axiom Sane
>>>>>>>>>> because, you know, ... people.
>>>>>>>>>>
>>>>>>>>>> I think such a department is inevitable given the deep and wide
>>>>>>>>>> impact of computers, just not in my lifetime. That's ok. When I
>>>>>>>>>> started programming there was no computer science degree.
>>>>>>>>>>
>>>>>>>>>> Somebody has to be the first lemming over the cliff.
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>> When Axiom Sane is paired with a proof checker (e.g. with Lean)
>>>>>>>>>>> there is a certain amount of verification that is involved.
>>>>>>>>>>>
>>>>>>>>>>> Axiom will provide proofs (presumably validated by Lean) for it=
s
>>>>>>>>>>> algorithms. Ideally, when a computation is requested from Lean
>>>>>>>>>>> for a GCD, the result as well as a proof of the GCD algorithm i=
s
>>>>>>>>>>> returned. Lean can the verify that the proof is valid. But it i=
s
>>>>>>>>>>> computationally more efficient if Axiom and Lean use a
>>>>>>>>>>> cryptographic
>>>>>>>>>>> hash, such as SHA1. That way the proof doesn't need to be
>>>>>>>>>>> 'reproven', only a hash computation over the proof text needs t=
o
>>>>>>>>>>> be performed. Hashes are blazingly fast. This allows proofs to =
be
>>>>>>>>>>> exchanged without re-running the proof mechanism. Since a large
>>>>>>>>>>> computation request from Lean might involve many algorithms
>>>>>>>>>>> there would be considerable overhead to recompute each proof.
>>>>>>>>>>> A hash simplifies the issue yet provides proof integrity.
>>>>>>>>>>>
>>>>>>>>>>> Tim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/9/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>> Provisos.... that is, 'formula SUCH pre/post-conditions'
>>>>>>>>>>>>
>>>>>>>>>>>> A computer algebra system ought to know and ought to provide
>>>>>>>>>>>> information about the domain and range of a resulting formula.
>>>>>>>>>>>> I've been pushing this effort since the 1980s (hence the
>>>>>>>>>>>> SuchThat domain).
>>>>>>>>>>>>
>>>>>>>>>>>> It turns out that computing with, carrying, and combining this
>>>>>>>>>>>> information is difficult if not impossible in the current
>>>>>>>>>>>> system.
>>>>>>>>>>>> The information isn't available and isn't computed. In that
>>>>>>>>>>>> sense,
>>>>>>>>>>>> the original Axiom system is 'showing its age'.
>>>>>>>>>>>>
>>>>>>>>>>>> In the Sane implementation the information is available. It is
>>>>>>>>>>>> part of the specification and part of the proof steps. With a
>>>>>>>>>>>> careful design it will be possible to provide provisos for eac=
h
>>>>>>>>>>>> given result that are carried with the result for use in furth=
er
>>>>>>>>>>>> computation.
>>>>>>>>>>>>
>>>>>>>>>>>> This raises interesting questions to be explored. For example,
>>>>>>>>>>>> if the formula is defined over an interval, how is the interva=
l
>>>>>>>>>>>> arithmetic handled?
>>>>>>>>>>>>
>>>>>>>>>>>> Exciting research ahead!
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/3/20, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>> Trusted Kernel... all the way to the metal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While building a trusted computer algebra system, the
>>>>>>>>>>>>> SANE version of Axiom, I've been looking at questions of
>>>>>>>>>>>>> trust at all levels.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One of the key tenets (the de Bruijn principle) calls for a
>>>>>>>>>>>>> trusted kernel through which all other computations must
>>>>>>>>>>>>> pass. Coq, Lean, and other systems do this. They base
>>>>>>>>>>>>> their kernel  on logic like the Calculus of Construction or
>>>>>>>>>>>>> something similar.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrej Bauer has been working on a smaller kernel (a
>>>>>>>>>>>>> nucleus) that separates the trust from the logic. The rules
>>>>>>>>>>>>> for the logic can be specified as needed but checked by
>>>>>>>>>>>>> the nucleus code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've been studying Field Programmable Gate Arrays (FPGA)
>>>>>>>>>>>>> that allow you to create your own hardware in a C-like
>>>>>>>>>>>>> language (Verilog). It allows you to check the chip you build
>>>>>>>>>>>>> all the way down to the transistor states. You can create
>>>>>>>>>>>>> things as complex as a whole CPU or as simple as a trusted
>>>>>>>>>>>>> nucleus. (youtube: Building a CPU on an FPGA). ACL2 has a
>>>>>>>>>>>>> history of verifying hardware logic.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It appears that, assuming I can understand Bauers
>>>>>>>>>>>>> Andromeda system, it would be possible and not that hard
>>>>>>>>>>>>> to implement a trusted kernel on an FPGA the size and
>>>>>>>>>>>>> form factor of a USB stick.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Trust "down to the metal".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/15/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>> Progress in happening on the new Sane Axiom compiler.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Recently I've been musing about methods to insert axioms
>>>>>>>>>>>>>> into categories so they could be inherited like signatures.
>>>>>>>>>>>>>> At the moment I've been thinking about adding axioms in
>>>>>>>>>>>>>> the same way that signatures are written, adding them to
>>>>>>>>>>>>>> the appropriate categories.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But this is an interesting design question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Axiom already has a mechanism for inheriting signatures
>>>>>>>>>>>>>> from categories. That is, we can bet a plus signature from,
>>>>>>>>>>>>>> say, the Integer category.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Suppose we follow the same pattern. Currently Axiom
>>>>>>>>>>>>>> inherits certain so-called "attributes", such as
>>>>>>>>>>>>>> ApproximateAttribute,
>>>>>>>>>>>>>> which implies that the results are only approximate.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We could adapt the same mechnaism to inherit the Transitive
>>>>>>>>>>>>>> property by defining it in its own category. In fact, if we
>>>>>>>>>>>>>> follow Carette and Farmer's "tiny theories" architecture,
>>>>>>>>>>>>>> where each property has its own inheritable category,
>>>>>>>>>>>>>> we can "mix and match" the axioms at will.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An "axiom" category would also export a function. This
>>>>>>>>>>>>>> function
>>>>>>>>>>>>>> would essentially be a "tactic" used in a proof. It would
>>>>>>>>>>>>>> modify
>>>>>>>>>>>>>> the proof step by applying the function to the step.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Theorems would have the same structure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This allows theorems to be constructed at run time (since
>>>>>>>>>>>>>> Axiom supports "First Class Dynamic Types".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition, this design can be "pushed down" into the Spad
>>>>>>>>>>>>>> language so that Spad statements (e.g. assignment) had
>>>>>>>>>>>>>> proof-related properties. A range such as [1..10] would
>>>>>>>>>>>>>> provide explicit bounds in a proof "by language definition".
>>>>>>>>>>>>>> Defining the logical properties of language statements in
>>>>>>>>>>>>>> this way would make it easier to construct proofs since the
>>>>>>>>>>>>>> invariants would be partially constructed already.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This design merges the computer algebra inheritance
>>>>>>>>>>>>>> structure with the proof of algorithms structure, all under
>>>>>>>>>>>>>> the same mechanism.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12/11/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>> I've been reading Stephen Kell's (Univ of Kent
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.=
cs.kent.ac.uk_people_staff_srk21_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1=
tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6r=
yqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D0SL3F3KHh9R1lV_IrJ0LmINrn_DSMjMq=
5xsNk1_eii0&e=3D
>>>>>>>>>>>>>>> ) on
>>>>>>>>>>>>>>> Seven deadly sins of talking about "types"
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.=
cs.kent.ac.uk_people_staff_srk21__blog_2014_10_07_&d=3DDwIFaQ&c=3D4NmamNZG3=
KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvT=
ih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DGOMXhymTlK2T6dt=
62fTbqv-K98dBQv0oMmB82kE8mXo&e=3D
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> He raised an interesting idea toward the end of the essay
>>>>>>>>>>>>>>> that type-checking could be done outside the compiler.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can see a way to do this in Axiom's Sane compiler.
>>>>>>>>>>>>>>> It would be possible to run a program over the source code
>>>>>>>>>>>>>>> to collect the information and write a stand-alone type
>>>>>>>>>>>>>>> checker. This "unbundles" type checking and compiling.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Taken further I can think of several other kinds of checker=
s
>>>>>>>>>>>>>>> (aka 'linters') that could be unbundled.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is certainly something to explore.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/8/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>> The Axiom Sane compiler is being "shaped by the hammer
>>>>>>>>>>>>>>>> blows of reality", to coin a phrase.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There are many goals. One of the primary goals is creating=
 a
>>>>>>>>>>>>>>>> compiler that can be understood, maintained, and modified.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So the latest changes involved adding multiple index files=
.
>>>>>>>>>>>>>>>> These are documentation (links to where terms are mentione=
d
>>>>>>>>>>>>>>>> in the text), code (links to the implementation of things)=
,
>>>>>>>>>>>>>>>> error (links to where errors are defined), signatures (lin=
ks
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> the signatures of lisp functions), figures (links to
>>>>>>>>>>>>>>>> figures),
>>>>>>>>>>>>>>>> and separate category, domain, and package indexes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The tikz package is now used to create "railroad diagrams"
>>>>>>>>>>>>>>>> of syntax (ala, the PASCAL report). The implementation of
>>>>>>>>>>>>>>>> those diagrams follows immediately. Collectively these wil=
l
>>>>>>>>>>>>>>>> eventually define at least the syntax of the language. In
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> ideal, changing the diagram would change the code but I'm
>>>>>>>>>>>>>>>> not that clever.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Reality shows up with the curent constraint that the
>>>>>>>>>>>>>>>> compiler should accept the current Spad language as
>>>>>>>>>>>>>>>> closely as possible. Of course, plans are to include new
>>>>>>>>>>>>>>>> constructs (e.g. hypothesis, axiom, specification, etc)
>>>>>>>>>>>>>>>> but these are being postponed until "syntax complete".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All parse information is stored in a parse object, which
>>>>>>>>>>>>>>>> is a CLOS object (and therefore a Common Lisp type)
>>>>>>>>>>>>>>>> Fields within the parse object, e.g. variables are also
>>>>>>>>>>>>>>>> CLOS objects (and therefore a Common Lisp type).
>>>>>>>>>>>>>>>> It's types all the way down.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These types are being used as 'signatures' for the
>>>>>>>>>>>>>>>> lisp functions. The goal is to be able to type-check the
>>>>>>>>>>>>>>>> compiler implementation as well as the Sane language.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The parser is designed to "wrap around" so that the
>>>>>>>>>>>>>>>> user-level output of a parse should be the user-level
>>>>>>>>>>>>>>>> input (albeit in a 'canonical" form). This "mirror effect"
>>>>>>>>>>>>>>>> should make it easy to see that the parser properly
>>>>>>>>>>>>>>>> parsed the user input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The parser is "first class" so it will be available at
>>>>>>>>>>>>>>>> runtime as a domain allowing Spad code to construct
>>>>>>>>>>>>>>>> Spad code.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One plan, not near implementation, is to "unify" some
>>>>>>>>>>>>>>>> CLOS types with the Axiom types (e.g. String). How
>>>>>>>>>>>>>>>> this will happen is still in the land of design. This woul=
d
>>>>>>>>>>>>>>>> "ground" Spad in lisp, making them co-equal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Making lisp "co-equal" is a feature, especially as Spad is
>>>>>>>>>>>>>>>> really just a domain-specific language in lisp. Lisp
>>>>>>>>>>>>>>>> functions (with CLOS types as signatures) would be
>>>>>>>>>>>>>>>> avaiable for implementing Spad functions. This not
>>>>>>>>>>>>>>>> only improves the efficiency, it would make the
>>>>>>>>>>>>>>>> BLAS/LAPACK (see volume 10.5) code "native" to Axiom.
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> On the theory front I plan to attend the Formal Methods
>>>>>>>>>>>>>>>> in Mathematics / Lean Together conference, mostly to
>>>>>>>>>>>>>>>> know how little I know, especially that I need to know.
>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.=
andrew.cmu.edu_user_avigad_meetings_fomm2020_&d=3DDwIFaQ&c=3D4NmamNZG3KTnUC=
oC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bk=
xc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DgiWJNgv9oeh8Aj_giZkH=
Cx-3GFVk62hxr53YKr4naRk&e=3D
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/28/19, Jacques Carette <carette@mcmaster.ca> wrote:
>>>>>>>>>>>>>>>>> The underlying technology to use for building such an
>>>>>>>>>>>>>>>>> algebra
>>>>>>>>>>>>>>>>> library
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> documented in the paper " Building on the Diamonds betwee=
n
>>>>>>>>>>>>>>>>> Theories:
>>>>>>>>>>>>>>>>> Theory Presentation Combinators"
>>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www=
.cas.mcmaster.ca_-7Ecarette_publications_tpcj.pdf&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3D5QO0O72zl3hFmW3r=
yVeFoBjl0AZs2cuQZhKuIxk8NUw&e=3D
>>>>>>>>>>>>>>>>> [which
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> also be on the arxiv by Monday, and has been submitted to=
 a
>>>>>>>>>>>>>>>>> journal].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is a rather full-fledged prototype, very well
>>>>>>>>>>>>>>>>> documented
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__al=
hassy.github.io_next-2D700-2Dmodule-2Dsystems_prototype_package-2Dformer.ht=
ml&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo=
6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq=
8bDzgkQ&s=3D9fnfoSWyT66oQoIb4gKAYpCE7JjANqxHquwJdRdo2Uk&e=3D
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (source at
>>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gi=
thub.com_alhassy_next-2D700-2Dmodule-2Dsystems&d=3DDwIFaQ&c=3D4NmamNZG3KTnU=
CoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0B=
kxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DZ-d1Pn1slXyiP2l23mZ=
BB5fBQOj0-Q48CUKRS1VNLao&e=3D
>>>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> literate source.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The old prototype was hard to find - it is now at
>>>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gi=
thub.com_JacquesCarette_MathScheme&d=3DDwIFaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV=
1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3D_2V6=
ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DpkDi0LOAAPefRjcwvjwNNI3BVzNgJDI=
TFQRpkFBgg8c&e=3D
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is also a third prototype in the MMT system, but it
>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>> function properly today, it is under repair.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The paper "A Language Feature to Unbundle Data at Will"
>>>>>>>>>>>>>>>>> (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__a=
lhassy.github.io_next-2D700-2Dmodule-2Dsystems_papers_gpce19-5Fa-5Flanguage=
-5Ffeature-5Fto-5Funbundle-5Fdata-5Fat-5Fwill.pdf&d=3DDwIFaQ&c=3D4NmamNZG3K=
TnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTi=
h0Bkxc&m=3D_2V6ryqOIDfXNZePX0kmp-2428hMSBYbz5fq8bDzgkQ&s=3DRui27trbws4VTZL5=
B0zits8pEczWsib7Q7_mxyRIxhk&e=3D
>>>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is also relevant, as it solves a problem with parametrize=
d
>>>>>>>>>>>>>>>>> theories
>>>>>>>>>>>>>>>>> (parametrized Categories in Axiom terminology) that all
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> systems
>>>>>>>>>>>>>>>>> suffer from.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2019-11-27 11:47 p.m., Tim Daly wrote:
>>>>>>>>>>>>>>>>>> The new Sane compiler is also being tested with the Fric=
as
>>>>>>>>>>>>>>>>>> algebra code. The compiler knows about the language but
>>>>>>>>>>>>>>>>>> does not depend on the algebra library (so far). It shou=
ld
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> possible, by design, to load different algebra towers.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In particular, one idea is to support the "tiny theories=
"
>>>>>>>>>>>>>>>>>> algebra from Carette and Farmer. This would allow much
>>>>>>>>>>>>>>>>>> finer grain separation of algebra and axioms.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This "flexible algebra" design would allow things like t=
he
>>>>>>>>>>>>>>>>>> Lean theorem prover effort in a more natural style.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> The current design and code base (in bookvol15) support=
s
>>>>>>>>>>>>>>>>>>> multiple back ends. One will clearly be a common lisp.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Another possible design choice is to target the GNU
>>>>>>>>>>>>>>>>>>> GCC intermediate representation, making Axiom "just
>>>>>>>>>>>>>>>>>>> another front-end language" supported by GCC.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The current intermediate representation does not (yet)
>>>>>>>>>>>>>>>>>>> make any decision about the runtime implementation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/26/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> Jason Gross and Adam Chlipala ("Parsing Parses")
>>>>>>>>>>>>>>>>>>>> developed
>>>>>>>>>>>>>>>>>>>> a dependently typed general parser for context free
>>>>>>>>>>>>>>>>>>>> grammar
>>>>>>>>>>>>>>>>>>>> in Coq.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> They used the parser to prove its own completeness.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unfortunately Spad is not a context-free grammar.
>>>>>>>>>>>>>>>>>>>> But it is an intersting thought exercise to consider
>>>>>>>>>>>>>>>>>>>> an "Axiom on Coq" implementation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tim

\start
Date: Thu, 30 Jul 2020 08:24:41 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Francois Charton <fcharton@fb.com>, Guillaume Lample <glample@fb.com>,
 Tim Daly <axiomcas@gmail.com>, axiom-dev <axiom-developer@nongnu.org>
Subject: Deep Learning for Symbolic Mathematics

I'm Tim Daly, lead developer on Axiom, a computer algebra
system developed by IBM, which is now open source.

http://axiom-developer.org

https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system)

http://daly.axiom-developer.org


I read your paper and watched your video with great interest.
It is excellent work. I have a few comments and a request.

A) In the short term (the last month)...

I'm using a tree-generator written in Axiom's SPAD language
and have been using it to generate test data.

Some of the integrals match the original equation. Some of
the integrals differ by a constant. Some of the integrals
require heavy simplification machinery (complex normalization)
to show equivalence.

Some of the results fail. One of the problems is that Axiom
and Mathematica share one definition of trig formulas,
Maple and Maxima use a different definition. That will
affect simplification. Simplification of roots is also a problem
as well as field extensions.

A second effect is to find bugs in Axiom, which is quite useful.

B) In the longer term...

I expect to spend several months on your data.

I intend to try to get your system running from the github
archive so I can do more extensive test sets.

I intend to automate testing against your test suite.

C) You mention in the paper that you would be interested
in data which you did not generate. Axiom has a computer
algebra test suite (CATS) at
http://axiom-developer.org/axiom-website/CATS/index.html

There you will find the integrals from Schaum's book,
ordinary differential equations from Kamke's book,
The Charlwood test suite, and Albert Rich's integration
test suite. The sources are provided on that page and
are free for you to use.

D) Axiom has extensive documentation and we are trying
to incorporate historically interesting documents along with
Axiom-related information. Axiom uses literate programming
so the actual code is embedded in (and extracted from) the
Latex documents.

E) It would be interesting to apply your approach to the
simplification problem. Simplification is very hard, and not
well defined.

For example, your final slide shows 10 different
ODE solutions. Can these be simplified to 0, taking pairwise
differences of the results? If not, why not, since they should
be mathematically equivalent.

You could do a beam search that generated multiple
correct solutions and use that to train a "simplifier",
which would be of great interest.

I would like your permission to quote your paper, with proper
acknowledgements, as part of the current test suite effort.

Many thanks,
Tim Daly
http://daly.axiom-developer.org


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