Hi Travis,
I had that confusion about the pbw_basis method, as well. From my (non
expert) point of view I would have expected the following:
What is now your L.pbw_basis() I expected to be
L.universal_enveloping_algebra(). This would match what the representation
string is telling you:
sage: L.pbw_basis()
Universal enveloping algebra of Lie algebra of ['A', 2] in the Chevalley
basis in the Poincare-Birkhoff-Witt basis
What is now your L.universal_enveloping_algebra() is just another
(isomorphic) realization. Therefore it could be accessed in this way:
L.universal_enveloping_algebra().as_nc_polynomial_ring()
matching what the representation string is telling you:
sage: L.universal_enveloping_algebra()
Noncommutative
Multivariate Polynomial Ring in b0, b1, b2, b3, b4, b5, b6, b7 over
Rational Field, nc-relations: {b5*b0: b0*b5 - b4, b6*b3: b3*b6 + 2*b6,
.................
Furthermore, conversion maps between these two realization (in both
directions) are desirable. The access to the PBW-basis would be
L.universal_enveloping_algebra().basis()
for which a shorthand L.pbw_basis() maybe be implemented (or not).
Best,
Sebastian
Am Freitag, 23. Februar 2018 23:28:21 UTC+1 schrieb Travis Scrimshaw:
>
>
> 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.
>>
>
> 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.
