\start
Date: Mon, 7 Nov 2016 04:13:20 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Future research directions (Quantum Computing)

Axiom is reaching a stable point where it can support research
in new areas. There is current work on Gustafson's Universal
Numbers (UNUMS) which promises to simplify the numeric
libraries. It seems to also promise some symbolic/numeric
\begin{verbatim}computation. Time will tell.

Another area, still at the read-the-literature stage is quantum
computing. IBM has made a 5-qubit machine available on the
web. Some effort was devoted to implementing known algorithms.

Quantum computing had come a long way in the last few years.
There are several attempts to create a high level language for
expressing algorithms.

Quipper is an interesting effort:
www.mathstat.dal.ca/~selinger/quipper
It is currently implemented on top of Haskell but it looks like
it could be implemented in Axiom. It uses Knill's QRAM model.
Some papers:
https://arxiv.org/pdf/1304.3390v1.pdf (Overview of the language)
https://arxiv.org/pdf/1304.5485v1.pdf (Introductory examples)

My particular interest is twofold: Given my crypto background I'm
interested in the post-crypto quantum work. I'm also interested in
my observation that Hadamard gates are the basis for both unitary
quantum operations and shared-channel telecommunications. By
combining quantum crypto and shared-channel communication it
seems that there is a potential for ultra-secure communication.

There are quantum computer simulators which could be embedded
into Axiom to support simulated quantum development. Since the
quantum operations are simple (unitary matrix operators) we could
create a syntax and language front end to express them. For instance,
being able to write a|Y> using the bra and ket notation.

This is a NIST-supported exploding area of research with many dozens
of algorithms already available in the literature:
http://math.nist.gov/quantum/zoo/

Tim


\start
Date: Mon, 7 Nov 2016 04:32:31 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Future research directions (Universal Numbers)

Numeric computations have been locked into IEEE arithmetic
for a long time. The problems are well known. NAG's numeric
routines have a huge number of parameters to deal with these
issues.

Axiom now has (growing) support for BLAS/LAPACK in native
form. This gives us the opportunity to explore alternative
number formats. BLAS routines could be adapted to use
interval arithmetic but initial experiments show that this tends
to generate wide, uninformative intervals.

Gustafson[0] has proposed a universal number format (UNUMs)
which essentially allows two things. First, you can re-define the
width of the exponent and mantissa fields to match the problem.
Second, you can define exact intervals to generate exact results.

Efforts are underway to create a new UNUM number format which,
hopefully, can be used in any context that DFLOAT can be used
(e.g. in polynomials).

In the longer but still near term Intel has bought Altera so it now
owns about 45% of the Field Programmable Gate Array (FPGA)
market. They have used their manufacturing to shrink the die size
by many generations and incorporated the FPGA onto the latest
Intel processor chip. What this likely means is the ability to define
new, novel instructions "on the fly" from your program. That would
allow "hardware UNUM support".

Ultimately this has the potential to allow strong symbolic/numeric
computation that does not suffer from overflow/underflow problems
and allows "symbolic epsilons". These symbolic epsilons can
eliminate the rounding-error / cancellation problems, leading to
more exact arithmetic and dynamic error analysis.

Tim

[0] Gustafson, John "The End of Error" 13-978-1-4822-3986-7 (2015)

\start
Date: Mon, 7 Nov 2016 05:00:51 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Future research directions (Deep Neural Networks)

