FreeModuleAutomorphism should not inherit from FreeModuleTensor

[mkoeppe]

It inherits _add_ and _sub_ methods that make no sense in the coercion system. These methods are guaranteed by the coercion system to get elements of the parent, and are supposed to give elements as well:

sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
sage: G = M.general_linear_group()
sage: T11 = M.tensor_module(1, 1)
sage: from sage.structure.coerce import CoercionModel
sage: cm = CoercionModel()
sage: cm.explain(G, G, operator.add)
Identical parents, arithmetic performed immediately.
Result lives in General linear group of the Rank-2 free module M over the Integer Ring
General linear group of the Rank-2 free module M over the Integer Ring

Also other operations inherited from the module are problematic because they are not type-stable. The result of operations is supposed to depend only on the parents of the operands, but:

sage: cm.explain(ZZ, G, operator.mul)
Action discovered.
    Left Integer Multiplication by Integer Ring on General linear group of the Rank-2 free module M over the Integer Ring
Result lives in General linear group of the Rank-2 free module M over the Integer Ring
General linear group of the Rank-2 free module M over the Integer Ring
sage: a = G.an_element()
sage: 2 * a
Type-(1,1) tensor on the Rank-2 free module M over the Integer Ring
sage: -a
Automorphism of the Rank-2 free module M over the Integer Ring
sage: (-1)*a
Automorphism of the Rank-2 free module M over the Integer Ring
sage: 0 *a
Automorphism of the Rank-2 free module M over the Integer Ring

(Note in particular the scary last one...)

There is already a coercion map from FreeModuleLinearGroup, sending a FreeModuleAutomorphism to the underlying tensor:

sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
sage: G = M.general_linear_group()
sage: T11 = M.tensor_module(1, 1)
sage: T11.coerce_map_from(G)
Coercion map:
  From: General linear group of the Rank-2 free module M over the Integer Ring
  To:   Free module of type-(1,1) tensors on the Rank-2 free module M over the Integer Ring
sage: _.category()
Category of elements of Set of Morphisms from General linear group of the Rank-2 free module M over the Integer Ring to Free module of type-(1,1) tensors on the Rank-2 free module M over the Integer Ring in Category of sets

This coercion can handle all of the module operations if we let it.

In this ticket, we change the relationship of FreeModuleAutomorphism and FreeModuleTensor from "is-a" to "has-a".

Making this change will also allow us to simplify FreeModuleTensor._add_ and _sub_: Currently they go through self._fmodule.tensor_from_comp() when they really should use self._new_instance.

CC: @egourgoulhon @tscrim @mjungmath

Component: linear algebra

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

[mjungmath]

comment:1

Do you have an explicit example what goes wrong here?

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,4 +1,17 @@
-It inherits `_add_` and `_sub_` methods that make no sense in the coercion system. 
+It inherits `_add_` and `_sub_` methods that make no sense in the coercion system. These methods are guaranteed by the coercion system to get elements of the parent, and are supposed to give elements as well. 
+
+Also other operations inherited from the module are problematic because they are not type-stable. The result of operations is supposed to depend only on the parents of the operands, but:
+
+```
+sage: 2 * a
+Type-(1,1) tensor on the Rank-2 free module M over the Integer Ring
+sage: -a
+Automorphism of the Rank-2 free module M over the Integer Ring
+sage: (-1)*a
+Automorphism of the Rank-2 free module M over the Integer Ring
+sage: 0 *a
+Automorphism of the Rank-2 free module M over the Integer Ring
+```
 
 (a) Instead, there should be a coercion map from `FreeModuleLinearGroup`, sending a `FreeModuleAutomorphism` to the underlying tensor.
 

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,8 +1,25 @@
-It inherits `_add_` and `_sub_` methods that make no sense in the coercion system. These methods are guaranteed by the coercion system to get elements of the parent, and are supposed to give elements as well. 
+It inherits `_add_` and `_sub_` methods that make no sense in the coercion system. These methods are guaranteed by the coercion system to get elements of the parent, and are supposed to give elements as well:
+
+```
+sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
+sage: G = M.general_linear_group()
+sage: T11 = M.tensor_module(1, 1)
+sage: from sage.structure.coerce import CoercionModel
+sage: cm = CoercionModel()
+sage: cm.explain(G, G, operator.add)
+Identical parents, arithmetic performed immediately.
+Result lives in General linear group of the Rank-2 free module M over the Integer Ring
+General linear group of the Rank-2 free module M over the Integer Ring
+```
 
 Also other operations inherited from the module are problematic because they are not type-stable. The result of operations is supposed to depend only on the parents of the operands, but:
 
 ```
+sage: cm.explain(ZZ, G, operator.mul)
+Action discovered.
+    Left Integer Multiplication by Integer Ring on General linear group of the Rank-2 free module M over the Integer Ring
+Result lives in General linear group of the Rank-2 free module M over the Integer Ring
+General linear group of the Rank-2 free module M over the Integer Ring
 sage: 2 * a
 Type-(1,1) tensor on the Rank-2 free module M over the Integer Ring
 sage: -a
@@ -12,10 +29,22 @@
 sage: 0 *a
 Automorphism of the Rank-2 free module M over the Integer Ring
 ```
