\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Tue, 3 Mar 2015 00:40:40 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Raising the bar (again)

David Mimno gave an interesting talk about using visualization
to make algorithms and models easier to learn. He points out that
we need three things, the math, the code, and the visualization.
https://www.youtube.com/watch?v=-0Pe30Zz3a0&feature=youtu.be

So far there has been almost no work on visualization in literate
programs. The time has come to change that. We have algorithms in
Axiom that could lend themselves to visualization and those
visualizations can be embedded in the literate document.

Given that the goal of literate programming is communicating the ideas
that the code represents to a new generation it seems that visualization 
is important. I am going to try to construct a prototypical example.

So, yet a "higher bar" for excellent documentation.

Tim

\start
Date: Thu, 5 Mar 2015 16:11:19 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Raising the bar (again)

Given that a major goal is communication with the future computational
mathematician we need to spend some head-cycles trying to find better
ways to communicate. This talk goes to the fundamentals. 

 "A lot of the power of an idea lies in the form in which it is expressed"

It is vital that we make the strong connection between group theory
and Spad completely transparent. People need to have a presentation
that makes it easy to move between group theory and Spad.

Bret Victor: The Humane Representation of Thought
https://vimeo.com/115154289

\start
Date: Fri, 06 Mar 2015 08:27:05 +0000
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Raising the bar (again)

> It is vital that we make the strong connection between group theory
> and Spad completely transparent. People need to have a presentation
> that makes it easy to move between group theory and Spad.

There is a book, which I like, called 'Visual Group Theory' [Nathen 
Carter, 2009]. This looks at the various ways to start learning about 
group theory: Cayley diagrams, multiplication tables and so on and a 
very graphical way. I think that this combination of looking at a 
subject from multiple viewpoints and in a visual way is very powerful. 
This would be even more powerful if both of these things could be done 
in an interactive way using Axiom.

Unfortunately the nature of Axiom seems to be against these things. 
First Axiom only defines groups in one way, as permutations, this makes 
sense if we want to make our definition as scalable as possible but it 
does mean that Axiom is not a tool for learning about mathematics.

Secondly, although Axiom has some graphics, it is clunky and does not 
produce the sort of graphics shown in the book above. It seems to me, 
that for discrete mathematics, a command line interface is very 
unhelpful. What is needed is an interactive graphical interface.

I realise that what you are interested in is teaching people about 
Axiom, not teaching people about mathematics (using Axiom). However 
perhaps there is some link between these. Personally I might question if 
concentrating on teaching mathematics using Axiom rather than just 
teaching Axiom might be a more successful approach?

Martin

\start
Date: Fri, 6 Mar 2015 05:32:15 -0600
From: daly@axiom-developer.org
To: Martin Baker <ax87438@martinb.com>
Subject: [Axiom-developer] (no subject)

>> It is vital that we make the strong connection between group theory
>> and Spad completely transparent. People need to have a presentation
>> that makes it easy to move between group theory and Spad.
>
>There is a book, which I like, called 'Visual Group Theory' [Nathen 
>Carter, 2009]. This looks at the various ways to start learning about 
>group theory: Cayley diagrams, multiplication tables and so on and a 
>very graphical way. I think that this combination of looking at a 
>subject from multiple viewpoints and in a visual way is very powerful. 
>This would be even more powerful if both of these things could be done 
>in an interactive way using Axiom.

I ordered a copy of the book.

Have you seen "Visual Complex Analysis" by Tristan Needham?




>Unfortunately the nature of Axiom seems to be against these things. 
>First Axiom only defines groups in one way, as permutations, this makes 
>sense if we want to make our definition as scalable as possible but it 
>does mean that Axiom is not a tool for learning about mathematics.

>Secondly, although Axiom has some graphics, it is clunky and does not 
>produce the sort of graphics shown in the book above. It seems to me, 
>that for discrete mathematics, a command line interface is very 
>unhelpful. What is needed is an interactive graphical interface.

I am working on a new browser-based version of the system
(see bookvol11: Axiom Browser). The long term plan is to merge
hyperdoc and graphics (using Canvas) into a single front-end.

At the moment, the notebook portion works (type an expression,
see the evaluated results) and a portion of the hyperdoc page
set has been converted. I'm searching for technologies that will
make the new interface interesting. WebSockets is one and I am
trying to learn it.