There is an explosion of research on Deep Neural Networks.
OpenAI (https://openai.com/blog/) has 1 billion (US) dollars
in support. They are doing focused work on reinforcement
learning. Baidu, Google, Facebook, etc. are all deeply in the
game.

Specifying Neural Networks to solve problems is easy. See
https://www.youtube.com/watch?v=sEciSlAClL8 which explains
the steps and the code to get 99+% accuracy on the MNIST
dataset (handwritten digits).

Tensorflow includes primitives, such as 2d convolution,
matrix multiplication, symbolic derivatives, RELU (rectified
linear unit which is just zero for negative values and linear
otherwise), sigmoid functions, atan functions, etc. The actual
computation is just linear matrix computations, XW+B where
X are the data, W are the weights, and B are the biases.

Latest "best practices" shows that deep neural networks are
best implemented by repeating layers of XW+B followed by
a non-linear (e.g. RELU, Sigmoid, Atan) step.

Axiom has the ability to do all of these tasks, making it a good
platform for further research. In particular, there seems to be
little "algorithmic analysis". The DNN area and NN research
in general seems to be a collection of "tricks" (e.g. dropout).
This is troubling since there is no easy way to predict the
actual result, and rather frightening when the DNN is driving
your car.

In theory what a DNN computes can be computed using a
single layer NN. Can Axiom be used to "collapse" the layers
by combining and spreading derivatives? A single layer NN
with complicated derivatives seems easier to analyze than a
multilayer iterated structure. The complicated derivatives could
be "grouped" into similar classes and the shape of the higher
order curves explored using symbolic expressions. This would
give a clearer view of what the NN will do, where the high
dimensional "valleys" lie, and where the system is sensitive.
Such an ability to do analysis could reshape the industry.

Tim

\start
Date: Mon, 7 Nov 2016 12:18:06 -0700
From: Jovan Trujillo <jovan.trujillo2@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Axiom-developer Digest, Vol 155, Issue 1

All of these research topics sound amazing to me. Are you submitting researc=
h proposals for them?

Sent from my iPhone

> On Nov 7, 2016, at 10:00 AM, axiom-developer-request@nongnu.org wrote:
>
> Send Axiom-developer mailing list submissions to
>    axiom-developer@nongnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.nongnu.org/mailman/listinfo/axiom-developer
> or, via email, send a message with subject or body 'help' to
>    axiom-developer-request@nongnu.org
>
> You can reach the person managing the list at
>    axiom-developer-owner@nongnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Axiom-developer digest..."
>
>
> Today's Topics:
>
>   1. Future research directions (Quantum Computing) (Tim Daly)
>   2. Future research directions (Universal Numbers) (Tim Daly)
>   3. Future research directions (Deep Neural Networks) (Tim Daly)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Nov 2016 04:13:20 -0500
> From: Tim Daly <axiomcas@gmail.com>
> To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly
>    <daly@axiom-developer.org>
> Subject: [Axiom-developer] Future research directions (Quantum
>    Computing)
> Message-ID:
>    <CAJn5L=3D+GffD7RZc8Aks7M4XdYC+z=3DQ4SQdcDEAXsZH4mQie1zg@mail.gmail.com=
>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Axiom is reaching a stable point where it can support research
> in new areas. There is current work on Gustafson's Universal
> Numbers (UNUMS) which promises to simplify the numeric
> libraries. It seems to also promise some symbolic/numeric
> computation. Time will tell.
>
> Another area, still at the read-the-literature stage is quantum
> computing. IBM has made a 5-qubit machine available on the
> web. Some effort was devoted to implementing known algorithms.
>
> Quantum computing had come a long way in the last few years.
> There are several attempts to create a high level language for
> expressing algorithms.
>
> Quipper is an interesting effort:
> www.mathstat.dal.ca/~selinger/quipper
> It is currently implemented on top of Haskell but it looks like
> it could be implemented in Axiom. It uses Knill's QRAM model.
> Some papers:
> https://arxiv.org/pdf/1304.3390v1.pdf (Overview of the language)
> https://arxiv.org/pdf/1304.5485v1.pdf (Introductory examples)
>
> My particular interest is twofold: Given my crypto background I'm
> interested in the post-crypto quantum work. I'm also interested in
> my observation that Hadamard gates are the basis for both unitary
> quantum operations and shared-channel telecommunications. By
> combining quantum crypto and shared-channel communication it
> seems that there is a potential for ultra-secure communication.
>
> There are quantum computer simulators which could be embedded
> into Axiom to support simulated quantum development. Since the
> quantum operations are simple (unitary matrix operators) we could
> create a syntax and language front end to express them. For instance,
> being able to write a|Y> using the bra and ket notation.
>
> This is a NIST-supported exploding area of research with many dozens
> of algorithms already available in the literature:
> http://math.nist.gov/quantum/zoo/
>
> Tim
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.nongnu.org/archive/html/axiom-developer/attachments/201=
61107/a602b272/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Nov 2016 04:32:31 -0500
> From: Tim Daly <axiomcas@gmail.com>
> To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly
>    <daly@axiom-developer.org>
> Subject: [Axiom-developer] Future research directions (Universal
>    Numbers)
> Message-ID:
>    <CAJn5L=3DJ3EvGEHzFUfwUnG86HE0hwzgvR9_ty00+gAgzU=3DvQo7A@mail.gmail.com=
>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Numeric computations have been locked into IEEE arithmetic
> for a long time. The problems are well known. NAG's numeric
> routines have a huge number of parameters to deal with these
> issues.
>
> Axiom now has (growing) support for BLAS/LAPACK in native
> form. This gives us the opportunity to explore alternative
> number formats. BLAS routines could be adapted to use
> interval arithmetic but initial experiments show that this tends
> to generate wide, uninformative intervals.
>
> Gustafson[0] has proposed a universal number format (UNUMs)
> which essentially allows two things. First, you can re-define the
> width of the exponent and mantissa fields to match the problem.
> Second, you can define exact intervals to generate exact results.
>
> Efforts are underway to create a new UNUM number format which,
> hopefully, can be used in any context that DFLOAT can be used
> (e.g. in polynomials).
>
> In the longer but still near term Intel has bought Altera so it now
> owns about 45% of the Field Programmable Gate Array (FPGA)
> market. They have used their manufacturing to shrink the die size
> by many generations and incorporated the FPGA onto the latest
> Intel processor chip. What this likely means is the ability to define
> new, novel instructions "on the fly" from your program. That would
> allow "hardware UNUM support".
>
> Ultimately this has the potential to allow strong symbolic/numeric
> computation that does not suffer from overflow/underflow problems
> and allows "symbolic epsilons". These symbolic epsilons can
> eliminate the rounding-error / cancellation problems, leading to
> more exact arithmetic and dynamic error analysis.
>
> Tim
>
> [0] Gustafson, John "The End of Error" 13-978-1-4822-3986-7 (2015)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.nongnu.org/archive/html/axiom-developer/attachments/201=
61107/5f80eb25/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 7 Nov 2016 05:00:51 -0500
> From: Tim Daly <axiomcas@gmail.com>
> To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly
>    <daly@axiom-developer.org>
> Subject: [Axiom-developer] Future research directions (Deep Neural
>    Networks)
> Message-ID:
>    <CAJn5L=3DLCcOUF2Cgx4Q=3D4uqGbwwPvot6Q5x59jvFasdWU9Q09VQ@mail.gmail.com=
>
> Content-Type: text/plain; charset=3D"utf-8"
>
> There is an explosion of research on Deep Neural Networks.
> OpenAI (https://openai.com/blog/) has 1 billion (US) dollars
> in support. They are doing focused work on reinforcement
> learning. Baidu, Google, Facebook, etc. are all deeply in the
> game.
>
> Specifying Neural Networks to solve problems is easy. See
> https://www.youtube.com/watch?v=3DsEciSlAClL8 which explains
> the steps and the code to get 99+% accuracy on the MNIST
> dataset (handwritten digits).
>
> Tensorflow includes primitives, such as 2d convolution,
> matrix multiplication, symbolic derivatives, RELU (rectified
> linear unit which is just zero for negative values and linear
> otherwise), sigmoid functions, atan functions, etc. The actual
> computation is just linear matrix computations, XW+B where
> X are the data, W are the weights, and B are the biases.
>
> Latest "best practices" shows that deep neural networks are
> best implemented by repeating layers of XW+B followed by
> a non-linear (e.g. RELU, Sigmoid, Atan) step.
>
> Axiom has the ability to do all of these tasks, making it a good
> platform for further research. In particular, there seems to be
> little "algorithmic analysis". The DNN area and NN research
> in general seems to be a collection of "tricks" (e.g. dropout).
> This is troubling since there is no easy way to predict the
> actual result, and rather frightening when the DNN is driving
> your car.
>
> In theory what a DNN computes can be computed using a
> single layer NN. Can Axiom be used to "collapse" the layers
> by combining and spreading derivatives? A single layer NN
> with complicated derivatives seems easier to analyze than a
> multilayer iterated structure. The complicated derivatives could
> be "grouped" into similar classes and the shape of the higher
> order curves explored using symbolic expressions. This would
> give a clearer view of what the NN will do, where the high
> dimensional "valleys" lie, and where the system is sensitive.
> Such an ability to do analysis could reshape the industry.
>
> Tim
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.nongnu.org/archive/html/axiom-developer/attachments/201=
61107/9ff6ee93/attachment.html>
>

\start
Date: Tue, 8 Nov 2016 02:02:39 +0300
From: Martin Irungu <waiharoirungum@gmail.com>
To: "axiom-developer@nongnu.org" <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fedora build failure

I downloaded the August 2014 source tarball for Fedora (I am running Fedora
24). I've followed the instructions on the download page and readme, except
for installing texlive-fonts-extra (I couldn't find an RPM anywhere so I
just installed texlive-full instead)
Make freezes after building vol. 13 of the book. The readme says to allow
about 2 hrs for the build on a 2GHz machine. I've waited nearly five,
restarted it twice and tried it on a different computer (also on Fedora).
It keeps stopping just after it builds the PDFs.
Could someone please explain how I should proceed and perhaps update the
download page to include an alternative to texlive-fonts-extra? I can't
imagine everyone trying to install Axiom on Fedora also has to fetch all of
TeXlive.

Martin

\start
Date: Tue, 8 Nov 2016 07:21:10 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Martin Irungu <waiharoirungum@gmail.com>,
	Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Fedora Build Failure

Try the following:

  git clone git:://github.com/daly/axiom
  cd axiom
  export AXIOM=`pwd`/mnt/fedora64
  export PATH=$AXIOM/bin:$PATH
  make NOISE= | tee console

If it still hangs I will need to know what Fedora image
you have installed so I can build a machine with your
exact image. Which ISO file did you use?

If it fails for any other reason please do
    tail -200 console >failure
and post the failure file.

Tim

\start
Date: Tue, 8 Nov 2016 17:48:04 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Martin Irungu <waiharoirungum@gmail.com>,
	Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>, gcl-devel@gnu.org
Subject: Re: [Axiom-developer] Fedora Build Failure

Martin,

Your build is failing with GCL, not Axiom. There is a known problem
with the latest GCC which seems to be causing failures. Try:

   git clone git://git.savannah.gnu.org/gcl.git
   cd git
   ./configure
   make

and let me know if that succeeds or fails.

Tim

On Tue, Nov 8, 2016 at 9:32 AM, Martin Irungu <waiharoirungum@gmail.com>
wrote:

> Thanks for responding. This
> <http://archive.fedoraproject.org/pub/fedora/linux/releases/24/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-24-1.2.iso>
> is the exact image I'm running. I had tried 'make NOISE=' after I sent the
> report and got the same error message.
>
> On Tue, Nov 8, 2016 at 3:21 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> Try the following:
>>
>>   git clone git:://github.com/daly/axiom
>>   cd axiom
>>   export AXIOM=`pwd`/mnt/fedora64
>>   export PATH=$AXIOM/bin:$PATH
>>   make NOISE= | tee console
>>
>> If it still hangs I will need to know what Fedora image
>> you have installed so I can build a machine with your
>> exact image. Which ISO file did you use?
>>
>> If it fails for any other reason please do
>>     tail -200 console >failure
>> and post the failure file.
>>
>> Tim
>>
>>
>

\start
Date: Thu, 10 Nov 2016 01:06:32 -0500
From: Lawrence Bottorff <borgauf@gmail.com>
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Latest Ubuntu compile fail

Tried

apt-get install m4 libxpm-dev libxt-dev libx11-dev
apt-get install libxext-dev gettext git-core texlive gawk
texlive-fonts-extra
git clone git://github.com/daly/axiom.git
cd axiom
export AXIOM=`pwd`/mnt/ubuntu
export PATH=$AXIOM/bin:$PATH
make

on my Ubuntu 16.10 and got this

. . .
num_sfun.c:(.text+0xbc14): undefined reference to `number_zero_expt'
./libpre_gcl.a(num_sfun.o):num_sfun.c:(.text+0xbc99): more undefined
references to `number_zero_expt' follow
collect2: error: ld returned 1 exit status
makefile:171: recipe for target 'raw_pre_gcl_map' failed
make[4]: *** [raw_pre_gcl_map] Error 1
make[4]: Leaving directory
'/home/hercynianx201/bin/axiom/lsp/gcl-2.6.12/unixport'
makefile:71: recipe for target 'unixport/saved_pre_gcl' failed
make[3]: *** [unixport/saved_pre_gcl] Error 2
rm h/mcompdefs.h
make[3]: Leaving directory '/home/hercynianx201/bin/axiom/lsp/gcl-2.6.12'
/bin/sh: 6: unixport/saved_gcl: not found
Makefile:8: recipe for target 'gcldir' failed
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory '/home/hercynianx201/bin/axiom/lsp'
Makefile.ubuntu:169: recipe for target 'lspdir' failed
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory '/home/hercynianx201/bin/axiom'
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Please advise.

LB

\start
Date: Fri, 11 Nov 2016 20:07:58 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Lawrence Bottorff <borgauf@gmail.com>,
	Martin Irungu <waiharoirungum@gmail.com>, 
	Tim Daly <daly@axiom-developer.org>, gcl-devel@gnu.org, 
	axiom-dev <axiom-developer@nongnu.org>,
	Camm Maguire <camm@maguirefamily.org>, Kurt Pagani <nilqed@gmail.com>
Subject: [Axiom-developer] GCL on Fedora

I spent the day trying to debug why GCL build fails on Fedora
and Scientific Linux without success. The problem is not related
to selinux.

I can build the latest GCL on 64 bit machines using Ubuntu.
I can run the 64 bit executable on Fedora (so the shared libraries
seem to be fine).

I cannot build GCL on Fedora. Either the problem is with configure
or something about make seems broken. The build seems to skip
the order of the rules in the makefile, jumping immediately to the
install stanza. Further, the $prefix variable doesn't seem to be set.

I will try again tomorrow.

Tim

\start
Date: Mon, 14 Nov 2016 03:34:01 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] [quantum] Axiom's Quantum Computing implementation

For those who want to work at the research front I'm going
to post links to sites that provide quantum computing ideas.
These posts will have the [quantum] label. Axiom can support
qubits as a type. It can implement Knill's architecture (i.e.
using a classical computer to control a quantum computer).

