This should be helpful. I'm afraid strings are usually my quick and dirty solution to problems - don't know enough sage or python yet. Another place where I used string conversion was to sort the mons list for the quotient. Lex then lowest degree (or grade) first. What I did works up to 10 generators at which point g0*g10*g3 comes before g0*g2*g3 plus they have the same degree but different string lengths. So I created a degree list determined by the number of '1's in the bit representation of the monomial. I'd want to sort first by generator index then by degree to do this properly. By the way I wrote Integer(ii+nn^2)[1:nn+1] for my bit rep when it should have been Integer(ii+2**nn)[1:nn+1] which was the same for nn=4 only. As far as ordering I haven't checked what happens in the original free algebra. The monomial g3*g1 doesn't get reordered, but I haven't checked whether g3*g1 + g1*g3 --> g1*g3 + g3*g1 seems like it might be appropriate if '+' is commutative in the free algebra. B ut no 'order' argument or 'commutative' argument exists for '+'
I'm starting a wish list of extra machinery also. For instance the reverse of a cliff_elt. The reverse of monomial g0*g2*g3 is g3*g2*g0 for instance. Then construct lower triangular matrix with rows equal to the coefficients of the reverse of each monomial in the basis and I believe the reverse of an arbitrary cliff_elt is then reconstructed from LTMat*vector(cliff_coef(cliff_elt))...If my reading in http://docs.sympy.org/latest/modules/galgebra/GA.html is correct. On 8/1/2014 2:18 PM, Nils Bruin wrote: > On Thursday, July 31, 2014 8:09:04 PM UTC-7, Stephen Kauffman wrote: >> >> # examples >> cliff_elt = g3*g2*g1*g0 >> [ST.free_algebra()(str(cliff_elt)).coefficient(mon) for mon in >> ST.monomial_basis()] # st_elt.coefficients() results in error since >> it has no such attribute >> > > ST is constructed to be a finite dimensional QQ-vector space, so getting > the coefficients is a matter of viewing the element as a vector over QQ. So > this works: > > sage: zip(cliff_elt.vector(),ST.monomial_basis()) > > Here too: if you find yourself having to use going through string > representations you're doing something wrong. If the system forces you to, > then there's an essential access/coercion feature missing, which should be > fixed. Unless you're trying to do something that's really odd to begin > with, but your questions are entirely reasonable. > > There's some awkwardness in reconstructing the element from this info: > > sage: sum( c*m for c,m in zip(cliff_elt.vector(),ST.monomial_basis())) > TypeError: unsupported operand parent(s) for '*': 'Rational Field' and > 'Free monoid on 4 generators (g0, g1, g2, g3)' > > Scalar multiplication isn't defined on the monoid. That's only defined for > the module spanned by the monoid. So one would have to do one of > > sage: sum( c*PRGA(m) for c,m in zip(cliff_elt.vector(),ST.monomial_basis())) > -4*g0*g1 + 4*g1*g2 - 2*g1*g3 + g0*g1*g2*g3 > sage: sum( c*ST(m) for c,m in zip(cliff_elt.vector(),ST.monomial_basis())) > -4*g0*g1 + 4*g1*g2 - 2*g1*g3 + g0*g1*g2*g3 > > It wouldn't be unreasonable to have the first form available as > cliff_elt.lift(). The second one just reconstructs the original element. > Whether, the "common parent discovery" of the coercion system should be > made aware of monoids and construct modules on monoids when encountering a > scalar multiplication might be problematic (at first blush it seems like > the right kind of construction *if any* is required, but it may have a few > too many unintended consequences). Anyway, the error message is pretty > clear. > > cliff_vect = 5*g0+7*g1-2*g2+6*g3/7 >> # to get the inner product back in the base ring, can't divide say >> g3/(g3*g3) even though g3*g3 scalar ostensibly in base field but not... >> > > Well, in my case g3*g3 happens to be 0 so you cannot divide by it, even > though it is a "scalar". In general, the constructor for a > FreeAlgebraQuotient doesn't require you to make "1" one of the basis > vectors, so even though for you it's clear it lies "in the base field", > sage doesn't know how the base field is embedded in this algebra (if at > all) and hence has no easy way of answering this question for you. > Therefore, "converting back" into the base field is probably never going to > happen (semi) automatically for this kind of algebra. > > For the free algebra it should be able to do this, however, because there > "1" is guaranteed to be there and is recognizable. > > sage: QQ(PRGA.0^0) > TypeError: Unable to coerce 1 (<class > 'sage.algebras.free_algebra_element.FreeAlgebra_generic_with_category.element_class'>) > > to Rational > > That one could be fixed. > > There is some extra machinery that would be nice to have. For instance, it > would be nice if cliff_elt.matrix() were to return: > > M=matrix([(b*cliff_elt).vector() for b in ST.monomial_basis()]) > > then one could see what the characteristic polynomial of an element is and > hence determine if an element is invertible: > > F=M.characteristic_polynomial() > x=F.parent().0 > cliff_elt_inv=(((F-F.constant_coefficient()) // x )/ > F.constant_coefficient())(cliff_elt) > > Having "char_poly", "min_poly", "inverse()" or "is_invertible()" methods on > these finite dimensional free algebra quotient elements would be a > reasonable thing to have. > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