There is a technology called d3.js that looks especially interesting:
https://github.com/mbostock/d3/wiki/Gallery
and I have spent a little time looking at it. It is data driven
so Axiom can feed it data just like it does for the current graphics.
A websocket connection would allow two-way interaction with Axiom.




>I realise that what you are interested in is teaching people about 
>Axiom, not teaching people about mathematics (using Axiom). However 
>perhaps there is some link between these. Personally I might question if 
>concentrating on teaching mathematics using Axiom rather than just 
>teaching Axiom might be a more successful approach?

As for "teaching people about mathematics", I have worked with world
class mathematicians and I'm clearly not even 3rd string on that team.

I'm interested in the next generation of computational mathematicians. 

It seems to me we're at the birth of this area and that it will 
continue to grow. Unfortunately the new computational mathematicians
have a long, difficult, and steep hill to climb. My generation developed
research-level computational mathematics but did not explain how they
reduced these ideas to code. The usual response is to try to develop
yet-another-system from scratch. I have a collection of over 100
attempts. What a waste of time and talent.

When looking at Spad algorithms it does not matter if you are able
to understand the mathematics and are able to program. If you don't
know the "trick" of the algorithm (e.g. bob's magic identity) then
the code is unreadable. 

My goal is to make it possible to communicate the ideas. My ideal
goal is to communicate the ideas so clearly that there is an
isomorphism between the presentation and the code. I want to be
able to look at the presentation and be able to clearly see where
the code must be wrong, weak, or lacking. This goes WAY beyond
commenting the code. Better yet would be the ability to develop
the presentation and have the code be written automatically.

I am currently doing Field Programmable Gate Array (FPGA) development.
The tools allow me to develop a circuit diagram and they compile it
into code (VHDL). Why can't we do this in Axiom?

If the next generation cannot understand the code then Axiom will die.
Why write code that will die? 

Tim

\start
Date: Fri, 06 Mar 2015 09:13:56 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] (no subject)

On 03/06/2015 06:32 AM, daly@axiom-developer.org wrote:
> There is a technology called d3.js that looks especially interesting: 
> https://github.com/mbostock/d3/wiki/Gallery and I have spent a little 
> time looking at it. It is data driven so Axiom can feed it data just 
> like it does for the current graphics. A websocket connection would 
> allow two-way interaction with Axiom. 
Leaving aside technicalities I think that
http://www.math.wm.edu/~leemis/chart/UDR/UDR.html
is an illustration of an effective way to organize some mathematical 
structures/relationships.  So far as I can see there is no reason calls 
(or code) couldn't be automatically generated from an illustration like 
this.  The background explanations (obtained by clicking) could be 
expanded or linked to code.  IMHO it's not complete but an excellent 
start for people trying to model statistical data.  For instance draging 
and dropping particular distributions into an "analyser" for 
comparisons, etc..., is a logical extension.
Of course the missing ingredient is an abstraction direction allowing 
focusing on particular properties; say different ranges, data types, and 
so forth.  But those ideas are rendered obvious once the "style" is visible.

Ray

-- 
  Two views on life:
life is an art not to be learned by observation.
George Santayana:Interpretations of Poetry and Religion
It's kinda nice to participate in your life
Raymond Rogers

\start
Date: Fri, 06 Mar 2015 17:55:05 +0000
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Raising the bar (again)

On 06/03/15 11:32, daly@axiom-developer.org wrote:
> Have you seen "Visual Complex Analysis" by Tristan Needham?

Yes, I agree that there are a lot of examples in there which show how 
visualisation helps people get a better understanding of the 
mathematics. Also I think this type of mathematics may be better suited 
to Axiom than discreet algebras such as finite groups.

I still think this is more useful to end users of Axiom than developers 
(it gives an intuitive understanding of the mathematics not the code), I 
think this is a good thing as end users may turn into developers but I'm 
not sure its part of the documentation. I suppose you could link 
graphics to small chunks of code as in David Mimno talk but not sure how 
that would explain the code?

> There is a technology called d3.js that looks especially interesting:
> https://github.com/mbostock/d3/wiki/Gallery
> and I have spent a little time looking at it. It is data driven
> so Axiom can feed it data just like it does for the current graphics.
> A websocket connection would allow two-way interaction with Axiom.

Yes, these new javascript graphics libraries look interesting but things 
are changing fast and I've not had a chance to really try them. A few 
years ago, before the javascript stuff took off, I tried writing an 
alternative graphics library in SPAD (in FriCAS) but SPAD seems limited 
for writing interfaces. However I do think it needs a tight coupling 
between the maths and the graphics and the ideal would be if it were all 
written in the same language.