For those who need things to seem "useful" it appears that
quantum computers can find the group underlying the algorithms
at the heart of public key encryption. That implies that the whole
internet falls since things like site certificates depend on it. Axiom
has added a chapter on finite fields written by Grabmeier (Chapter 8)
http://axiom-developer.org/axiom-website/bookvol10.1.pdf
(the author of Axiom's FF types) as well as links to background
courses embedded in Axiom's PDFs (e.g.
http://axiom-developer.org/axiom-website/GroupTheoryII/Salomone.html

There are implementations of quantum computing simulations
making it possible to run quantum programs on stock hardware.
An online example is the Quantum Computing Playground
http://www.quantumplayground.net/#/home
which provides simulation of up to 22 qubits. Axiom could
implement such a simulation engine.

IBM provides a real online 5-qubit quantum computer
http://www.research.ibm.com/quantum/
I've tried to implement some trivial algorithms there.

The Quipper language
http://www.mathstat.dal.ca/~selinger/quipper/
is a Haskell-based language. Axiom actually provides more
features than the Haskell platform, such as dependent types,
which the Haskell implementation has to check at runtime.

Quipper is supported by DARPA. They have implemented
7 non-trivial quantum algorithms required by DARPA.

A good introduction is provided by Siddiqui, et al.
"Five Quantum Algorithms Using Quipper"
https://arxiv.org/pdf/1406.4481v2.pdf

For a solid background, Susskind's lectures are golden:
http://newpackettech.com/Resources/Susskind/

For a computer science background see
Mermin, David "Quantum Computer Science" 978-0-521-87658-2

This is research so there will be blind paths, speculation,
confusion, and all the usual fun without the unusual riches.
But that's what we "research rats" love.

Tim "research rat" Daly

\start
Date: Mon, 14 Nov 2016 04:11:58 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	William Sit <wsit@ccny.cuny.edu>
Subject: [Axiom-developer] [quantum] Geometric Algebra

Current quantum computing uses 2x2 (Pauli) operators
and (4x4) Dirac operators expressed as matrices.

But Hestenes
https://en.wikipedia.org/wiki/David_Hestenes
showed that these are simple subdomains of the Clifford
(aka Geometric) Algebra. Axiom implements the Clifford
algebra so it should be possible to re-formulate the
quantum algorithms using operations expressed in
this more general form.

It is possible that these more general Clifford forms would
improve clarity and expressiveness for quantum algorithms.
In particular, applying Clifford notation to the Bloch sphere
rotations seems like an interesting idea.

Also of interest is that the Hadamard gate, expressed as a
matrix [[1,1],[1,-1]], is fundamental quantum operator. But it
is also the method of constructing communication codes so
that multiple endpoints can fully share the same channel using
the full channel bandwidth. This leads to the thought that
quantum communication is intimately linked with these higher
codes. See
http://www.uow.edu.au/~jennie/WEBPDF/2005_12.pdf

A Geometric Algebra formulation of these matrix operations
provides a more general, coordinate-free language.

This leads to the need for more work on the Clifford domain.

Tim

\start
Date: Mon, 14 Nov 2016 06:04:14 -0800
From: Arthur Ralfs <arthur@mathbrane.ca>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] [quantum] Geometric Algebra

