Multiplication of additive semigroup elements by nonnegative integers

[nthiery]

It's natural to have the following:

                sage: E = CommutativeAdditiveMonoids().example()
                sage: e = E.an_element()
                sage: 2*e
                2*a + 6*c + 4*b + 8*d
                sage: e*3
                3*a + 9*c + 6*b + 12*d

Depends on #20767

CC: @sagetrac-sage-combinat @nathanncohen @jdemeyer

Component: categories

Work Issues: failing tests, memory usage

Branch/Commit: u/nthiery/categories/additive-semigroups-intmul-16384 @ 68d43b8

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

[kcrisman]

comment:2

Congratulations on ticket 2^14!

[nthiery]

Branch: u/nthiery/categories/additive-semigroups-intmul-16384

[nthiery]

Commit: 68d43b8

[nthiery]

Work Issues: failing tests, memory usage

[nthiery]

comment:4

The current implementation more or less works. However, given the usage of an action and the current implementation of actions, this will probably leak memory if a lot additive semigroups are temporarily constructed. There are also some failing tests.

Still, reviewing the rest can start.

---

Last 10 new commits:

54c3d67	#15801: Initialize the base ring for module homsets
aa01591	#15801: doctests for CategoryObjects.base_ring + docfix in Modules.SubcategoryMethods.base_ring
79f4766	Merge branch 'public/categories/over-a-base-ring-category-15801' of trac.sagemath.org:sage into public/categories/over-a-base-ring-category-15801
281f539	Added back in import statement as per comment.
96c631f	Merge branch 'develop' into categories/axioms-10963
b1a2aed	Trac 10963: two typo fixes to let the pdf documentation compile
c16f18b	Merge branch 'public/ticket/10963-doc-distributive' of trac.sagemath.org:sage into categories/axioms-10963
dcb11d8	Merge branch 'categories/axioms-10963' into categories/over_a_base_category-15801
15658bd	Trac 15801: fixed merge with #12630
68d43b8	16384: implement the multiplication by integers for elements of an additive semigroup, through an action

[nthiery]

Dependencies: #15801

[nthiery]

comment:6

Replying to @kcrisman:

Congratulations on ticket 2^14!

Yippee :-)

[videlec]

comment:7

Hi there,

how much time before ticket 2^15 ?

Why __mul__ and __rmul__ are implemented in the category and not in element.pyx like it is done for ModuleElement ? It is confusing and moreover, it is the kind of methods that must be fast.

Vincent

[nthiery]

comment:8

Replying to @videlec:

how much time before ticket 2^15 ?

Given the acceleration, it might not be that long :-)

Why __mul__ and __rmul__ are implemented in the category and not in element.pyx like it is done for ModuleElement ? It is confusing and moreover, it is the kind of methods that must be fast.

Because, due to the single inheritance limitation of Cython classes,
the hierarchy of element classes in element.pyx is extremely limited,
and will ever be. For example, there can be no class for elements of
an additive magma. Well, there could be one, but RingElement could not
inherit from it and from MonoidElement at the same time.

The *Element hierarchy of classes is really only there to cover a
few very common cases (elements of rings, ...) where speed can be
critical. And we should only put there those methods where speed is
critical. Note that the __mul__ method implemented there take
precedence over there counterparts in the categories.

That being said, thanks to relatively recent progress in Cython, it's
now possible to define a cython function and make it a method of a
Python class/category by assigning it there (example courtesy of
Robert Bradshaw):

%cython

import cython
@cython.binding
def foo(*args):
    print args

class A:
    x = foo
a = A()
print a.x(1, 2, 3)

With this, we still pay the price of a method call, but the execution
of the method itself is fast. We could explore the use of this for the
critical methods of categories.

Cheers,
Nicolas

[jdemeyer]

Changed dependencies from #15801 to none

[jdemeyer]

Dependencies: #20767