+(Note in particular the scary last one...)
 
-(a) Instead, there should be a coercion map from `FreeModuleLinearGroup`, sending a `FreeModuleAutomorphism` to the underlying tensor.
+There is already a coercion map from `FreeModuleLinearGroup`, sending a `FreeModuleAutomorphism` to the underlying tensor:
 
-(b) Alternatively, + and - could be implemented as actions.
+```
+sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
+sage: G = M.general_linear_group()
+sage: T11 = M.tensor_module(1, 1)
+sage: T11.coerce_map_from(G)
+Coercion map:
+  From: General linear group of the Rank-2 free module M over the Integer Ring
+  To:   Free module of type-(1,1) tensors on the Rank-2 free module M over the Integer Ring
+sage: _.category()
+Category of elements of Set of Morphisms from General linear group of the Rank-2 free module M over the Integer Ring to Free module of type-(1,1) tensors on the Rank-2 free module M over the Integer Ring in Category of sets
+```
+This coercion can handle all of the module operations if we let it.
 
 
 Making this change will allow us to simplify `FreeModuleTensor._add_` and `_sub_`: Currently they go through `self._fmodule.tensor_from_comp()` when they really should use `self._new_instance`.

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Description changed:

--- 
+++ 
@@ -46,7 +46,9 @@
 ```
 This coercion can handle all of the module operations if we let it.
 
-
-Making this change will allow us to simplify `FreeModuleTensor._add_` and `_sub_`: Currently they go through `self._fmodule.tensor_from_comp()` when they really should use `self._new_instance`.
+In this ticket, we change the relationship of `FreeModuleAutomorphism` and `FreeModuleTensor` from "is-a" to "has-a".
 
 
+Making this change will also allow us to simplify `FreeModuleTensor._add_` and `_sub_`: Currently they go through `self._fmodule.tensor_from_comp()` when they really should use `self._new_instance`.
+
+

[mkoeppe]

Description changed:

--- 
+++ 
@@ -20,6 +20,7 @@
     Left Integer Multiplication by Integer Ring on General linear group of the Rank-2 free module M over the Integer Ring
 Result lives in General linear group of the Rank-2 free module M over the Integer Ring
 General linear group of the Rank-2 free module M over the Integer Ring
+sage: a = G.an_element()
 sage: 2 * a
 Type-(1,1) tensor on the Rank-2 free module M over the Integer Ring
 sage: -a

[egourgoulhon]

comment:7

I agree with most of the ticket description, except for

Making this change will also allow us to simplify FreeModuleTensor._add_ and _sub_: Currently they go through self._fmodule.tensor_from_comp() when they really should use self._new_instance.

Indeed, at this stage, self._fmodule.tensor_from_comp() is still required in FreeModuleTensor._add_() because it deals properly with the tensor (anti)symmetries, via the code of CompWithSym.__add__(). For instance, if t1 is a (4,0)-tensor with that is fully symmetric, and t2 is a (4,0)-tensor that is symmetric on the first two indices and antisymmetric on the last two ones, t1 + t2 is symmetric only on the first two indices, i.e. its (anti)symmetries are different from those of t1 or t2. They thus cannot be generated by self._new_instance (in the current stage).

[mkoeppe]

comment:8

Thanks, that's an important point.

[mkoeppe]

Changed author from Matthias Koeppe to none

[mkoeppe]

comment:11

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