Be aware that Hestenes has copyrighted some of his material.

Arthur


On 11/14/2016 01:11 AM, Tim Daly wrote:
> Current quantum computing uses 2x2 (Pauli) operators
> and (4x4) Dirac operators expressed as matrices.
>
> But Hestenes
> https://en.wikipedia.org/wiki/David_Hestenes
> showed that these are simple subdomains of the Clifford
> (aka Geometric) Algebra. Axiom implements the Clifford
> algebra so it should be possible to re-formulate the
> quantum algorithms using operations expressed in
> this more general form.
>
> It is possible that these more general Clifford forms would
> improve clarity and expressiveness for quantum algorithms.
> In particular, applying Clifford notation to the Bloch sphere
> rotations seems like an interesting idea.
>
> Also of interest is that the Hadamard gate, expressed as a
> matrix [[1,1],[1,-1]], is fundamental quantum operator. But it
> is also the method of constructing communication codes so
> that multiple endpoints can fully share the same channel using
> the full channel bandwidth. This leads to the thought that
> quantum communication is intimately linked with these higher
> codes. See
> http://www.uow.edu.au/~jennie/WEBPDF/2005_12.pdf
>
> A Geometric Algebra formulation of these matrix operations
> provides a more general, coordinate-free language.
>
> This leads to the need for more work on the Clifford domain.
>
> Tim

