X-Git-Url: http://gitweb.michael.orlitzky.com/?p=sage.d.git;a=blobdiff_plain;f=mjo%2Feja%2FTODO;h=f4b9515c4ed643bd1f9a13c6fc0d6cefa3d32879;hp=0e969cdfe4a2062c6a531b3fa84520c49e88de8f;hb=HEAD;hpb=0103fdda28e6a0f3eda84c625eeda8a3b4754775 diff --git a/mjo/eja/TODO b/mjo/eja/TODO index 0e969cd..b0d5378 100644 --- a/mjo/eja/TODO +++ b/mjo/eja/TODO @@ -1,26 +1,20 @@ -1. Finish DirectSumEJA: add to_matrix(), random_instance(), - one()... methods. Make it subclass RationalBasisEuclideanJordanAlgebra. - This is not a general direct sum / cartesian product implementation, - it's used only with the other rationalbasis algebras (to make non- - simple EJAs out of the simple ones). +1. Add references and start citing them. -2. Add references and start citing them. +2. Profile (and fix?) any remaining slow operations. -3. Implement the octonion simple EJA. +3. When we take a Cartesian product involving a trivial algebra, we + could easily cache the identity and charpoly coefficients using + the nontrivial factor. On the other hand, it's nice that we can + test out some alternate code paths... -4. Pre-cache charpoly for some small algebras? +4. Add dimension bounds on any tests over AA that compute element + subalgebras. -RealSymmetricEJA(4): +5. The rational_algebra() stuff doesn't really belong in classes that + don't derive from RationalBasisEJA or its as-yet-nonexistent + element class. -sage: F = J.base_ring() -sage: a0 = (1/4)*X[4]**2*X[6]**2 - (1/2)*X[2]*X[5]*X[6]**2 - (1/2)*X[3]*X[4]*X[6]*X[7] + (F(2).sqrt()/2)*X[1]*X[5]*X[6]*X[7] + (1/4)*X[3]**2*X[7]**2 - (1/2)*X[0]*X[5]*X[7]**2 + (F(2).sqrt()/2)*X[2]*X[3]*X[6]*X[8] - (1/2)*X[1]*X[4]*X[6*X[8] - (1/2)*X[1]*X[3]*X[7]*X[8] + (F(2).sqrt()/2)*X[0]*X[4]*X[7]*X[8] + (1/4)*X[1]**2*X[8]**2 - (1/2)*X[0]*X[2]*X[8]**2 - (1/2)*X[2]*X[3]**2*X[9] + (F(2).sqrt()/2)*X[1]*X[3]*X[4]*X[9] - (1/2)*X[0]*X[4]**2*X[9] - (1/2)*X[1]**2*X[5]*X[9] + X[0]*X[2]*X[5]*X[9] - -5. The main EJA element constructor is happy to convert between - e.g. HadamardEJA(3) and JordanSpinEJA(3). - -6. Profile the construction of "large" matrix algebras (like the - 15-dimensional QuaternionHermitianAlgebra(3)) to find out why - they're so slow. - -7. Drop the element-subalgebra in favor of a regular subalgebra. The - cached "one" can be set in the method. +6. Add special det/trace method overrides for the algebras where we + know them? The only reason this might be tricky is because the + obvious solution is to subclass EJAElement, but then we might + collide with e.g. the Cartesian product element subclass.