add method "tensor_factors" to tensor products

[fchapoton]

so that one can easily access them

CC: @tscrim

Component: categories

Author: Frédéric Chapoton

Branch: b81dbf0

Reviewer: Matthias Koeppe, Travis Scrimshaw

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

[fchapoton]

comment:2

meeting an unexpected issue with Schur algebras.. to be investigated

[mkoeppe]

comment:3

+            def construction(self):
...
+                return [tensor, *self._reduction[1]]

This can't possibly be correct code to be included in the category. _reduction is set by UniqueRepresentation, so it's under control of implementation classes, not the category

[fchapoton]

comment:4

Replying to @mkoeppe:

+            def construction(self):
...
+                return [tensor, *self._reduction[1]]

This can't possibly be correct code to be included in the category. _reduction is set by UniqueRepresentation, so it's under control of implementation classes, not the category

ok, right. Any better idea ? My final aim would be to have tensor products of morphisms..

[mkoeppe]

comment:5

No better idea than having CombinatorialFreeModule_Tensor.__init__ (or other implementation classes) save the info that you need

[sagetrac-git]

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

4f8adea

another try

[sagetrac-git]

Changed commit from 7fc6333 to 4f8adea

[fchapoton]

comment:7

The information seems to be stored in _sets. Let us try.

[mkoeppe]

comment:8

That's an implementation detail, so I think the method components should be @abstract_method(optional=True) in the category, and the implementation should go to CombinatorialFreeModule_Tensor

[mkoeppe]

comment:9

Also the method name is not specific enough. How about tensor_factors (this mirrors cartesian_factors, which is already in use?

[mkoeppe]

comment:10

And this can be moved to a larger category - at least to FreeModules, where it would apply to sage.tensor.modules.tensor_free_module.TensorFreeModule