\start
Date: Mon, 14 Nov 2016 18:43:06 +0100
From: Bertfried Fauser <Bertfried.Fauser@uni-konstanz.de>
To: axiom-devel <Axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] [quantum] Geometric Algebra

Hi Arthur,

  there were rumors about this when Rafal and I developed our Clifford
package (mid 90ies), so we registered it as original work with the US
Library of Congress (Rafal knows how he did that) and that makes it a
publicly available piece of software (and unpatentable). Though it
needs (alas) Maple to run, the software as it stands is open source
freely available and can be used (modified rewritten). Anyhow I will
patent natural numbers and all derived concepts, hey why not sets
(after Bourbaki all math is derivable from that :) )

@Tim:
  Martin Baker has written a new Grassmann and Clifford package for
FriCAS, which goes beyond what was done in AXIOM before. The
implementation of Clifford algebras in AXIOM is at best a proof of
concept. Rafal's and mine Clifford package have algorithms which in
certain situations can be proven to be optimal, and also special
(fast)
algorithms for diagonal (in suitable bases) bilinear (polar) forms (of
quadratic forms). Without such fast algorithms computations in
Clifford algebras of dimension 5 or higher are not feasible, even with
fast algorithms, the computation of a Clifford algebra multiplication
table
is not possible for dimension 8/9 upwards. Rafal and I investigated
how to parallelise the Clifford product, as Maple has some coarse
grained parallelism. We got 11 times faster code on a two core machine
(amazing isn't it?) and it showed to us that a much better design of
data structures brought more gain in speed that doing parallel
computations (2 versus 5.5 at best). Robotics people do computations
in 9 to 11 (base space) dimenional Clifford algebras and would also be
interested in fast software for doing that.
  While Hestenes was influential in the Geometric Algebra camp, he was
not the person who did this first. There is a continuous literature
going back to Hamilton, Grassmann and Clifford. Though Geometric
Algebra people do tend not to cite these papers.
  In the mid 90ies people tried to do quantum computing stuff using
Clifford algebras in the Hestenes (operator spinor) style. However
they ran into problems:
  When you tensor matrices not spinors, you pick up additional
dimensions, the proper tensor product is an amalgamated (central
product) one. People then used 'quantum correlators' (aka projection
operators) to fix this. However, in the end they just reconstructed
what people did with (spin-tensor) matrices anyhow. Unless there is
more insight or more abstraction (basis free Clifford algebras are
still a challenge to be done in a CAS) it might be not that fruitful?
Anyhow, a search for literature might be helpful. If I remember rightly
there was a special issue for Hestenes' 60ies birthday in Foundatons
of Physics, and in that you will find some of the work mentioned above
by Doran, Lasenby et al.

Unfortunately I do not have much time at the moment to help out, but if
question arise regarding algorithms related to Grassmann and Clifford
algebras etc I try to help.

Kind regards
BF.


-- 
% Dr Bertfried Fauser
%      Phone :  +49 7471 4031397   Mobile : +49 176 64094110

\start
Date: Mon, 14 Nov 2016 10:11:41 -0800
From: Arthur Ralfs <arthur@mathbrane.ca>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] [quantum] Geometric Algebra

