Opened 7 years ago
Last modified 6 years ago
#15573 needs_work defect
(co)product coercion
Reported by: | elixyre | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | categories | Keywords: | |
Cc: | kdilks | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | u/elixyre/ticket/15573 (Commits) | Commit: | f54c2e9db4e546d721f97c09b33f95ef9948a801 |
Dependencies: | Stopgaps: |
Description
In a bialgebra, that is not obvious there exists *a_realization* such that implements (easily) the product and the coproduct.
So I propose a coercion method that try to find automatically a realization which has the implementation of the (co)product.
Cheers,
Jean-Baptiste Priez
Change History (13)
comment:1 Changed 7 years ago by
- Branch set to u/elixyre/ticket/15573
- Created changed from 12/23/13 14:18:16 to 12/23/13 14:18:16
- Modified changed from 12/23/13 14:18:16 to 12/23/13 14:18:16
comment:2 Changed 7 years ago by
- Commit set to 76f28279aed8534bcdfb14f8f7c7845598b3a50e
comment:3 Changed 7 years ago by
- Status changed from new to needs_review
comment:4 Changed 7 years ago by
I think whatever is returned by a_realization()
should have a (co)product/antipode/etc. methods implemented. If not, the code should call the "best" realization to do the computations in by overwriting the respective *_by_coercion()
in either the realization category or in the parent directly (sometimes [often] the change-of-basis is nontrivial as well). Although this requirement that a_realization()
has a concrete implementation of the operation methods (or it's elements) is not stated and it should be.
However, +1
that there should be a *_by_coercion()
in the most general (realization) category that defines that operation. IMO the coproduct_by_coercion()
method in this ticket should go in Coalgebras
, in which coproduct()
will need some tweaks since it seems to be assuming a basis. Similarly product_by_coercion()
is inherited from the Magmas
category and is redundant.
Best,
Travis
comment:5 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:6 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:7 follow-up: ↓ 9 Changed 7 years ago by
- Status changed from needs_review to needs_work
I experimented a bit with running a patchbot; it chose this ticket and discovered a doctest failure in hopf_algebras.py
due to an undefined name left
. Independently, Travis's comment:4 also seems to mean this needs work.
comment:8 Changed 7 years ago by
- Commit changed from 76f28279aed8534bcdfb14f8f7c7845598b3a50e to f54c2e9db4e546d721f97c09b33f95ef9948a801
comment:9 in reply to: ↑ 7 Changed 7 years ago by
- Status changed from needs_work to needs_review
I think whatever is returned by
a_realization()
should have a (co)product/antipode/etc. methods implemented.
That point is obvious if we considere algebras or coalgebras... any structure with an unique operations. But with bialgebras, moreover with Hopf algebra, one has several operations and one is may be easier to define in some basis and one other in an other one.
Replying to tscrim:
If not, the code should call the "best" realization to do the computations in by overwriting the respective
*_by_coercion()
in either the realization category or in the parent directly (sometimes [often] the change-of-basis is nontrivial as well).
That point seems could be correct if we want define code for sage developpers! My opinion is this code should be code for users! That means: I want do my research without say... to compute in a basis of my new Hopf algebra, I don't want spend my time to tell to sage... I don't have define a specific realization (a_realization
) for my operations but if I want the product go to find this basis and the coproduct this one... No! I have implement product/coproduct whatever somewhere so do it!
Then if some code add in sage seems to be slow because of that! This code should specify go to this basis.
Replying to tscrim:
However,
+1
that there should be a*_by_coercion()
in the most general (realization) category that defines that operation. IMO thecoproduct_by_coercion()
method in this ticket should go inCoalgebras
, in whichcoproduct()
will need some tweaks since it seems to be assuming a basis. Similarlyproduct_by_coercion()
is inherited from theMagmas
category and is redundant.
This code don't have to be in coalgebras or magmas because, for these structures we obviously could define one realization with the unique operation of the structure.
Replying to pbruin:
I experimented a bit with running a patchbot; it chose this ticket and discovered a doctest failure in
hopf_algebras.py
due to an undefined nameleft
.
That is fix
Replying to pbruin: Independently, Travis's comment:4 also seems to mean this needs work.
I hope I have answered to that part.
Cheers, Jean-Baptiste
comment:10 Changed 6 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:11 Changed 6 years ago by
- Status changed from needs_review to needs_work
one failing doctest, see buildbot report
comment:12 Changed 6 years ago by
- Cc kdilks added
comment:13 Changed 6 years ago by
Based on this comment in hopf_algebra.py
inside antipode_by_coercion:
# TODO: # - Use @conditionally_defined once it's in Sage, for a nicer idiom # - Do the right thing (TM): once we will have proper # overloaded operators (as in MuPAD-Combinat; see #8900), # we won't need to specify explicitly to which parent one # should coerce the input to calculate the antipode; so it # will be sufficient to put this default implementation in # HopfAlgebras.ParentMethods.
it sounds like what this ticket is attempting to achieve was originally the goal.
I think this is something worth figuring out eventually, but for the sake of actually getting later features of CHA included in Sage, I'm fine with Travis's suggestion of making a_realization
always return a product/coproduct/antipode method that's hard-coded to point to a realization where the method is actually defined, rather than having Sage automatically find a realization where the method is actually defined.
Branch pushed to git repo; I updated commit sha1. New commits:
ticket 15573