\start
Date: Thu, 1 Sep 2016 08:25:03 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Richard Fateman <fateman@berkeley.edu>
Subject: Re: [Axiom-developer] Design of Semantic Latex
Cc: Tim Daly <daly@axiom-developer.org>, axiom-dev <axiom-developer@nongnu.org>,
	Ralf Hemmecke <ralf@hemmecke.org>,
	James Davenport <J.H.Davenport@bath.ac.uk>, 
	Mike Dewar <miked@nag.co.uk>, vdhoeven@lix.polytechnique.fr, 
	D Zwillinger <zwilling@az-tec.com>, albert_rich@msn.com
\begin{verbatim}
The weaver program can now process a latex document.
The end result is a tree structure of the same document.
There is still more to do, of course. Much more.

It is clear that the semantics of the markup tags are all in
the weaver program. This is obvious in hindsight since the
markup needs to be transparent to the print representation.

The parser needs to know the 'arity' of tags since \tag{a}{b}
would parse one way, \tag{a}, for a 1-arity tag and another
way \tag{a}{b} for a 2-arity tag. The code needs to be generalized
to parse given the arity.

The weaver program is structured so that the tree-parse output
is independent of Axiom. The Axiom rewrite will take the tree
as input and produce valid Axiom inputforms. This should make
it possible to target any CAS.

Onward and upward, as they say....

Tim


On Sat, Aug 27, 2016 at 1:28 PM, Tim Daly <axiomcas@gmail.com> wrote:

>
>
> On Sat, Aug 27, 2016 at 12:14 PM, Richard Fateman <fateman@berkeley.edu>
> wrote:
>
>>
>> Take up a book on complex analysis and see what problems you have
>>  as you try to encode the statements, or especially the homework
>> problems. I tried this decades ago with the text I used,
>> https://www.amazon.com/Functions-Complex-Variable-Technique-
>> Mathematics/dp/0898715954
>> but probably any other text would do.
>>
>
> My last project at CMU (Tires) involved work on machine learning
> using natural language (and Good-Old-Fashioned-AI (GOFAI)).
> I'm not smart enough to make progress in natural language.
>
>
>
>>
>> I think the emphasis on handbook or reference book representation
>> is natural, and I have certainly pursued this direction myself.  However
>> what you/we want to be able to encode is mathematical discourse. This
>> goes beyond "has the algorithm reproduced the reference value for an
>> integration."   Can you encode in semantic latex a description of the
>> geometry
>> of the (perhaps infinitely layered) contour of a complex function?  You
>> might wonder if this is important, but then note that questions of this
>> sort
>> appear in the problem section for chapter 1.
>>
>
> Like any research project, there has to be bounds on the ambition.
>
> At this point, the goal is to modify the markup to disambiguate a latex
> formula so the machine can import it. Axiom needs to import it to create
> a test suite measuring progress against existing knowledge.
>
> What you're describing seems to be a way to encode topological issues
> dealing with the structure of the space underlying the formulas. I have no
> idea how to encode the Bloch sphere or a torus or any other space except
> by referencing an Axiom domain, which implicitly encodes it.
>
> If the formula deals with quantum mechanics then the algorithms have an
> implicit, mechanistic way of dealing with the Bloch sphere. So markup that
> uses these function calls use this implicit grounding. Simllarly, markup
> that
> uses a branch cut implicitly uses the implementation semantics.
>
> Axiom and Mathematics have one set of branch cuts, Maple and Maxima
> have another (at far as I can tell). So the markup decisions have to be
> carefully chosen.
>
>
>>
>> Here's the challenge then.  Take a mathematics book and "encode"
>>  it so that a program (hypothetically) could answer the problems at
>> the end of each chapter.
>>
>
> That's a much deeper can of worms than it appears. I spent a lot of
> time in the question-answering literature. I have no idea how to make
> progress in that area. The Tires project involved self-modifying lisp
> based on natural language interaction with a human in the limited
> domain of changing a car tire. See
> http://daly.axiom-developer.org/cmu/book.pdf
> (The grant ended before the projected ended. Sigh)
>
> Tim
>
> P.S. Tires is self-modifying lisp code. It "learns" by changing itself.
> The initial code (the seed code) becomes "something else". One
> interesting insight is that two versions of the seed code will diverge
> based on "experience". That implies that you can't "teach by copy",
> that is, you can't teach one system and then "just copy" it to another
> existing system since their experiences (and the code structure)
> will differ. Any system that "learns" will fail "teach by copy", I believe.
> That means that AI will not have the exponential growth that everyone
> seems to believe.
>
>
>


