Hi!
Dne pátek 23. února 2018 23:28:21 UTC+1 Travis Scrimshaw napsal(a):
>
>
> 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.
>
>
Thank you for clarification. I checked and they are different objects. They
just have the same _repr_ string. Probably nothing to be done about that.
> 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.
>
OK. I don't really understand the wording of the ticket. I checked the
example given there and it works and as far as I can tell it works as it
should. In my opinion, Sage should give errors when the user tries to input
something like
C.basis()[(1,0)]
I don't know enough about implementation details to see why any performance
hit there would matter. In case the speed is really needed perhaps we could
have another (private) method without the checks that would be used in
heavy calculations? Waiting few hours more for some extensive calculations
is definitely better than risking a worng output because you somewhere made
a transposition error (0, 1) -> (1, 0).
>>
>
>>
>>>
>>>>
>>>>
>>>>> 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.]
>
And right there is the problem I have. Why do I, as a user, should know
anything about the implementation details? Example of usage would bring me
a long way. (Hence I propose to create a ticket for adding more examples
into docstrings.) Perhaps even better would be to have a more descriptive
docstring for SubsetsSorted that would explain that the objects are
actually ordered tuples. Or at least that the objects are SortedSets.
>
> 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.
>
>
That's awesome! Great. It would be nicer if it worked even without the
square brackets but that's just nitpicking. More importantly -- where are
these features documented?
>
>>> 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.
>
Perhaps a topic for SageDays94?
>
>
>> 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 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().
>
>
Sorry, I don't understand. What restrictions are you talking about here?
PBW basis always exists. Is it not true that all Lie algebras in Sage have
one basis or another?
In my opinion, the object coming from pbw_basis() is much more useful and
will be used by more people than the one coming from
universal_enveloping_algebra(). 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.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
