TODO for GluCat 0.8.2 with PyClical
===================================

Documentation:
o Write a programmer's guide with descriptions of usage via use cases.
o Provide better user documentation for PyClical.

Packaging:
o Improve the packaging of the example and test programs.

Portability:
o Build and test GluCat and PyClical using Cygwin on Windows
  (requested by Alan Bromborsky).
o Port to other architectures and compilers which support template template
  parameters.

Interfaces:
  Downwards:
o Try using Eigen or Armadillo as a replacement for uBLAS and Boost bindings.

  Upwards:
o Expand the Cython-based Python extension module PyClical into a Sage interface.
o Try defining Boost concepts and more numeric traits so that GluCat can
  eventually become a Boost library.

Transcendental functions:
o Devise better algorithms and better implementations of existing algorithms for
  the transcendental functions. In particular, pay more attention to radius of
  convergence, condition number of matrices and poking out of the subalgebra.
o Investigate the use of matrix decompositions in the evaluation of
  transcendental functions. See N. J. Higham, Functions of Matrices: Theory and
  Computation, 2008.

Experimental:
o Expand the use of numeric type promotion and demotion from transcendental
  functions to operations such as division.
o Port to C++14 to take maximum advantage of C++11 and C++14 semantics and idioms.
o Investigate the use of expression templates.
o Try refactoring the relationship between matrix_multi, framed_multi and
  clifford_algebra to allow more flexibility with template parameters.
  Possibly use enable_if and SFINAE to do this.
o Try adding a Matrix_Tag template parameter to framed_multi and matrix_multi,
  to determine if matrix_t is compressed, dense, etc.
o Try removing the template parameters LO and HI from framed_multi and
  matrix_multi, and using DEFAULT_LO and DEFAULT_HI where these are needed in
  framed_multi.h, matrx_multi.h, etc.
o Try making Tune_P into a mixin policy class template parameter.
o Add convenience constructors to index_set<>: index_set<>(int, int),
  index_set<>(int, int, int), ... etc.
o Try replacing multiplication by +/-1 within inner products by addition and
  subtraction.
o Try creating a class, vector_multi<>, which uses std::vector rather than
  std::map. This should be faster than framed_multi<>, if tuned properly, for
  full multivectors. For sparse multivectors, it may be slower.
