Sage: Ticket #30241: New implementation class FiniteRankDualFreeModule
https://trac.sagemath.org/ticket/30241
<p>
(from <a class="closed ticket" href="https://trac.sagemath.org/ticket/30169" title="defect: FiniteRankFreeModule needs __classcall__ (closed: fixed)">#30169</a>)
</p>
<p>
Currently, we have the following identifications:
</p>
<pre class="wiki">sage: M = FiniteRankFreeModule(ZZ, 3, name='M')
sage: M is M.exterior_power(1)
True
sage: M is M.tensor_module(1, 0)
True
</pre><p>
In contrast:
</p>
<pre class="wiki">sage: M.dual() is M.dual_exterior_power(1)
True
sage: M.dual() is M.tensor_module(0, 1)
False
</pre><p>
The dual is implemented twice, as a special case of both <code>TensorFreeModule</code> and <code>ExtPowerDualFreeModule</code>.
</p>
<p>
We create a separate implementation class <code>FiniteRankDualFreeModule</code> for it.
</p>
<p>
By adding <code>__classcall_private__</code> methods, we delegate the construction to the new class for the special cases.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/30241
Trac 1.1.6gh-mjungmathTue, 28 Jul 2020 18:43:51 GMT
https://trac.sagemath.org/ticket/30241#comment:1
https://trac.sagemath.org/ticket/30241#comment:1
<p>
This doesn't sound sensible to me. <code>ExtPowerDualFreeModule</code> and <code>TensorFreeModule</code> follow <em>very</em> different construction patterns. For a reason: even from the mathematical point of view, one forms and (0,1) tensors are constructed differently, though they are isomorphic.
</p>
<p>
From that perspective, the current implementation makes perfect sense. What would make more sense is implementing the isomorphism.
</p>
TicketmkoeppeTue, 28 Jul 2020 18:48:46 GMT
https://trac.sagemath.org/ticket/30241#comment:2
https://trac.sagemath.org/ticket/30241#comment:2
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:1" title="Comment 1">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This doesn't sound sensible to me. <code>ExtPowerDualFreeModule</code> and <code>TensorFreeModule</code> follow <em>very</em> different construction patterns. For a reason: mathematically, meaning very strictly speaking, one forms and (0,1) tensors are defined differently, though they are isomorphic.
</p>
</blockquote>
<p>
The same is true for <code>M.exterior_power(1)</code> and <code>M.tensor_module(1, 0)</code>, but we do have this identification.
</p>
TicketmkoeppeTue, 28 Jul 2020 18:50:42 GMT
https://trac.sagemath.org/ticket/30241#comment:3
https://trac.sagemath.org/ticket/30241#comment:3
<p>
By the way, I am adding the additional structure of the exterior powers as quotients of tensor modules in <a class="closed ticket" href="https://trac.sagemath.org/ticket/30169" title="defect: FiniteRankFreeModule needs __classcall__ (closed: fixed)">#30169</a>. Please take a look
</p>
Ticketgh-mjungmathTue, 28 Jul 2020 19:08:36 GMT
https://trac.sagemath.org/ticket/30241#comment:4
https://trac.sagemath.org/ticket/30241#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:2" title="Comment 2">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:1" title="Comment 1">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This doesn't sound sensible to me. <code>ExtPowerDualFreeModule</code> and <code>TensorFreeModule</code> follow <em>very</em> different construction patterns. For a reason: mathematically, meaning very strictly speaking, one forms and (0,1) tensors are defined differently, though they are isomorphic.
</p>
</blockquote>
<p>
The same is true for <code>M.exterior_power(1)</code> and <code>M.tensor_module(1, 0)</code>, but we do have this identification.
</p>
</blockquote>
<p>
Fair point. Then I would vote for changing this to the expected outputs rather than creating a whole new class which has no further purpose than everything that is already there. Regarding Travis <a class="ext-link" href="https://trac.sagemath.org/ticket/30169#comment:10"><span class="icon"></span>comment:10</a> this would be a convenient solution. Meaning: <code>M.exterior_power(1)</code> should return an instance of <code>ExtPowerFreeModule</code> and <code>M.tensor_module(1, 0)</code> should return an instance of <code>TensorFreeModule</code>. Then, one can implement the isomorphisms.
</p>
<p>
Either way, I agree that consistency is desirable here.
</p>
<p>
Allow me a side note: please remember that the whole manifold setup is built upon <code>FiniteRankFreeModule</code>. Modifying substatial things here might cause problems in the manifold implementation. It would be good to double check and, if absolutely necessary, make changes there, too. Henceforth, I suggest doctesting the manifold part, too.
</p>
TicketmkoeppeTue, 28 Jul 2020 19:11:50 GMT
https://trac.sagemath.org/ticket/30241#comment:5
https://trac.sagemath.org/ticket/30241#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:4" title="Comment 4">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
... a whole new class which has no further purpose than everything that is already there.
</p>
</blockquote>
<p>
Note that by creating the new class, both of the <code>ExtPowerDualFreeModule</code> and <code>TensorFreeModule</code> classes will be simplified because they no longer have to implement the special case.
</p>
TicketmkoeppeTue, 28 Jul 2020 19:14:58 GMT
https://trac.sagemath.org/ticket/30241#comment:6
https://trac.sagemath.org/ticket/30241#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:4" title="Comment 4">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
<code>M.exterior_power(1)</code> should return an instance of <code>ExtPowerFreeModule</code> and <code>M.tensor_module(1, 0)</code> should return an instance of <code>TensorFreeModule</code>.
</p>
</blockquote>
<p>
Let's see. In your opinion, what should <code>M.exterior_power(0)</code> and <code>M.dual_exterior_power(0)</code> return?
</p>
Ticketgh-mjungmathTue, 28 Jul 2020 19:19:15 GMT
https://trac.sagemath.org/ticket/30241#comment:7
https://trac.sagemath.org/ticket/30241#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:6" title="Comment 6">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:4" title="Comment 4">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
<code>M.exterior_power(1)</code> should return an instance of <code>ExtPowerFreeModule</code> and <code>M.tensor_module(1, 0)</code> should return an instance of <code>TensorFreeModule</code>.
</p>
</blockquote>
<p>
Let's see. In your opinion, what should <code>M.exterior_power(0)</code> and <code>M.dual_exterior_power(0)</code> return?
</p>
</blockquote>
<p>
Strictly speaking, they should return instances of <code>ExtPowerFreeModule</code> or <code>ExtPowerDualFreeModule</code> respectively, which are isomorphic to the base ring.
</p>
<p>
You definitely have a good point. And I totally agree that this should be unified, in either way.
</p>
<p>
But I am strictly against a new class dedicated to just one special case. At least, this is how I understand your proposal.
</p>
TicketmkoeppeTue, 28 Jul 2020 19:26:01 GMT
https://trac.sagemath.org/ticket/30241#comment:8
https://trac.sagemath.org/ticket/30241#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
I am strictly against a new class dedicated to just one special case.
</p>
</blockquote>
<p>
I'll just prepare a branch and then you can see how it simplifies things, which will make it easier to review this proposal
</p>
Ticketgh-mjungmathTue, 28 Jul 2020 19:36:18 GMT
https://trac.sagemath.org/ticket/30241#comment:9
https://trac.sagemath.org/ticket/30241#comment:9
<p>
Sure, I will take a look. Travis, what do you say?
</p>
TicketmkoeppeTue, 28 Jul 2020 19:42:28 GMT
https://trac.sagemath.org/ticket/30241#comment:10
https://trac.sagemath.org/ticket/30241#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:4" title="Comment 4">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
Allow me a side note: please remember that the whole manifold setup is built upon <code>FiniteRankFreeModule</code>. Modifying substatial things here might cause problems in the manifold implementation. It would be good to double check and, if absolutely necessary, make changes there, too. Henceforth, I suggest doctesting the manifold part, too.
</p>
</blockquote>
<p>
Thanks. Prompted by your remark, I have taken a look and I noticed that <code>VectorFieldModule</code> also has similar code. I have yet to study this code in detail (I am slowly making my way up the stack...), but it looks it has the same inconsistency between primal and dual:
</p>
<pre class="wiki">sage: M = Manifold(2, 'M')
sage: XM = M.vector_field_module()
sage: XM.tensor_module(1, 0) is XM
True
sage: XM.tensor_module(0, 1) is XM.dual()
False
</pre>
TicketmkoeppeTue, 28 Jul 2020 19:56:05 GMT
https://trac.sagemath.org/ticket/30241#comment:11
https://trac.sagemath.org/ticket/30241#comment:11
<p>
I think I have a solution that could make everyone happy.
</p>
<p>
In <a class="closed ticket" href="https://trac.sagemath.org/ticket/30169" title="defect: FiniteRankFreeModule needs __classcall__ (closed: fixed)">#30169</a>, I had implemented <code>FiniteRankDualFreeModule.__classcall_private__</code> methods that delegate to other classes and implement the identification.
</p>
<p>
But we could as well take care of all identifications in the <code>FiniteRankModule.exterior_power</code>, <code>dual_power</code>, <code>tensor_module</code> methods.
</p>
<p>
Then the class constructors <code>ExtPowerFreeModule</code> could keep the strict behavior (I would also check that the case of degree 0 is correctly implemented - I don't think it is currently).
</p>
Ticketgh-mjungmathTue, 28 Jul 2020 20:09:57 GMT
https://trac.sagemath.org/ticket/30241#comment:12
https://trac.sagemath.org/ticket/30241#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30241#comment:11" title="Comment 11">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
I think I have a solution that could make everyone happy.
</p>
<p>
In <a class="closed ticket" href="https://trac.sagemath.org/ticket/30169" title="defect: FiniteRankFreeModule needs __classcall__ (closed: fixed)">#30169</a>, I had implemented <code>FiniteRankDualFreeModule.__classcall_private__</code> methods that delegate to other classes and implement the identification.
</p>
</blockquote>
<blockquote class="citation">
<p>
But we could as well take care of all identifications in the <code>FiniteRankModule.exterior_power</code>, <code>dual_power</code>, <code>tensor_module</code> methods.
</p>
</blockquote>
<p>
This sounds much better, yes. It would also be good to leave a note in the documentation so that the user knows about these special cases and how they are treated (if not already done).
</p>
<blockquote class="citation">
<p>
Then the class constructors <code>ExtPowerFreeModule</code> could keep the strict behavior (I would also check that the case of degree 0 is correctly implemented - I don't think it is currently).
</p>
</blockquote>
<p>
I would appreciate this task. The degree zero case had already caused some troubles in the past.
</p>
TicketmkoeppeThu, 13 Aug 2020 17:11:30 GMTmilestone changed
https://trac.sagemath.org/ticket/30241#comment:13
https://trac.sagemath.org/ticket/30241#comment:13
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
Ticket