mjo/eja/DESIGN

   1 Overview
   2 --------
   3 This is a collection of design notes that should eventually wind up in
   4 the documentation. I'm just not sure where they go yet.
   5
   6 Matrix representations
   7 ----------------------
   8
   9 Why allow matrix representations for all algebras?
  10
  11 1. We already have a to_vector() operation that turns an algebra
  12 element into a vector whose coordinates live in the algebra's
  13 base_ring(). Adding a to_matrix() operation is a natural
  14 generalization of that.
  15
  16 2. When constructing a Cartesian product algebra, we don't know a
  17 priori whether or not the result will have matrix-algebra factors. We
  18 can figure it out at runtime, but it would be nice if DirectSumEJA
  19 always returned the same class. Maybe more importantly, if a Cartesian
  20 product has one matrix and one non-matrix factor, then what would its
  21 own matrix representation look like? We want to delegate to the
  22 factors...
  23
  24
  25 Basis normalization
  26 -------------------
  27 For performance reasons, we need a class (RationalBasis...) that
  28 orthonormalizes its own basis. We *could* insist that the user do
  29 this, of course, but the reason we don't want him to is because we
  30 need to know how to undo the process. If we run Gram-Schmidt on the
  31 basis matrix ourselves, then we can save the matrix that undoes the
  32 process. And by undoing the process, we can get to a basis where
  33 computations are fast again.