> > I've created #24914. >
IMO, would be better to have individual tickets for each file/issue as they are independent. If you decide to do that, you can either keep #24914 as a meta-ticket or recycle it as one of the tickets for one of the specific issues. > I will get around to it by the end of the week. I would appreciate > pointers to where tensor() is defined > sage: import_statements(tensor) from sage.categories.tensor import tensor One of the most useful tools for development IMO. :) > and how would one actually define an arbitrary ordering for pbw_basis. > > There is the example in the PBW class and in the Verma modules code. The API is you define a function that takes an index of the Lie algebra's basis and returns a key object just like for Python's sorted() key parameter (in fact, it essentially feeds it off to sorted()). >> +1 <shameless plug>You should also apply for funding as a participant for >> SageDays@ICERM too.</shameless plug> >> > > Will do. Thanks! > It will be great to talk to you in person at both of these and work on improving (Lie) algebras in Sage. :) > > >> >>> >>>> >>>> >>>>> 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). >>>> >>> >>> There is a big conceptual difference between algebra and a basis of an >>> algebra. For all practical purposes, pbw_basis() returns an object that >>> behaves and is used, as far as I can see, as an algebra. I showed the >>> current behavior to participants of SageDays93 and we all agreed that the >>> current behavior of universal_enveloping_algebra() and pbw_basis() is >>> confusing. >>> >> >> I do not know how you presented it, but I feel that it a bit unfair to >> say because you yourself had said you are confused by it. Also, the >> pbw_basis() is not an algebra in the abstract concept but a class modeling >> a chosen PBW basis of the UEA. So there is a lot more structure (and >> limitations). >> > > Sorry. I tried to be fair. I am attachign the notebook I used for > demonstration. > I do not mean to suggest you did not try, but I just feel it is hard to be. > Somebody actually proposed the same thing as Sebastian. Since, as you say, >>> there are implementation difficulties with that approach, what about: >>> universal_enveloping_algebra -> abstract_universal_enveloping_algebra & >>> pbw_basis -> universal_enveloping_algebra? Another suggestion was pbw_basis >>> -> universal_enveloping_algebra_with_pbw_basis. >>> >> >> I believe that is completely unmanageable unless I am misunderstanding >> something about your approach. You would require a (sub)class for each Lie >> algebra that wanted to implement a different UEA that the PBW basis. Let me >> say again that mathematics has a lot more freedom than computer >> implementations; the canonical being the real numbers and formal power >> series. >> >> Here is an idea based on one of your suggestions for how to have >> universal_enveloping_algebra() be more, ahem, universal. >> >> def universal_enveloping_algebra(self, implementation=None, **kwds): >> if implementation is None: >> return self.lift.codomain() >> elif implementation is "PBW": >> return self.pbw_basis(**kwds) >> else: >> raise ValueError("invalid implementation") >> >> This way you can specify the implementation with having a default being >> the (distinguished) one from _construct_UEA() and you get the PBW basis. >> (Well, technically this would go in the LieAlgebrasWithBasis category and >> the one in LieAlgebras would not have the extra PBW implementation elif.) >> >> > I believe this is pretty much what I suggested on 23.2. The latter > suggestions are merely renames of the current methods. I think the absolute > minimum we should do is to rename pbw_basis to something like > universal_enveloping_algebra_pbw That way the naming is not confusing and > the feature is easily discoverable by the user. Merging these two methods > in the way you propose is IMHO nicer API. > It is not in a couple of key areas. The biggest is that is gives you a hook to have multiple implementations (say, as an NC poly ring, the PBW basis, and some other class that is custom built for your purposes). It also has a consistent API for those Lie algebras that may not have a distinguished basis. Let me be clear, I am in no way proposing or suggesting removing pbw_basis(). I also do not like the suggested change of the method name. It is too much of a mouthful and does not offer really any clarity IMO. Again, if we rewrite L.pbw_basis() in function form of pbw_basis(L), wouldn't you prefer that over universal_enveloping_algebra_pbw_basis(L)? Now we can have that be an alias, but we also then should have the alias universal_enveloping_algebra_poincare_birkhoff_witt_basis(). 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 firstname.lastname@example.org. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.