\start
Date: Thu, 8 Sep 2016 04:59:06 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Twenty Pieces of Advice for a Young (and also not
 so young) Mathematician

Twenty Pieces of Advice for a Young (and also not so young) Mathematician
http://www.math.rutgers.edu/~zeilberg/Opinion92.html

by Doron Zeilberger

\start
Date: Thu, 8 Sep 2016 05:10:00 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	jenksprize@sigsam.org, kaltofen@math.ncsu.edu
Subject: [Axiom-developer] Buchberger Jenks Award?

But the MOST significant contribution by 20th-Century human mathematicians
and computer scientists was the creation of COMPUTER ALGEBRA. It is still
in a very preliminary stage, but is already revolutionizing the way we DO
and THINK about mathematics. Even computer foes often `cheat' and use Maple
or Mathematica on the side. It is a scandal that, so far, the pioneers of
computer algebra did not get their due recognition by the mathematical
establishment. One glaring oversight, reminiscent of G=C3=B6del only becomi=
ng a
professor at the age of 47, is that Bruno BUCHBERGER, the great pioneer of
computer algebra, whose algorithm revolutionized all the spectrum of
mathematics, from robotics to very abstract algebraic geometry, does not
get a tiny fraction of the recognition granted to the Atiyahs and the
Botts. He is not even a member of the Academy of Science of his native
Austria! But one should not fault this or that specific Academy. After all,
at least today, national academies consist of members of that
narrow-minded, short-sighted species called humans. Bruno Buchberger's
heritage, and his Gr=C3=B6bner Bases will survive long after most of the cu=
rrent
members of the Austrian Academy of Science will be forgotten.

-- quote from Doron Zeilberger (
http://www.math.rutgers.edu/~zeilberg/Opinion47.html)

Tim


\start
Date: Thu, 8 Sep 2016 05:19:38 -0400 (EDT)
From: Ilias Kotsireas <ikotsire@wlu.ca>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] Buchberger Jenks Award?
cc: axiom-dev <axiom-developer@nongnu.org>,
	Tim Daly <daly@axiom-developer.org>, jenksprize@sigsam.org,
	kaltofen@math.ncsu.edu

thank you for this inspirational quote from Doron, Tim.

note that SIGSAM has managed to honor Bruno with the prestigious
Paris Kanellakis Award in 2007
http://www.sigsam.org/Awards/KanellakisAward.html
I personally spend a lot of time working on his nomination,
with Mark Giesbrecht, Emil Volcheck and others. In the end,
we were delighted to be successful.

see here: http://www.sigsam.org/awards/jenks/
for the procedures governing the Jenks Award.

all the best,

 	Ilias

On Thu, 8 Sep 2016, Tim Daly wrote:

> But the MOST significant contribution by 20th-Century human 
> mathematicians and computer scientists was the creation of COMPUTER 
> ALGEBRA. It is still in a very preliminary stage, but is already 
> revolutionizing the way we DO and THINK about mathematics. Even computer 
> foes often `cheat' and use Maple or Mathematica on the side. It is a 
> scandal that, so far, the pioneers of computer algebra did not get their 
> due recognition by the mathematical establishment. One glaring 
> oversight, reminiscent of G?del only becoming a professor at the age of 
> 47, is that Bruno BUCHBERGER, the great pioneer of computer algebra, 
> whose algorithm revolutionized all the spectrum of mathematics, from 
> robotics to very abstract algebraic geometry, does not get a tiny 
> fraction of the recognition granted to the Atiyahs and the Botts. He is 
> not even a member of the Academy of Science of his native Austria! But 
> one should not fault this or that specific Academy. After all, at least 
> today, national academies consist of members of that narrow-minded, 
> short-sighted species called humans. Bruno Buchberger's heritage, and 
> his Gr?bner Bases will survive long after most of the current members of 
> the Austrian Academy of Science will be forgotten.
> 
> -- quote from Doron Zeilberger (http://www.math.rutgers.edu/~zeilberg/Opinion47.html)
> 
> Tim

\start
Date: Sun, 18 Sep 2016 23:21:27 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Proving Axiom correct, derivations, and CAD

Axiom now has the necessary machinery to process proofs
at build time (ACL2 for Lisp, COQ for Spad). While pondering
the subject I ended up reading "The Semantics of Destructive
Lisp"[0]. There is an interesting quote from Scherlis and Scott[1]
which leads me to think there is a crossover from Collin's work
on Cylindrical Algebraic Decomposition.[2]

The first thought involves the difference between a verification
proof and a derivation proof. Verification involves proving an
algorithm that already exists. Derivation involves transformations
from an initial set to a final result. Both proofs work but [2] says

  "The traditional correctness proof -- that a program is consistent
  with its specifications -- does not constitute a derivation of the
  program. Conventional proofs, as currently presented in the
  literature, do little to justify the structure of the program being
  proved, and they do even less to aid in the development of new
  programs that may be similar to the program that was proved. That
  is, they neither explicate existing programs nor aid in their
  modification and adaptation.

  We intend that program derivations serve as conceptual or idealized
  histories of the development of programs. That is, a program derivation
  can be considered an idealized record of the sequence of design
  decisions that led to a particular realization of a specification.

  Stripped down to essentials, our claim is that the programs of the
  future will in fact be descriptions of program derivations. Documentation
  methods based on stepwise-refinement methodologies are already
  strong evidence that there is movement toward this approach. These
  documentation methods also provide support for the hypothesis that
  program derivations offer a more intuitive and revealing way to explain
  programs than do conventional proofs of correctness. The proofs may
  succeed in convincing the reader of the correctness of the algorithm
  without giving him any hint of why the algorithm works or how it came
  about. On the other hand, a derivation may be thought of as an
  especially well-structured constructive proof of correctness of the
  algorithm, taking the reader step by step from an inital abstract
  algorithm he accepts as meeting the specifications of the problem to
  a highly connected and efficient implementation of it."

For mathematical algorithms, Mason [0] points out that it is possible to
mechanically specialize an algorithm for a given case, often with an
order of magnitude of efficiency. This is very appealing, especially in
numeric domains where it can be proven that things cannot overflow.

Collins works in semialgebraic sets, basically polynomials with a few
comparison limits and parameters. CAD could be "bent" to use it as
a compile step so that a CAD result would generate a program. Not
only would this give a complete specification, it would provide a solid
theoretical basis for the code. Can this be extended to derive other
algorithms?

Matrices can be viewed as polynomials. Can numeric algorithms
be derived from the specification (e.g. LAPACK programs) that
guarantee behavior?

Much more reading to do...

Tim

[0] Mason, Ian A. "The Semantics of Destructive Lisp"
CSLI Lecture Notes Number 5, ISBN 0-937073-06-7 (1986)

[1] Scherlis, W. L. and Scott, D. S. "First Steps Towards
Inferential Programming" in R. E. A. Mason (Ed.)
Information Processing 83 New York, North Holland

[2] Collins, George E. "Quantifier elimination for the elementary
theory of real closed fields" Lecture Notes in Computer Science
33:134-183 (1975)

\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}



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