Bertfried,

Yours and Tim's private response has put my mind at ease, I guess.  My 
concern was based on a book, Geometric Algebra by Dorst, Fontijne, and 
Mann, recommended by Martin Baker, a few years ago.  When I got to 
section 13.8 it was mentioned that some of the work was patented and not 
freely available for commercial use.

Arthur

On 11/14/2016 09:43 AM, Bertfried Fauser wrote:
> Hi Arthur,
>
>   there were rumors about this when Rafal and I developed our Clifford
> package (mid 90ies), so we registered it as original work with the US
> Library of Congress (Rafal knows how he did that) and that makes it a
> publicly available piece of software (and unpatentable). Though it
> needs (alas) Maple to run, the software as it stands is open source
> freely available and can be used (modified rewritten). Anyhow I will
> patent natural numbers and all derived concepts, hey why not sets
> (after Bourbaki all math is derivable from that :) )
>
> @Tim:
>   Martin Baker has written a new Grassmann and Clifford package for
> FriCAS, which goes beyond what was done in AXIOM before. The
> implementation of Clifford algebras in AXIOM is at best a proof of
> concept. Rafal's and mine Clifford package have algorithms which in
> certain situations can be proven to be optimal, and also special
> (fast)
> algorithms for diagonal (in suitable bases) bilinear (polar) forms (of
> quadratic forms). Without such fast algorithms computations in
> Clifford algebras of dimension 5 or higher are not feasible, even with
> fast algorithms, the computation of a Clifford algebra multiplication
> table
> is not possible for dimension 8/9 upwards. Rafal and I investigated
> how to parallelise the Clifford product, as Maple has some coarse
> grained parallelism. We got 11 times faster code on a two core machine
> (amazing isn't it?) and it showed to us that a much better design of
> data structures brought more gain in speed that doing parallel
> computations (2 versus 5.5 at best). Robotics people do computations
> in 9 to 11 (base space) dimenional Clifford algebras and would also be
> interested in fast software for doing that.
>   While Hestenes was influential in the Geometric Algebra camp, he was
> not the person who did this first. There is a continuous literature
> going back to Hamilton, Grassmann and Clifford. Though Geometric
> Algebra people do tend not to cite these papers.
>   In the mid 90ies people tried to do quantum computing stuff using
> Clifford algebras in the Hestenes (operator spinor) style. However
> they ran into problems:
>   When you tensor matrices not spinors, you pick up additional
> dimensions, the proper tensor product is an amalgamated (central
> product) one. People then used 'quantum correlators' (aka projection
> operators) to fix this. However, in the end they just reconstructed
> what people did with (spin-tensor) matrices anyhow. Unless there is
> more insight or more abstraction (basis free Clifford algebras are
> still a challenge to be done in a CAS) it might be not that fruitful?
> Anyhow, a search for literature might be helpful. If I remember rightly
> there was a special issue for Hestenes' 60ies birthday in Foundatons
> of Physics, and in that you will find some of the work mentioned above
> by Doran, Lasenby et al.
>
> Unfortunately I do not have much time at the moment to help out, but if
> question arise regarding algorithms related to Grassmann and Clifford
> algebras etc I try to help.
>
> Kind regards
> BF.
>
>

\start
Date: Wed, 16 Nov 2016 12:34:06 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] [Category Theory] Lecture on Category Theory

This is an excellent course on Category Theory:
https://www.youtube.com/watch?v=I8LbkfSSR58&index=1&list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_

Tim

\start
Date: Tue, 29 Nov 2016 20:51:37 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Oral Tradition in Software Engineering

https://www.youtube.com/watch?v=4PaWFYm0kEw

quoting one slide:

Comments as oral tradition

The best comments seem to have an aspect of oral tradition
to them; they not only explain what is going on but
provide a narative as to why.

Comments live with the code but do not otherwise affect its
correctness -- allowing for broad scope and artistic license.

Relevant, correct software systems will survive long past their
creators; comments are the art within the timeless machine.

Comments are how we speak to future generations.

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