Add construction methods to FiniteRankFreeModule, CombinatorialFreeModule and Cartesian products

[mkoeppe]

(follow-up from #30194)

... extending sage.categories.pushout.VectorFunctor

for example:

            sage: M = FreeModule(ZZ, 4, with_basis=None, name='M')
            sage: latex(M)
            M
            sage: from sage.categories.pushout import VectorFunctor, pushout
            sage: M_QQ = pushout(M, QQ)
            sage: latex(M_QQ)
            M \otimes \Bold{Q}

CC: @tscrim @egourgoulhon @fchapoton @nthiery

Component: linear algebra

Author: Matthias Koeppe

Branch/Commit: 3f44174

Reviewer: Travis Scrimshaw

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

[mkoeppe]

Branch: u/mkoeppe/add_construction_methods_to_finiterankfreemodule_and_combinatorialfreemodule

[mkoeppe]

New commits:

9ee2a48	Create CombinatorialFreeModule if basis keys given
d08ee98	zero_vector: Handle bad input like zero_vector(3.6) before passing it to ZZ.__pow__
5d56004	FreeModule: SImplify argument handling
9116a1c	src/sage/misc/sageinspect.py: Do not use FreeModule as an example for a class instance
20b10f0	Extend VectorSpace factory in the same way
6af7fa4	Move documentation from FreeModuleFactory to FreeModule
5910876	FreeModule: Add to documentation
78d0633	More documentation

[mkoeppe]

Commit: 78d0633

[mkoeppe]

Dependencies: #30194

[mkoeppe]

comment:5

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

Changed branch from u/mkoeppe/add_construction_methods_to_finiterankfreemodule_and_combinatorialfreemodule to none

[mkoeppe]

Changed commit from 78d0633 to none

[mkoeppe]

Changed dependencies from #30194 to none

[mkoeppe]

Branch: u/mkoeppe/add_construction_methods_to_finiterankfreemodule_and_combinatorialfreemodule

[mkoeppe]

New commits:

33d3675

src/sage/categories/pushout.py (VectorFunctor): Add support for other keywords of the FreeModule constructor

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Commit: 33d3675

[sagetrac-git]

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

91c5645

src/sage/combinat/free_module.py (CombinatorialFreeModule): Add construction method

[sagetrac-git]

Changed commit from 33d3675 to 91c5645

[tscrim]

comment:13

We will need to be really careful with this because lots of classes are subclasses of CFM, where the result of construction() will become wrong if we do the generic one.

However, I am generally +1 on doing this. There is a ticket out there on implementing extension of scalars, and this would be a step towards doing that generically by being able to implement pushouts.

[sagetrac-git]

Changed commit from 9c299cf to 2c6f7ee

[mkoeppe]

comment:45

Tests pass, the pyright crash is unrelated; needs review

[tscrim]

comment:46

While the subclass for the construction version is the proper way to do it, I am not sure how much of a hassle it will create long-term once we have a more general way to do constructions for things that subclass CFM. The hack way would be

def construction(self):
    if self.__class__.__mro__[1] == CombinatorialFreeModule:
         return VectorFunctor(...)
    return super().construction()

(We cannot to type(self) == CFM because of the dynamic class created from the category. There is a function or method to get this more robustly, but I don't remember offhand.) I am fairly convinced that your proposal is how we should go, but I just have this little nagging doubt.

One thing that does need to be changed is that we will have two CFM classes with (almost) identical (public) documentations. This is easy to fix by adding a class-level doc to the new class explaining the difference.

[mkoeppe]

comment:47

Another hackish way would be to assign self.construction in a __classcall_private__ method.

[tscrim]

comment:48

Replying to @mkoeppe:

Another hackish way would be to assign self.construction in a __classcall_private__ method.

Indeed, although I think that is even more of a hack since it is doing stuff non-locally (to the method).

[mkoeppe]

comment:49

I don't have an objection to using self.__class__.__base__ or something like this like you suggested. It's probably less confusing than the renaming reimport

[mkoeppe]

comment:50

I'm making this change now.

[sagetrac-git]

Changed commit from 2c6f7ee to a81428a

[sagetrac-git]

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

165e6ff	Revert "src/doc/en/thematic_tutorials/tutorial-implementing-algebraic-structures.rst: In subclassing example, import CombinatorialFreeModule"
c95e97f	Revert "Update doctest outputs for new class CombinatorialFreeModule_with_construction"
f22988f	Revert "sage.combinat.all: Import CombinatorialFreeModule_with_construction as CombinatorialFreeModule"
9a2c87e	Revert "CombinatorialFreeModule_with_construction: Add __classcall_private__"
d78a002	Revert "CombinatorialFreeModule: Move method 'contruction' to subclass CombinatorialFreeModule_with_construction"
a81428a	CombinatorialFreeModule.construction: On subclasses, return None

[sagetrac-git]

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

3f44174

src/sage/tensor/modules/finite_rank_free_module.py, src/sage/categories/pushout.py: Fix name mappings

[sagetrac-git]

Changed commit from a81428a to 3f44174

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:53

I think this is acceptable. Éric, do you have any comments?

[egourgoulhon]

comment:54

Replying to @tscrim:

I think this is acceptable. Éric, do you have any comments?

No, I don't. This is mostly beyond my knowledge, but thanks for asking ;-)

[tscrim]

comment:55

Then let it be so.

[mkoeppe]

comment:56

Thanks!

[vbraun]

Changed branch from u/mkoeppe/add_construction_methods_to_finiterankfreemodule_and_combinatorialfreemodule to 3f44174