#18756: Use coerce actions in the category framework
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.8
Component: coercion | Resolution:
Keywords: cython, coercion, | Merged in:
actions, categories | Reviewers: Travis Scrimshaw
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | a5bdbf6f85ea0d732a13ebc7d8e91dbd28c92ef0
u/SimonKing/combinatorial_free_module_cython_coercion| Stopgaps:
Dependencies: #18795 |
-------------------------------------+-------------------------------------
Description changed by SimonKing:
Old description:
> 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!
New description:
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!
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_`.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:45>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
