> No, it is not. The keys for the basis of the PBW are different than those >> for the algebra generators. See the output: >> >> sage: PBW.basis() >> Lazy family (Term map from Free abelian monoid indexed by {alpha[1], >> alphacheck[1], -alpha[1]} to Universal enveloping algebra of Lie algebra >> of ['A', 1] in the Chevalley basis in the Poincare-Birkhoff-Witt basis(i >> ))_{i in Free abelian monoid indexed by {alpha[1], alphacheck[1], -alpha[ >> 1]}} >> sage: PBW.algebra_generators() >> Finite family {-alpha[1]: PBW[-alpha[1]], alpha[1]: PBW[alpha[1]], >> alphacheck[1]: PBW[alphacheck[1]]} >> >> It clearly indicates that the basis keys should be an element of a free >> abelian monoid. LBYL. Now in this case, if we did try to convert the input >> into the keys, it should work. See https://trac.sagemath.org/ticket/18750. >> Actually, it is not as bad as I remembered in terms of outright timings, >> but there are some other technical issues. >> >> > Oh. Sorry. I admit that I have trouble parsing the Lazy family description. >

## Advertising

Yea, I agree it is a bit heavy. There are some ways it could be simplified by saying the function is something like "the monomial map". > Free abelian monoid... Hmmm... What free abelian monoid? > > sage: PBW.basis().keys().an_element() > > PBW[alpha[1]]^2*PBW[alphacheck[1]]^2*PBW[-alpha[1]]^3 > > > So PBW.basis() is _indexed_ by elements of the basis of PBW? I am sorry > for all these stupid questions but (as you can clearly see) I am confused > as hell. > No, they are just have the same names. A good parallel would be the polynomial ring R = ZZ[x,y] in the natural basis. Here, R is the ZZ-algebra of the abelian monoid A = <x,y>, and subsequently, the basis elements are indexed by elements in A. We can call the elements in the monoid <c,d>, but that induces undue overhead on the programmer. For the PBW case, granted it is not a monoid algebra, so we cannot simply *coerce* in things from the indexing monoid (but of course, conversion is allowed), but the design is there. I would just be taking products of the algebra generators anyways and not worrying about constructing elements via the basis. > I looked at the ticket and I have no idea what it is about. > Right now, if we are trying to construct a monomial, we do not convert it into the indexing set of the basis and instead trust the user to do it. The ticket #18750 is about changing that. > > > >> >>> >>> >>>> sage: C.basis() >>>> Lazy family (Term map from Subsets of {0, 1} to The Clifford algebra >>>> of the Quadratic form in 2 variables over Rational Field with >>>> coefficients: >>>> [ 1 0 ] >>>> [ * 1 ](i))_{i in Subsets of {0, 1}} >>>> >>>> So it is expecting subsets and that the user will not input bad data. >>>> There is no reason for it to simplify and not a bug. Granted, we could put >>>> a check on the user input here, but there is a speed penalty as this can >>>> be >>>> a well-used code path internally. Moreover, ducktyping can also be useful. >>>> So we are fairly permissive here, but not without due cause IMO. >>>> >>>> >>> Pardon my ignorance, but If there is no simplification then what is all >>> this good for? It does simplify for universal enveloping algebra and so it >>> should do it for Clifford algebras as well. Also I have a big issue with >>> naming convention here. The method basis() does not produce a basis! >>> >> >> it is *bad input*. It does produce a basis, one indexed by *subsets*, >> not words/multisets. In math terms, if you have a sequence (x_i)_{i \in I}, >> then want x_j, where j \notin I, then you have an error. With #18750, this >> input might instead raise an error. If you want to do that, then you can do >> this: >> >> sage: Q = QuadraticForm(QQ, 2, [1,0,1]) >> sage: C = CliffordAlgebra(Q) >> sage: g = list(C.algebra_generators()); g >> [e0, e1] >> sage: prod(g[i] for i in [0,0,1,0,1,1,0,0]) >> -e0*e1 >> >> If you took your input and wrapped it with set: >> >> sage: set((1,1,0,1)) >> {0, 1} >> >> which would be the other possible outcome with #18750. >> > > But sets are unhashable so how do I actually input the correct keys to cb > = C.basis()? > Here we get into implementation details, and given your previous complaint about index sets, you are not going to like it. The object used to model the subsets are tuples. sage: C.basis().keys() Subsets of {0, 1} sage: list(_) [(), (0,), (1,), (0, 1)] However, we do require an explicit total order on the generators to have a well-defined representative of a monomial. > Another way to solve my original problem (which is to construct certain > element of U \otimes C) would be to take tensor product of elements of U > and C. Something like UC.tensor_elements(E*F+F*E, e*f - f*e). > You can always do tensor([x,y]), and you do not need to explicitly create the parent that way as well. >> Remember that we are bound by the facilities of computer science and >> programming within Sage as well, which are usually much stronger >> constraints than mathematics (e.g., consider the set of real numbers). For >> the current implementation of tensor products, we require the algebra to be >> in AlgebrasWithBasis. I would not say limitations of the current framework >> to be a bug. Also, NC poly rings are in the category of algebras, so it >> does produce an algebra. >> >> > I understand. I just object to naming conventions. I mean the object that > results from calling universal_algebra() presents itself as a ring. How can > I know that it is actually also in category of algebras without digging > through the code? > foo.category() > >> C.basis() does produce a basis. >> >> sage: list(C.basis()) >> [1, e0, e1, e0*e1] >> >> Now pbw_basis() does return an algebra in a particular basis, so in some >> ways, it is returning a basis, just not for the Lie algebra. So now I see >> why you feel it is not completely natural. However, do you have a proposal >> for how to have convenient access to the PBW basis of U(*g*)? IMO, it >> cannot be connected with universal_enveloping_algebra() because that only >> has to return a class modeling the UEA, which should not be required to >> have a PBW basis method. Also, I feel that a PBW basis is really more >> closely connected to the Lie algebra and it is clear to someone working in >> this field what pbw_basis would return. >> > > But that nonocmmutative ring that one gets from > universal_enveloping_algebra() also has some implicit basis. What is this > ring actually good for? I would think that most people would want to work > with some PBW basis anyway. > Perfect bases (the q=1 version of a crystal basis) are equally good. Just having the existence of the UEA can allow you to do a fair bit of the representation theory. Also, there is no reason why we should limit someone doing a Lie algebra implementation to having the UEA be in the PBW basis. Also, for the free Lie algebra, its UEA is the free algebra, which has a natural basis you can work with. I agree that the (NC) poly rings should be in the category of AlgebrasWithBasis as they are given with a distinguished basis, but there are methods that need to be implemented and some inconsistencies to resolve IIRC. > My objection is not only that pbw_basis() doesn't return a basis of L, but > also that it returns algebra (with a preffered chosen basis). > I agree that it is not the best that it does not return a basis *of L*, but there is fundamentally no difference between a basis of the UEA and the UEA in a distinguished basis (other than possibly the interface). > I propose to get rid of pbw_basis method and introduce optional argument > pbw_basis_ordering to universal_enveloping_algebra method. > Very strong -1. I do not believe the UEA should be forced to be in the PBW basis, which is what you are effectively making it do. Either that or you do cannot impose the behavior of a PBW basis. It also imposes much stronger restrictions on universal_enveloping_algebra(). In your proposal as well, the code is suggesting that it should be two separate methods and there is no easy way to construct the UEA in some PBW basis. I am open to changing the name of the method pbw_basis(), but I oppose merging it with universal_enveloping_algebra(). Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.