Use coerce actions in the category framework

simon-king-jena commented 9 years ago

The starting point of this ticket was:

CombinatorialFreeModule

is written in Python (hence, is too slow at least for my applications),
its elements just inherit from Element and not from a more appropriate base class (ModuleElement or even better RingElement, since the former for some reason raises an error on an inner multiplication), and
it is not conforming to Sage's coercion model, which really is bad, since I have seen many people who would start with CombinatorialFreeModule when implementing new algebraic stuff.

Early in the discussion, it was found that using RingElement isn't really a solution. Instead, the aim of this ticket was broadened:

It should be possible to define a multiplication action of a parent on itself; this require changing ModuleElement.__mul__.
Instead of overriding __mul__ and _mul_ for element classes, the category framework should instead return sage.structure.coerce_actions.... to provide multiplication.
These actions can be implemented in Cython---while the categories stay in Python!

CC: @nthiery @sagetrac-sage-combinat

Component: coercion

Keywords: actions

Author: Simon King

Branch/Commit: u/SimonKing/combinatorial_free_module_cython_coercion @ a5bdbf6

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/18756

7ed8c4ca-6d56-4ae9-953a-41e42b4ed313 commented 9 years ago

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

a5bdbf6 Fix a doctest

simon-king-jena commented 9 years ago

comment:40

Meanwhile I think it is essential to ascend the MRO resp. the category hierarchy.

Rationale: The plan for #18758 is to let Magmas().parent_class provide a _get_action_ method returning a multiplicative action of self on self, while AdditiveMagmas().parent_class._get_action_ yields an additive action of self on self. Hence, in order to get a ring structure, it is essential that Parent.get_action has access to both categorical _get_action_ methods.

To be fixed (here or in #18758?) is the issue with wrongly initialised parents. By this, I mean isinstance(P, C.parent_class) and not isinstance(P, P.category().parent_class) for a proper super-category C of P.category().

One could easily work around, but this would involve a little slow-down. So, better fix the issue rather than working around!

simon-king-jena commented 9 years ago

comment:41

Got it: FormalSums(ZZ).base_extend(GF(7)) returns a wrongly initialised parent.

simon-king-jena commented 9 years ago

Dependencies: #18795

simon-king-jena commented 9 years ago

comment:43

I believe this is ready for review now. The dependency #18795 is ready, too, but isn't merged here, which I believe is the correct thing to do, or should I merge it?

Concerning the question on whether or not we should go up the mro and the categories: I think it makes sense to do it. Different algebraic structure / categories have different stories to tell about different actions. Hence, either it is requested to explicitly call "super(...)._get_action_" resp. hardcode all specific situations when implementing _get_action_, or we do the super call automatically. And I believe automatically is the more stable solution.

There remains the question if it slows down one or another computation. Do you have ideas for suitable benchmarks? They would involve lots of different parents engaged in actions, since Parent.get_action is cached and thus won't slow down when repeatedly requesting an action for always the same parents.

simon-king-jena commented 9 years ago

comment:44

simon-king-jena commented 9 years ago

Description changed:

--- 
+++ 
@@ -10,3 +10,8 @@
 - It should be possible to define a multiplication action of a parent on itself; this require changing `ModuleElement.__mul__`.
 - Instead of overriding `__mul__` and `_mul_` for element classes, the category framework should instead return `sage.structure.coerce_actions....` to provide multiplication.
 - These actions can be implemented in Cython---while the categories stay in Python!
+
+As a consequence (and that's the real aim of the ticket)
+- multiplication can still be defined by category initialisation in `Magmas()`. However, it should become faster and it should in future be easier to import the multiplication from a fast cython module.
+- The way to define an internal multiplication should be more uniform throughout Sage: One simply defines `_mul_` and initialises in `Magmas()`. Overriding `__mul__` (which in some situations was still needed) should in future be even more useless.
+- Similar statements hold for `_add_`.

simon-king-jena commented 9 years ago

Description changed:

--- 
+++ 
@@ -11,7 +11,3 @@
 - Instead of overriding `__mul__` and `_mul_` for element classes, the category framework should instead return `sage.structure.coerce_actions....` to provide multiplication.
 - These actions can be implemented in Cython---while the categories stay in Python!

-As a consequence (and that's the real aim of the ticket)
-- multiplication can still be defined by category initialisation in `Magmas()`. However, it should become faster and it should in future be easier to import the multiplication from a fast cython module.
-- The way to define an internal multiplication should be more uniform throughout Sage: One simply defines `_mul_` and initialises in `Magmas()`. Overriding `__mul__` (which in some situations was still needed) should in future be even more useless.
-- Similar statements hold for `_add_`.

simon-king-jena commented 9 years ago

comment:46

Argh! I was posting on the wrong ticket. What I wrote should go to #18758...

jdemeyer commented 8 years ago

Changed dependencies from #18795 to none

jdemeyer commented 8 years ago

comment:48

It is hard for me to understand what this ticket is really about and how #20767 would affect it.

jdemeyer commented 8 years ago

comment:49

Does not build anymore due to #20686.

jdemeyer commented 8 years ago

comment:50

Replying to @simon-king-jena:

Meanwhile I think it is essential to ascend the MRO resp. the category hierarchy.

Rationale: The plan for #18758 is to let Magmas().parent_class provide a _get_action_ method returning a multiplicative action of self on self, while AdditiveMagmas().parent_class._get_action_ yields an additive action of self on self. Hence, in order to get a ring structure, it is essential that Parent.get_action has access to both categorical _get_action_ methods.

I don't quite get why you need to manually play with the MRO. Why not use super() calls in the _get_action_ implementations (instead of returning None) for that?

simon-king-jena commented 6 years ago

comment:51

In the meantime, a lot of things have changed in sage.structure.element. Thus, it might be worthwhile to see what points raised in the ticket description are still valid, and then start from scratch addressing these points.

jdemeyer commented 6 years ago

comment:52

Indeed. Now there is much less difference between Element and the derived classes like ModuleElement.

sagemath / sage

Use coerce actions in the category framework #18756