> 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
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
>>>> 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
>> 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
> Sorry. I tried to be fair. I am attachign the notebook I used for
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
>> 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)
>> 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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.