#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 nthiery):
Replying to [comment:4 SimonKing]:
> I was talking about cythoning the elements and the helper
> functions.
Good.
> 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.
Putting `CombinatorialFreeModule` in a Cython file would mean that we
could not use the Python debugger on it and that any change would
require a recompilation. That's not necessarily a show stopper, but
this has to be weighted against the expected gains.
> 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.
It's possible that the technical implementation of the multiplication
by scalars is incorrect, and I'd be happy if you fixed that.
But CombinatorialFreeModule is -- by original design -- meant to be
used to implement both modules and algebras. And it has been used
intensively both ways. No abuse here.
> - `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_`).
Yup, the single inheritance of Cython is a very strong constraint. It
pushes us to do crap.
Now assume that we consider acceptable to inherit from `RingElement`
for non rings, why do we need `RingElement` in the first place? Could
not we just merge its features into `ModuleElement`?
> 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.
This would make things complicated for subclasses of
`CombinatorialModule` that have an Element class that inherits from
`CombinatorialFreeModuleElement`.
Now a question: what are the speed critical things that we really need
to be Cythonized? If it's just the `__mul__` methods and friends, it
would be worth experimenting with replacing their Python
implementations in the Modules/Rings/Algebras categories by Cythonized
methods (with recent versions of Cython, this is possible). Maybe this
would be sufficient.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:6>
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.
