Sage: Ticket #30164: Add category FreeModules (without distinguished basis)
https://trac.sagemath.org/ticket/30164
<p>
From <code>sage.tensor.modules.finite_rank_free_module</code>:
</p>
<pre class="wiki">.. TODO::
- implement submodules
- create a FreeModules category (cf. the *TODO* statement in the
documentation of :class:`~sage.categories.modules.Modules`: *Implement
a ``FreeModules(R)`` category, when so prompted by a concrete use case*)
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/30164
Trac 1.1.6tscrimFri, 17 Jul 2020 23:37:48 GMT
https://trac.sagemath.org/ticket/30164#comment:1
https://trac.sagemath.org/ticket/30164#comment:1
<p>
I am not sure I agree with having this category. I don't see the use case why we would need this category as there are basically only one concrete implementation: an n-dimensional free module. It is not until you start selecting and manipulating bases that you start having the possibility for different concrete implementations. At least, I see better ways of doing this rather than a new category that I don't foresee having much room to expand.
</p>
TicketmkoeppeSun, 19 Jul 2020 15:01:07 GMT
https://trac.sagemath.org/ticket/30164#comment:2
https://trac.sagemath.org/ticket/30164#comment:2
<p>
Perhaps, in fact, this category should define (as an abstract method) the method <code>isomorphism_with_fixed_basis</code> proposed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/30094" title="defect: Basis-dependent isomorphism from FiniteRankFreeModule to an object in ... (closed: fixed)">#30094</a>.
</p>
TickettscrimFri, 24 Jul 2020 01:15:56 GMT
https://trac.sagemath.org/ticket/30164#comment:3
https://trac.sagemath.org/ticket/30164#comment:3
<p>
My thought is that would be better left to the concrete implementation. It almost seems like you are proposing lifting the entire concrete implementation of <code>FiniteRankFreeModule</code> to the category, at which point the category becomes the parent, rather than the abstraction of the properties you want the parent to have. I feel like that might make the code maintenance harder because the two concepts are becoming too blurred together.
</p>
TicketmkoeppeSat, 25 Jul 2020 04:36:58 GMT
https://trac.sagemath.org/ticket/30164#comment:4
https://trac.sagemath.org/ticket/30164#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:3" title="Comment 3">tscrim</a>:
</p>
<blockquote class="citation">
<p>
My thought is that would be better left to the concrete implementation. It almost seems like you are proposing lifting the entire concrete implementation of <code>FiniteRankFreeModule</code> to the category, at which point the category becomes the parent, rather than the abstraction of the properties you want the parent to have.
</p>
</blockquote>
<p>
There is certainly a subtle line that separates expectations for a category's parent/element methods from those for abstract base classes.
</p>
<p>
I would think that user-facing methods that expose a mathematical concept/theorem do belong to the category.
</p>
<p>
Concretely, an implementation detail certainly is how a basis is designated or represented. <code>FiniteRankFreeModule</code> uses a custom class for representing a basis and accepts symbols (strings) as designators for a basis. I agree that it would make maintenance harder if on the category level we tried to define this.
</p>
<p>
However, we can focus on the theorem that in a free module we can choose a basis and that therefore there exists a free module isomorphism with a free module with the same base ring and rank. And this is exactly what is expressed by the method <code>isomorphism_with_fixed_basis</code> -- without having to expose the concrete concept of a basis on the category level.
</p>
<p>
I would generalize the method from <a class="closed ticket" href="https://trac.sagemath.org/ticket/30094" title="defect: Basis-dependent isomorphism from FiniteRankFreeModule to an object in ... (closed: fixed)">#30094</a>, <code>isomorphism_with_fixed_basis(self, basis, codomain=None)</code>, so that the parameter <code>basis</code> becomes optional - and when not provided uses some basis (such as the default basis if it has been set, or like <code>some_elements</code> does, to set the default basis to something arbitrary).
</p>
<p>
The category's parent method would use the compatible signature
<code>isomorphism_with_fixed_basis(self, *, codomain=None)</code>. It would be an optional abstract method.
</p>
TickettscrimSat, 25 Jul 2020 23:08:36 GMT
https://trac.sagemath.org/ticket/30164#comment:5
https://trac.sagemath.org/ticket/30164#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:4" title="Comment 4">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:3" title="Comment 3">tscrim</a>:
</p>
<blockquote class="citation">
<p>
My thought is that would be better left to the concrete implementation. It almost seems like you are proposing lifting the entire concrete implementation of <code>FiniteRankFreeModule</code> to the category, at which point the category becomes the parent, rather than the abstraction of the properties you want the parent to have.
</p>
</blockquote>
<p>
There is certainly a subtle line that separates expectations for a category's parent/element methods from those for abstract base classes.
</p>
<p>
I would think that user-facing methods that expose a mathematical concept/theorem do belong to the category.
</p>
<p>
Concretely, an implementation detail certainly is how a basis is designated or represented. <code>FiniteRankFreeModule</code> uses a custom class for representing a basis and accepts symbols (strings) as designators for a basis. I agree that it would make maintenance harder if on the category level we tried to define this.
</p>
</blockquote>
<p>
The maintenance aspect with categories is something that I worry a bit more about. I have gotten a lot of questions asking how the category framework works with its black magic. Most of the times I point to a concrete implementation and the key methods someone needs to implement.
</p>
<p>
Additionally, abstracting free modules will not lead to a combinatorial explosion of classes involving different combinations of axioms (which is the main reason why we have this framework). We see this with <code>CombinatorialFreeModule</code>; many implementations of different objects use that implementation for the underlying module rather than the abstraction in <code>ModulesWithBasis</code>.
</p>
<blockquote class="citation">
<p>
However, we can focus on the theorem that in a free module we can choose a basis and that therefore there exists a free module isomorphism with a free module with the same base ring and rank. And this is exactly what is expressed by the method <code>isomorphism_with_fixed_basis</code> -- without having to expose the concrete concept of a basis on the category level.
</p>
<p>
I would generalize the method from <a class="closed ticket" href="https://trac.sagemath.org/ticket/30094" title="defect: Basis-dependent isomorphism from FiniteRankFreeModule to an object in ... (closed: fixed)">#30094</a>, <code>isomorphism_with_fixed_basis(self, basis, codomain=None)</code>, so that the parameter <code>basis</code> becomes optional - and when not provided uses some basis (such as the default basis if it has been set, or like <code>some_elements</code> does, to set the default basis to something arbitrary).
</p>
</blockquote>
<p>
The difference with <code>some_elements</code> would be that those elements are not a defining property of the set. Having a default basis sounds like a concrete implementation detail, and we don't want to impose a fixed semantic for <code>basis()</code>. This would lead to a conflict between <code>FiniteRankFreeModule</code> and anything in <code>ModulesWithBasis</code> (which would naturally be a subcategory of <code>FreeModules</code>).
</p>
<blockquote class="citation">
<p>
The category's parent method would use the compatible signature
<code>isomorphism_with_fixed_basis(self, *, codomain=None)</code>. It would be an optional abstract method.
</p>
</blockquote>
<p>
This feels more like code bloat to me right now. At least, I cannot think of a definitive use-case for this over having a common ABC.
</p>
TicketmkoeppeSat, 25 Jul 2020 23:23:07 GMT
https://trac.sagemath.org/ticket/30164#comment:6
https://trac.sagemath.org/ticket/30164#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:5" title="Comment 5">tscrim</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I would generalize the method from <a class="closed ticket" href="https://trac.sagemath.org/ticket/30094" title="defect: Basis-dependent isomorphism from FiniteRankFreeModule to an object in ... (closed: fixed)">#30094</a>, <code>isomorphism_with_fixed_basis(self, basis, codomain=None)</code>, so that the parameter <code>basis</code> becomes optional - and when not provided uses some basis (such as the default basis if it has been set, or like <code>some_elements</code> does, to set the default basis to something arbitrary).
</p>
</blockquote>
<p>
The difference with <code>some_elements</code> would be that those elements are not a defining property of the set. Having a default basis sounds like a concrete implementation detail, and we don't want to impose a fixed semantic for <code>basis()</code>. This would lead to a conflict between <code>FiniteRankFreeModule</code> and anything in <code>ModulesWithBasis</code> (which would naturally be a subcategory of <code>FreeModules</code>).
</p>
</blockquote>
<p>
In case it did not become clear, in my proposal I do NOT define a semantic for <code>basis()</code> at all.
</p>
TicketmkoeppeSat, 25 Jul 2020 23:34:30 GMT
https://trac.sagemath.org/ticket/30164#comment:7
https://trac.sagemath.org/ticket/30164#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:5" title="Comment 5">tscrim</a>:
</p>
<blockquote class="citation">
<p>
The maintenance aspect with categories is something that I worry a bit more about. I have gotten a lot of questions asking how the category framework works with its black magic. Most of the times I point to a concrete implementation and the key methods someone needs to implement.
</p>
</blockquote>
<p>
Could you elaborate on the maintenance aspect? This sounds to me just like a documentation problem. Would it not just suffice to add some comments to an implementation class what methods are already provided by the required category?
</p>
<blockquote class="citation">
<p>
Additionally, abstracting free modules will not lead to a combinatorial explosion of classes involving different combinations of axioms (which is the main reason why we have this framework). We see this with <code>CombinatorialFreeModule</code>; many implementations of different objects use that implementation for the underlying module rather than the abstraction in <code>ModulesWithBasis</code>.
</p>
</blockquote>
<p>
I have noticed that, but the problem is that we have multiple incomplete and incompatible implementations of linear algebra. <code>CombinatorialFreeModule</code> does not know about linear forms, <code>FiniteRankFreeModule</code> does not know about triangular morphisms, ...
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
However, we can focus on the theorem that in a free module we can choose a basis and that therefore there exists a free module isomorphism with a free module with the same base ring and rank. And this is exactly what is expressed by the method <code>isomorphism_with_fixed_basis</code> -- without having to expose the concrete concept of a basis on the category level.
</p>
<p>
I would generalize the method from <a class="closed ticket" href="https://trac.sagemath.org/ticket/30094" title="defect: Basis-dependent isomorphism from FiniteRankFreeModule to an object in ... (closed: fixed)">#30094</a>, <code>isomorphism_with_fixed_basis(self, basis, codomain=None)</code>, so that the parameter <code>basis</code> becomes optional - and when not provided uses some basis (such as the default basis if it has been set, or like <code>some_elements</code> does, to set the default basis to something arbitrary).
</p>
</blockquote>
<p>
The difference with <code>some_elements</code> would be that those elements are not a defining property of the set. Having a default basis sounds like a concrete implementation detail, and we don't want to impose a fixed semantic for <code>basis()</code>. This would lead to a conflict between <code>FiniteRankFreeModule</code> and anything in <code>ModulesWithBasis</code> (which would naturally be a subcategory of <code>FreeModules</code>).
</p>
<blockquote class="citation">
<p>
The category's parent method would use the compatible signature
<code>isomorphism_with_fixed_basis(self, *, codomain=None)</code>. It would be an optional abstract method.
</p>
</blockquote>
<p>
This feels more like code bloat to me right now. At least, I cannot think of a definitive use-case for this over having a common ABC.
</p>
</blockquote>
<p>
My immediate application is <a class="new ticket" href="https://trac.sagemath.org/ticket/30198" title="enhancement: Polyhedra in vector spaces without distinguished basis (new)">#30198</a>.
</p>
TickettscrimSun, 26 Jul 2020 02:15:57 GMT
https://trac.sagemath.org/ticket/30164#comment:8
https://trac.sagemath.org/ticket/30164#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:7" title="Comment 7">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:5" title="Comment 5">tscrim</a>:
</p>
<blockquote class="citation">
<p>
The maintenance aspect with categories is something that I worry a bit more about. I have gotten a lot of questions asking how the category framework works with its black magic. Most of the times I point to a concrete implementation and the key methods someone needs to implement.
</p>
</blockquote>
<p>
Could you elaborate on the maintenance aspect? This sounds to me just like a documentation problem. Would it not just suffice to add some comments to an implementation class what methods are already provided by the required category?
</p>
</blockquote>
<p>
For someone who doesn't know the code, if you look at an object <code>X</code>, how do you find the methods? The problem is that most of the classes in its MRO are dynamically created, so they don't exist as actual code. You also cannot easily point to specific points where to look. Generic answers are not very helpful, and there is documentation (including a number of tutorials), but it is a lot to process in one go. Now more often than not, the benefits of having the generic code outweigh the extra disassociation between the implementation and the use, but I don't see that here.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Additionally, abstracting free modules will not lead to a combinatorial explosion of classes involving different combinations of axioms (which is the main reason why we have this framework). We see this with <code>CombinatorialFreeModule</code>; many implementations of different objects use that implementation for the underlying module rather than the abstraction in <code>ModulesWithBasis</code>.
</p>
</blockquote>
<p>
I have noticed that, but the problem is that we have multiple incomplete and incompatible implementations of linear algebra. <code>CombinatorialFreeModule</code> does not know about linear forms, <code>FiniteRankFreeModule</code> does not know about triangular morphisms, ...
</p>
</blockquote>
<p>
Not all of the features should necessarily be compatible because they are designed for different purposes. Sometimes these unaoidaby require specific implementation details. That being said, there are definitely missing features that could be lifted to an ABC, which can easily handle the generality you want.
</p>
<p>
Categories are heavier objects than ABCs, which are still effective at modeling the mathematics. There are more assumptions and a bigger ecosystem to worry about. For instance, you have to make sure that you cannot have a category for <code>FreeModulesWithBasis</code> as an object in <code>ModulesWithBasis</code> is free by definition. You have to make sure there are no possible convention conflicts (cf. metric).
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
The category's parent method would use the compatible signature
<code>isomorphism_with_fixed_basis(self, *, codomain=None)</code>. It would be an optional abstract method.
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
I feel like this method needs to handle a basis parameter. If you use a <code>default_basis()</code>, then you need a method that should be named <code>basis()</code> to create a basis. Also, something with a set <code>default_basis()</code> is in <code>ModulesWithBasis</code> essentially as the default basis is a distinguished basis. Not quite, but close. You have to also be a little more careful about what can happen when the default basis changes.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
This feels more like code bloat to me right now. At least, I cannot think of a definitive use-case for this over having a common ABC.
</p>
</blockquote>
<p>
My immediate application is <a class="new ticket" href="https://trac.sagemath.org/ticket/30198" title="enhancement: Polyhedra in vector spaces without distinguished basis (new)">#30198</a>.
</p>
</blockquote>
<p>
Why would you want a category over an ABC?
</p>
TicketmkoeppeSun, 26 Jul 2020 02:23:15 GMT
https://trac.sagemath.org/ticket/30164#comment:9
https://trac.sagemath.org/ticket/30164#comment:9
<p>
Thanks a lot for your explanations.
</p>
TicketmkoeppeSun, 26 Jul 2020 02:27:27 GMT
https://trac.sagemath.org/ticket/30164#comment:10
https://trac.sagemath.org/ticket/30164#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:8" title="Comment 8">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:7" title="Comment 7">mkoeppe</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
The category's parent method would use the compatible signature
<code>isomorphism_with_fixed_basis(self, *, codomain=None)</code>. It would be an optional abstract method.
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
I feel like this method needs to handle a basis parameter. If you use a <code>default_basis()</code>, then you need a method that should be named <code>basis()</code> to create a basis. Also, something with a set <code>default_basis()</code> is in <code>ModulesWithBasis</code> essentially as the default basis is a distinguished basis. Not quite, but close. You have to also be a little more careful about what can happen when the default basis changes.
</p>
</blockquote>
<p>
I think you're missing that I want the category (or, if you will, ABC) to provide the *abstract* method so that the protocol is specified, but not provide an implementation. Thus no methods <code>basis()</code> or <code>default_basis()</code> are assumed.
</p>
TicketmkoeppeMon, 27 Jul 2020 06:10:14 GMT
https://trac.sagemath.org/ticket/30164#comment:11
https://trac.sagemath.org/ticket/30164#comment:11
<p>
In a slightly different direction: I think it should also be clarified what exactly the category <code>Modules(R).FiniteDimensional()</code> is.
</p>
TicketmkoeppeTue, 28 Jul 2020 18:25:14 GMT
https://trac.sagemath.org/ticket/30164#comment:12
https://trac.sagemath.org/ticket/30164#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30164#comment:11" title="Comment 11">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
In a slightly different direction: I think it should also be clarified what exactly the category <code>Modules(R).FiniteDimensional()</code> is.
</p>
</blockquote>
<p>
Continuing with this question on <a class="new ticket" href="https://trac.sagemath.org/ticket/30233" title="enhancement: Axioms FinitelyGenerated, FinitelyGeneratedAs.... (new)">#30233</a>
</p>
TickettscrimWed, 29 Jul 2020 01:04:32 GMT
https://trac.sagemath.org/ticket/30164#comment:13
https://trac.sagemath.org/ticket/30164#comment:13
<p>
Your proposed method <code>isomorphism_with_fixed_basis</code> would require the target object to be specified, which means a specific implementation. The other option I see would be that it just requires the image to have some fixed basis, but I don't see how that would be different than a basis implementation of the generic free module. Basically, this feels like it requires a concrete implementation.
</p>
TicketmkoeppeThu, 13 Aug 2020 17:11:30 GMTmilestone changed
https://trac.sagemath.org/ticket/30164#comment:14
https://trac.sagemath.org/ticket/30164#comment:14
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
TicketmkoeppeSat, 13 Feb 2021 20:51:01 GMTmilestone changed
https://trac.sagemath.org/ticket/30164#comment:15
https://trac.sagemath.org/ticket/30164#comment:15
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.3</em> to <em>sage-9.4</em>
</li>
</ul>
<p>
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
</p>
Ticket