Dne pátek 2. března 2018 0:08:46 UTC+1 Travis Scrimshaw napsal(a):
>
>
>
>>>
>>>> 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.
>>
>
> The reason for that is somewhere between being natural and being lazy. The
> easiest way to implement the PBW basis was to pass the prefix to the
> underlying basis indexing set and not do any string parsing and replacing
> in the subclass of CombinatorialFreeModule. I also felt it was natural as I
> outlined above.
>
>>
>>
>>> 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)]
>>
>
> Not if the basis is indexed by tuples or the indexing set that takes
> tuples as input? You then put the burden on the user and double create the
> indexing elements (or worse, you force a containment test). Also, there is
> no reason why we should force the indexing set to be a subclass of Parent
> or be a callable object.
>
>>
>> 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).
>>
>
> It is used in a tight loop (which this code can be), that can a few hours
> can actually be double the time it used to take.
>
>
>> 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.)
>>
>
> +1 Go ahead and create it. I will be happy to review it.
>
I've created #24914. I will get around to it by the end of the week. I
would appreciate pointers to where tensor() is defined and how would one
actually define an arbitrary ordering for pbw_basis.
>
>
>> 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.
>>
>
> Sometimes we need to make tradeoffs for ease of programming maintenance
> and speed. Now we can check the user input to put it into correct form, but
> IMO it is needless technical debt and wasted CPU cycles to use a more
> complicated class than Python's tuple.
>
>>
>>> 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?
>>
>
> It is in CombinatorialFreeModule_tensor. I was thinking there was an
> example in "tensor()", but there is not. We should add one to tensor().
>
>>
>>
>>>
>>>>> 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?
>>
>
> +1 <shameless plug>You should also apply for funding as a participant for
> SageDays@ICERM too.</shameless plug>
>
Will do. Thanks!
>
>>
>>>
>>>
>>>> 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 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?
>>
>
> Mathematical abstraction versus concrete computation. *Abstractly*, you
> always have a PBW basis, so *abstractly* you always have an isomorphism
> with any other class modeling a basis of the UEA. However, you may not know
> what that isomorphism is *concretely*. Hence, it is impossible to define
> a coercion between a PBW basis and a generic basis of the UEA. However, by
> attaching a pbw_basis() to any UEA (which, as I said above, is wholly
> impractical to do), you are tacitly saying there should be a way to go from
> that UEA implementation to the object returned by the pbw_basis (I would
> certainly object).
>
> Also, I believe it is possible to define a Lie algebra from an associative
> algebra that does not have a (distinguished) basis, and so this Lie algebra
> would not have a (distinguished) basis. At least, I do not believe there
> are any technical limitations to this. You can also define an object in Lie
> algebras as being a set of matrices satisfying certain conditions closed
> under commutators and not know what an explicit basis is. While it does not
> afford you much in the way of features currently, its not to say that there
> might be enough structure there to do something useful with it. There is no
> reason to limit the future.
>
>>
>> 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().
>>
>
> That is great for your applications. What if you want to look at certain
> ideals of the UEA and, say, compute its syzygy module:
>
> sage: L = lie_algebras.sl(QQ,2)
> sage: UEA = L.universal_enveloping_algebra()
> sage: e,h,f = UEA.gens()
> sage: I = UEA.ideal(e^2-h, f^2-h, side='twosided')
> sage: I.syzygy_module()
>
> Being fair, I don't know if people actually look at such things, but I
> know there are ways to compute Gröbner bases of NC ideals in Singular
> (Plural?); this was the first hit on Google "noncommutative groebner basis,
> singular"
>
>
> https://www.ricam.oeaw.ac.at/specsem/srs/groeb/download/Levandovskyy_ncgb.pdf
>
> So it might just be a matter of exposing Singular features in Sage to do
> things like quotients in NC rings, whereas it do similar computations with
> the PBW basis would require a significant amount of work currently.
>
>
OK. Now I understand the need for abstract UAE. Thank you very much for
clarification.
> 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.
> Best,
> Travis
>
>
Best regards,
Vit
--
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.
algebras.ipynb
Description: Binary data
