> 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 

> 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 

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 


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.

Reply via email to