>
> 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 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.
