#18756: Use cython and coercion for CombinatorialFreeModule
-------------------------------------------------+-------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.8
Component: algebra | Resolution:
Keywords: CombinatorialFreeModule, | Merged in:
cython, coercion | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Comment (by SimonKing):
Replying to [comment:2 nthiery]:
> +1 on cythonizing CombinatorialFreeModuleElement (but not
CombinatorialFreeModule unless there is a compelling reason)
I was talking about cythoning the elements and the helper functions. I
plan to turn `CombinatorialFreeModule` into a Python class in a cython
file (i.e., keeping parent and element in one file), which means that some
generic code in the methods of `CombinatorialFreeModule` would become
faster. But the class would NOT be cdef.
> ok on inheriting from ModuleElement.
>
> -1 on inheriting from RingElement. It's too much of an abuse.
I disagree. Actually I believe the current structure is an abuse.
- `ELement` uses `_acted_on_/_acted_upon_` to implement actions. It has no
`_lmul_`, which means that the comment "for backward compatibility" fails
entirely.
- `ModuleElement` provides the infrastructure for both general actions
(inherited from `Element`) and a special path for scalar multiplication
(`_lmul_/_rmul_`). Problem: You can not implement a ring multiplication
when you just inherit from `ModuleElement`, since `ModuleElement.__mul__`
raises an error if both arguments belong to the same parent.
- `RingElement` provides the infrastructure for general actions, scalar
multiplication, and ring multiplication (via `_mul_`).
I have seen that people use `CombinatorialFreeModule` as a starting points
for implementing algebras. That's an abuse, since it works around the
existing infrastructure.
> Can you elaborate on the speed issue?
The old implementation of path algebras used `CombinatorialFreeModule` (by
the way: For ALGEBRAS, hence, one needs ring multiplication!). Granted, in
this case the actual spee-up comes from using special data types.
It is of course not ideal when one uses `RingElement` to implement
elements of a module. However, we must not forget that
`CombinatorialFreeModule` is applied in a wider range, not just to
implement modules but also rings.
Alternatively, one could create two base classes for elements: One
inherits from `ModuleElement`, the other from `RingElement`, and then the
`CombinatorialFreeModule.Element` attribute is assigned during
initialisation, according to whether the category is a sub-category of
`Rings()` or not.
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:4>
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.