For example, in the Needham book, say the user wanted to experiment with 
hyperbolic space. They might want to change the mathematical parameters, 
apply transforms, set boundaries, overlay a grid to see how it gets 
distorted, view it from different angles, change the colour or 
appearance. All these things interactively. Do you think a websocket 
connection will allow this and will it require special javascript to be 
written for each domain, or could the code that is specific to say 
hyperbolic space be written in SPAD and exported to js which then does 
all the interactive stuff?

> If the next generation cannot understand the code then Axiom will die.
> Why write code that will die?

I'm not disputing that, but I would like something like this to help 
people (including myself) understand the mathematics.

Martin

\start
Date: Fri,  6 Mar 2015 15:39:48 -0500 (EST)
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: [Axiom-developer] UDR diagram

I must say that I'm impressed with this.

>> There is a technology called d3.js that looks especially interesting: 
>> https://github.com/mbostock/d3/wiki/Gallery and I have spent a little 
>> time looking at it. It is data driven so Axiom can feed it data just 
>> like it does for the current graphics. A websocket connection would 
>> allow two-way interaction with Axiom. 
>Leaving aside technicalities I think that
>http://www.math.wm.edu/~leemis/chart/UDR/UDR.html
>is an illustration of an effective way to organize some mathematical 
>structures/relationships.  So far as I can see there is no reason calls 
>(or code) couldn't be automatically generated from an illustration like 
>this.  The background explanations (obtained by clicking) could be 
>expanded or linked to code.  IMHO it's not complete but an excellent 
>start for people trying to model statistical data.  For instance draging 
>and dropping particular distributions into an "analyser" for 
>comparisons, etc..., is a logical extension.
>Of course the missing ingredient is an abstraction direction allowing 
>focusing on particular properties; say different ranges, data types, and 
>so forth.  But those ideas are rendered obvious once the "style" is visible.

I'd like to develop a similar diagram for Axiom categories listing all of
the axioms that underpin each category. The links would go to the section
of the book for that category. I already have an SVG graph of the categories,
domains, and packages on the Axiom website.

Tim

\start
Date: Fri, 06 Mar 2015 16:30:43 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] UDR diagram

On 03/06/2015 03:39 PM, daly@axiom-developer.org wrote:
> I must say that I'm impressed with this.
>
>>> There is a technology called d3.js that looks especially interesting:
>>> https://github.com/mbostock/d3/wiki/Gallery and I have spent a little
>>> time looking at it. It is data driven so Axiom can feed it data just
>>> like it does for the current graphics. A websocket connection would
>>> allow two-way interaction with Axiom.
>> Leaving aside technicalities I think that
>> http://www.math.wm.edu/~leemis/chart/UDR/UDR.html
>> is an illustration of an effective way to organize some mathematical
>> structures/relationships.  So far as I can see there is no reason calls
>> (or code) couldn't be automatically generated from an illustration like
>> this.  The background explanations (obtained by clicking) could be
>> expanded or linked to code.  IMHO it's not complete but an excellent
>> start for people trying to model statistical data.  For instance draging
>> and dropping particular distributions into an "analyser" for
>> comparisons, etc..., is a logical extension.
>> Of course the missing ingredient is an abstraction direction allowing
>> focusing on particular properties; say different ranges, data types, and
>> so forth.  But those ideas are rendered obvious once the "style" is visible.
> I'd like to develop a similar diagram for Axiom categories listing all of
> the axioms that underpin each category. The links would go to the section
> of the book for that category. I already have an SVG graph of the categories,
> domains, and packages on the Axiom website.
>
> Tim
Well I will give it a shot.  I have written a fairly extensive program 
in Javascript and have been looking for motivation to study "Interactive 
Data Visualization for the Web.pdf"
which I bought and started (and then dribbled off).  The distribution 
bubble chart program looks well organized in Javascript.
BTW: bookvol10.2full.html  doesn't seem to bring up the book when I 
click on the box.

Ray

\start
Date: Sat, 7 Mar 2015 11:18:08 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Graph Drawing

For large graphs, such as Axiom's category/domain/package graph,
it is a challenge to find a 2D representation. This new algorithm
seems to attack that problem.

Graph Drawing by High-Dimensional Embedding
http://www.wisdom.weizmann.ac.il/~harel/papers/highdimensionalGD.pdf

\start
Date: Sat, 07 Mar 2015 13:07:02 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Graph Drawing

