--- /dev/null
+Overview
+--------
+This is a collection of design notes that should eventually wind up in
+the documentation. I'm just not sure where they go yet.
+
+Matrix representations
+----------------------
+
+Why allow matrix representations for all algebras?
+
+1. We already have a to_vector() operation that turns an algebra
+element into a vector whose coordinates live in the algebra's
+base_ring(). Adding a to_matrix() operation is a natural
+generalization of that.
+
+2. When constructing a Cartesian product algebra, we don't know a
+priori whether or not the result will have matrix-algebra factors. We
+can figure it out at runtime, but it would be nice if DirectSumEJA
+always returned the same class. Maybe more importantly, if a Cartesian
+product has one matrix and one non-matrix factor, then what would its
+own matrix representation look like? We want to delegate to the
+factors...
+
+
+Basis normalization
+-------------------
+For performance reasons, we need a class (RationalBasis...) that
+orthonormalizes its own basis. We *could* insist that the user do
+this, of course, but the reason we don't want him to is because we
+need to know how to undo the process. If we run Gram-Schmidt on the
+basis matrix ourselves, then we can save the matrix that undoes the
+process. And by undoing the process, we can get to a basis where
+computations are fast again.
+
+Question: what's the best way to construct these algebras? We'll
+usually know,
+
+ * the multiplication function
+ * the inner-product function
+ * a basis in either vector or matrix format
+
+and want:
+
+ * an orthonormalized copy of the basis, in long-vector format
+ * the reverse gram-schmidt matrix that deorthonormalizes that
+ long-vector basis
+ * a multiplication matrix (for speed) w.r.t. the orthonormal basis
+ * an inner-product matrix (for speed) w.r.t. the orthonormal basis
+ * a way to turn those two matrices into multiplication and inner-
+ product matrices for the deorthonormalized basis.