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 elixyre

  • 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 git

  • Commit set to 76f28279aed8534bcdfb14f8f7c7845598b3a50e

Branch pushed to git repo; I updated commit sha1. New commits:

76f2827ticket 15573

comment:3 Changed 7 years ago by elixyre

  • Status changed from new to needs_review

comment:4 Changed 7 years ago by tscrim

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 vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:6 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:7 follow-up: Changed 7 years ago by pbruin

  • 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 git

  • Commit changed from 76f28279aed8534bcdfb14f8f7c7845598b3a50e to f54c2e9db4e546d721f97c09b33f95ef9948a801

Branch pushed to git repo; I updated commit sha1. New commits:

8278242Merge branch 'CHA/prod_cop_coerc/15573' into CHA/coprod_coercion
f54c2e9Ticket 15573: fix antipode_by_coercion

comment:9 in reply to: ↑ 7 Changed 7 years ago by elixyre

  • 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 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.

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 name left.

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 vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:11 Changed 6 years ago by chapoton

  • Status changed from needs_review to needs_work

one failing doctest, see buildbot report

comment:12 Changed 6 years ago by kdilks

  • Cc kdilks added

comment:13 Changed 6 years ago by kdilks

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.

Note: See TracTickets for help on using tickets.