Michael Orlitzky [Wed, 21 Aug 2019 20:10:14 +0000 (16:10 -0400)]
eja: refactor some of the basis and inner-product stuff.
This is movement towards eventually cheating on the charpoly
coefficients, which we should be able to compute in the "nice" basis
and then scale to the normalized one. The coefficients are polynomials
in "the coordinates of x", and those coordinates change only by a
scalar multiple when we normalize the basis.
Michael Orlitzky [Wed, 21 Aug 2019 14:50:55 +0000 (10:50 -0400)]
eja: add "normalize" argument to matrix algebra constructors.
This is useful for two reasons:
1. It's nice to be able to test that some things are invariant
under changes of basis.
2. The min/charpoly computations will be a lot faster if we
can use the basis over QQ (i.e. if the properties that we're
testing in the first item hold).
Michael Orlitzky [Tue, 20 Aug 2019 21:28:06 +0000 (17:28 -0400)]
eja: use NumberField instead of QuadraticField everywhere.
This will be more extensible when we need a field containing both
sqrt(2) and sqrt(-1). QuadraticField can't handle that, so we have to
use NumberField anyway at that point. Might as well get it out of the
way.
Michael Orlitzky [Tue, 20 Aug 2019 20:46:16 +0000 (16:46 -0400)]
eja: normalize the real symmetric matrix basis.
This is necessary to ensure that the default basis representation is
an isometry. When it is not, the left-multiplication operator is
self-adjoint (by the Jordan axiom), but its matrix with respect to
that basis is not. The other two matrix algebras need similar fixing.
Michael Orlitzky [Tue, 20 Aug 2019 15:11:32 +0000 (11:11 -0400)]
eja: use the basis space ring instead of the element's during construction.
Basically, when we're constructing an element, we're trying to fit
some given representation into a pre-existing space. Thus it makes
sense to build that space out of the pre-existing stuff, and not from
the element's base ring. This makes sense in general.
Michael Orlitzky [Sat, 10 Aug 2019 00:00:04 +0000 (20:00 -0400)]
eja: fix the natural representation in trivial subalgebras.
The natural representation relies on knowing a matrix space, and in a
trivial subalgebra there ain't no matrices to have no spaces. To work
around that, the space is now computed/stored separately, in a new
natural_basis_space() method. This is then overridden in the subalgebra
class to do the right thing.
eja: ensure that Sage doesn't think EJAs are associative.
It turns out that the FiniteDimensionalAlgebrasWithBasis category
somehow has both the legacy Algebras() category and the newer
MagmaticAlgebras() category as super-categories. Problem is, the
legacy one is associative! To fix that, we now use MagmaticAlgebras
directly.
Of course, we have to reimplement some of the stuff that was done for
us before... and we have to add a bunch of hacks for parts of Sage
that break when you don't have a ring.... and we can't use a matrix
for our multiplication table any more. But it was all doable.
This way, we don't need to either regenerate it when someone calls
multiplication_table(), or cache a second copy of it. Besides,
matrices are efficient and indexing one is probably faster than
indexing a list of lists.
eja: switch some index orderings to agree with row-then-column semantics.
This doesn't actually affect anything in these cases, but the row "i"
indices should be on the outside whenever we loop through a
two-dimensional array that corresponds to a matrix.
eja: move away from using matrices as our "multiplication table."
Instead of passing around a bunch of matrices that can be applied to
vectors to figure out how multiplication works, it's simpler (and
probably faster) to use a two-dimensional array whose (i,j)th entry
contains the answer to "how do we multiply basis elements i and j?"
When we feed these arrays into the EJA constructor, they must contain
vectors: there's no algebra yet, so it's not like we have any algebra
elements to pass in. However, in the long run, it's much more
convenient to have the multiplication table *stored* in terms of
algebra elements; that way we don't have to convert back and forth
every time we want to multiply two algebra elements. The algebra
constructor now performs this conversion and stores a table containing
algebra elements. This makes product_on_basis() a simple table lookup.
eja: move the element constructor into the parent algebra class.
Instead of using the element's __init__(), we're now using the
algebra's _element_constructor_() method that only gets called
after the parent tries to coerce the argument and fails. This
is somewhat cleaner because we don't have to handle the "usual"
case.
Michael Orlitzky [Sun, 28 Jul 2019 04:36:43 +0000 (00:36 -0400)]
eja: rewrite the operator class again to eliminate VectorSpaceMorphisms.
Wherever possible, I'd like to eliminate row-vector APIs from sneaking
into userland. There's no reason for us to subclass VectorSpaceMorphism,
because left-multiplication by a scalar doesn't work anyway. So, just
drop it, and keep our own matrix variable around instead.
Michael Orlitzky [Sat, 27 Jul 2019 15:05:42 +0000 (11:05 -0400)]
eja: replace the Hom stuff with a custom EJA operator class.
Implementing homsets as linear operators was always a hack, since
linear operators will in general not be algebra homomorphisms. We
wound up re-implementing addition, subtraction, etc. of operators
anyway, so in hindsight, there is no extra difficulty in creating our
own EJA operator class as a subclass of VectorSpaceMorphism.
This commit throws out the EJA morphism stuff, and replaces it with
an equivalent EJA operator class to remain mathematically sound.
Michael Orlitzky [Sat, 27 Jul 2019 00:44:42 +0000 (20:44 -0400)]
eja: fix powers of zero for operators.
When you raise a morphism to the power of zero, it returns an object
(the identity morphism) in a much more general and useless space. We
need to be able to add/subtract these things. So now we have our own
one() method for the Homset, and our own __pow__ for morphisms.
Michael Orlitzky [Fri, 26 Jul 2019 17:03:37 +0000 (13:03 -0400)]
eja: add composition (multiplication) for morphisms.
The whatever-superclass composition of morphisms returned a formal
composition, which can't be treated like a morphism itself. Since all
of our morphisms are represented by matrices, we can simply perform
the composition ourself via matrix multiplication to return something
useful.