Acess bracketed elements in free lie algebra element

69 views
Skip to first unread message

Sam DeHority

unread,
Feb 13, 2020, 12:48:24 PM2/13/20
to sage-devel
I asked the following question on ask.sagemath : https://ask.sagemath.org/question/49897/acess-bracked-elements-in-free-lie-algebra-element/ and I'll copy it here. 

I'm trying to access the left and right elements in a free lie algebra element, whose monomials are stored as binary trees. Thus I want a method (like exists in the source for lie_algebra_element) which would return something like

sage:  L = LieAlgebra(QQ, 3, 'x')
sage: x0,x1,x2 = L.gens()
sage: Lyn = FL.Lyndon()
sage: a = Lyn.graded_basis(3)[2]; a
[[x0, x1], x1]
sage: a._left
[x0,x1]
sage: a._right
x1

Of course the last 4 lines are fake. One way of seeing this is the following:

sage: isinstance(a, LyndonBracket)
False
sage: isinstance(a, LieBracket)
False

How do I fix this "the right way" ? My current solution is just to set

sage: a_tree = eval(repr(a)); a_tree
[[x0, x1], x1]

But this feels extremely wrong.


The response suggested to do the following:
sage: a_tree = a.list()[0][0]; a_tree
[[x0, x1], x1]
sage: isinstance(a_tree, sage.algebras.lie_algebras.lie_algebra_element.LyndonBracket)
True
sage: a_tree._left
[x0, x1]
sage: a_tree._right
x1


But this has its own issues:
sage: x1 == a_tree._right
False

Because x1 is an element of the free Lie algbera but a_tree._right is just some LieGenerator. The responder also suggested I post here. Perhaps there's a better way to represent elements of the free lie algebra so that the brackets are accessible (say if you ever want to expand something using the Jacobi identity, which I do) in a reasonable manner? 

Travis Scrimshaw

unread,
Feb 14, 2020, 2:49:56 AM2/14/20
to sage-devel
The element a is an element of the Lie algebra, not a pure Lie bracket:

sage: type(a)
<class 'sage.algebras.lie_algebras.free_lie_algebra.FreeLieAlgebra.Lyndon_with_category.element_class'>

In particular, it can be a sum of Lie brackets. Similarly a generator for the Lie algebra is not a LieGenerator (which is a special class for the leaf in the (leaf-)labeled complete binary tree representing a Lie bracket) as it is an element of the algebra. Instead you need to get access to the Lie bracket in the support, which you can then use standard list-like behavior:

sage: b = a.support()[0]
sage
: type(b)
<class 'sage.algebras.lie_algebras.lie_algebra_element.LyndonBracket'>
sage
: b[0]
[x0, x1]
sage
: b[1]
x1
sage
: b._left
[x0, x1]
sage
: b._right
x1

This is a common design for most algebras in SageMath indexed by combinatorial objects. To that point, combinatorial objects do not carry any algebraic structure (you can think of them purely as labels for the strings); here, in order to be lightweight objects for speed reasons, they do not have a parent, and so there is no coercion. Furthermore, it was designed this way so there was both minimal redundancy, avoiding definition loops (the basis is indexed by the algebra elements which are given by the basis) and ease of implementing the basis elements, multiplication, and conversion between the two bases.

With that being said, this can be improved by adding support for things like:

sage: Lyn(b)  # This currently does not work

This likely won't solve the comparison problem outright, but it will make it easier to compare. However, I don't think it is a good idea to actually modify the LieBracket and LieGenerator to make them behave more algebra like; I don't think it is easily possible to make them behave the same way. Instead if you think this is a necessary feature (which I am not fully convinced because I don't know what you are trying to do with it), I think the best solution is essentially to sidestep it by adding methods to the FreeLieAlgebraElement that return algebra elements back and error when there is more than one term in the support. However, without knowing your application (specifically, what data you want and what you want to do with it), I cannot say for certain what the best remedy is.

Best,
Travis
Reply all
Reply to author
Forward
0 new messages