Add construction methods to FiniteRankFreeModule, CombinatorialFreeModule and Cartesian products

[Matthias Köppe]

(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}

[Matthias Köppe]

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

[Matthias Köppe]

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

[Matthias Köppe]

New commits:

​33d3675

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

[git]

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

​91c5645

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

[Travis Scrimshaw]

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.

[git]

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

​d1c586b	Sets.CartesianProducts: Add parent method 'construction'
​7014231	CombinatorialFreeModule: Fix UniqueRepresentation failure when category is passed
​0c8e8ad	CombinatorialFreeModule.construction: Allow the method from the category to take precedence

[Matthias Köppe]

Replying to tscrim:

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.

Yes, I see a few dozen testsuite failures (_test_construction) in sage.combinat now.

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.

Yes

[Matthias Köppe]

Help on these subclasses in sage.combinat is very welcome.

Otherwise I'd just add a lot of def construction(self): return None

[Travis Scrimshaw]

There are also a number of them in sage.algebra as well. In most cases, the "correct" thing to do would be to have their own ConstructionFunctor. Although we probably would remove a lot of redundant code if we have some generic subclass, say VectorSpaceWithBaseRing from commutative rings that takes a class and arbitrary inputs/keywords except the base ring. It would have a generic merging that would require all of the inputs/keywords to be equal. It might also be possible to pull the key to UniqueRepresentation as these additional structures as a generic implementation in CFM.

[Matthias Köppe]

For a start, I guess we can just give the None construction to all filtered modules

[Travis Scrimshaw]

True, it makes the situation no worse than before.

[git]

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

​b26e459

FilteredAlgebras, FilteredModules: No construction functor

[git]

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

​9b66cb5

AlgebrasWithBasis: Add construction

[Matthias Köppe]

Probably safer to just disable the construction for all subclasses

[git]

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

​e0ba7c6

CombinatorialFreeModule: Move method 'contruction' to subclass CombinatorialFreeModule_with_construction

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​7897a86

CombinatorialFreeModule: Move method 'contruction' to subclass CombinatorialFreeModule_with_construction

[Matthias Köppe]

Replying to tscrim:

It might also be possible to pull the key to UniqueRepresentation as these additional structures as a generic implementation in CFM.

Yes, I think a solution based on UniqueRepresentation could be a good idea.

[git]

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

​e07ac34

CombinatorialFreeModule_with_construction: Add __classcall_private__

[git]

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

​9d4d1dc

sage.combinat.all: Import CombinatorialFreeModule_with_construction as CombinatorialFreeModule

[Matthias Köppe]

sage -t --random-seed=211950378039065916298685714207807222444 doc/en/thematic_tutorials/tutorial-implementing-algebraic-structures.rst  # 1 doctest failed
sage -t --random-seed=211950378039065916298685714207807222444 doc/en/thematic_tutorials/tutorial-objects-and-classes.rst  # 1 doctest failed
sage -t --random-seed=211950378039065916298685714207807222444 sage/combinat/free_module.py  # 1 doctest failed
sage -t --random-seed=211950378039065916298685714207807222444 sage/modules/with_basis/indexed_element.pyx  # 1 doctest failed

[git]

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

​a0177f9	Update doctest outputs for new class CombinatorialFreeModule_with_construction
​96f082a	src/doc/en/thematic_tutorials/tutorial-implementing-algebraic-structures.rst: In subclassing example, import CombinatorialFreeModule

[git]

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

​1d4120b

src/sage/tensor/modules/finite_rank_free_module.py: Add construction

[git]

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

​61f3ca1

src/sage/modules/free_module.py (FreeModule): If with_basis=None, decode rank and start_index from basis_keys

[git]

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

​c9a499c

src/sage/tensor/modules/finite_rank_free_module.py (construction): Support start_index

[git]

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

​418be02

FiniteRankFreeModule.construction, VectorFunctor: Preserve/construct name, latex_name

[git]

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

​f5c8afd

src/sage/tensor/modules/ext_pow_free_module.py: No construction

[git]

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

​55606c8

src/sage/tensor/modules/tensor_free_module.py: No construction

[Matthias Köppe]

sage -t --random-seed=116536317366563428683146425021076892502 src/sage/manifolds/vector_bundle_fiber.py  # 1 doctest failed
sage -t --random-seed=116536317366563428683146425021076892502 src/sage/manifolds/differentiable/tangent_space.py  # 1 doctest failed

[git]

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

​1bb9ffa

TangentSpace, VectorBundleFiber: No construction

[git]

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

​9c299cf

src/sage/categories/pushout.py: Expand doctest

[git]

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

​2c6f7ee

src/sage/categories/pushout.py: Fix pycodestyle

[Matthias Köppe]

Tests pass, the pyright crash is unrelated; needs review

[Travis Scrimshaw]

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.

[Matthias Köppe]

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

[Travis Scrimshaw]

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).

[Matthias Köppe]

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

[Matthias Köppe]

I'm making this change now.

[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

[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

[Travis Scrimshaw]

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

[Eric Gourgoulhon]

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 ;-)

[Travis Scrimshaw]

Then let it be so.

[Matthias Köppe]

Thanks!