On 03/07/2015 12:18 PM, daly@axiom-developer.org wrote:
> For large graphs, such as Axiom's category/domain/package graph,
> it is a challenge to find a 2D representation. This new algorithm
> seems to attack that problem.
>
> Graph Drawing by High-Dimensional Embedding
> http://www.wisdom.weizmann.ac.il/~harel/papers/highdimensionalGD.pdf
>

Yes, but it's dealing with undirected graphs.  Although taking the graph 
analysis approach vs partitioning is interesting.
I imagine something like counting ancestors and dependants to form a 
graph matrix.  Thus contrary to my normal graphing thoughts the nodes 
have weights instead of edges.  That can be reversed by duality but I 
have a hard time giving meaning to that in this usage.  Anyway: each 
node would have an associated list of (ancestors, dependants) lists.  
Then if that could be expressed in sets of polynomials a Groebner basis 
algorithm might be able to generate partitions; where different lex 
schemes would give different partitions and alternate solutions might 
also lead to different partitions. (?)
In other words: some scheme to make the graphs be directly generated 
from code.
Alternately a simple sort by something like ancestors might be 
informative.  Where nodes having fewer ancestors would be higher in the 
abstraction chain.
Or so such; just random thoughts.

Ray

\start
Date: Fri, 13 Mar 2015 09:23:15 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] One more documentation program.

Since I can't find a cross-reference:  I ran across another 
code&documentation system.

Robodoc   http://rfsber.home.xs4all.nl/Robo/index.html

Typically, excuses if this is already mentioned.  In any case this is 
not a recomendation; just a mention.

\start
Date: Fri, 13 Mar 2015 09:20:47 -0600
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: Re: [Axiom-developer] Robodoc

Robodoc, doxygen, javadoc, etc. are all "automatic documentation
systems". They are useful for machine-accurate reference material
for APIs.

Literate programming is not "documentation". It is writing for
humans by humans. There is no automatic tool that can be used
to replace writing down the ideas.

Tim

\start
Date: Sat, 14 Mar 2015 11:52:07 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Continuous Release and Docker

Axiom is moving away from the idea of "releases", monthly or otherwise,

The release cycle is being set up so that when a change is pushed to Git
the latest version is compiled, tested, and immediately released.

Axiom is nearly ready to make the continuous releases live.
The test vehicle will be the Docker image.

If you're using Axiom's Docker distribution you might find that
a Docker image might be broken this weekend as the process is debugged.

Tim

\start
Date: Mon, 16 Mar 2015 10:46:19 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Continuous Deployment of Axiom

I have successfully automated the build, test, and automatic
deployment of Axiom to Docker.

This means that the Docker image has the latest version.

I still need to set up and test automatic triggers on github changes.
Once that process works the Docker image will always be up to date.

If you want to test it, Docker runs on all platforms and therefore
Axiom runs everywhere.

Download Boot2Docker
Start the book2docker client
  docker pull daly/axiom
  docker run -it daly/axiom axiom

Tim

\start
Date: Mon, 16 Mar 2015 17:07:58 -0400
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Continuous Deployment of Axiom

Works on Ubuntu 14.04
Where it failed before??
No Hyperdoc though.

Ray

On 03/16/2015 12:46 PM, daly@axiom-developer.org wrote:
> I have successfully automated the build, test, and automatic
> deployment of Axiom to Docker.
>
> This means that the Docker image has the latest version.
>
> I still need to set up and test automatic triggers on github changes.
> Once that process works the Docker image will always be up to date.
>
> If you want to test it, Docker runs on all platforms and therefore
> Axiom runs everywhere.
>
> Download Boot2Docker
> Start the book2docker client
>    docker pull daly/axiom
>    docker run -it daly/axiom axiom
>
> Tim

\start
Date: Tue, 17 Mar 2015 04:26:21 -0400 (EDT)
From: Tim Daly <daly@axiom-developer.org>
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: Re: [Axiom-developer] Continuous Deployment of Axiom

> Works on Ubuntu 14.04
> Where it failed before??
> No Hyperdoc though.

There appears to be an issue about adding code to Docker.
Once it exceeds a certain limit the upload times out.
It could be a local issue.

Hyperdoc requires X11 which creates a larger upload.
I'll continue to look into it.

I added vi to the build so )help works.
Axiom defaults to vi for )help files. So
   )help Integer
will show the help in vi. Use :q to exit.

A new release was pushed.

Tim



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