Sage: Ticket #30373: Parent methods tensor vs. tensor_product
https://trac.sagemath.org/ticket/30373
<p>
We unify the use of the methods <code>tensor</code> vs. <code>tensor_product</code> in parent classes.
</p>
<p>
Current situation:
</p>
<p>
Category <code>ModulesWithBasis</code> provides a parent method <code>tensor</code> to construct a tensor product of modules.
</p>
<pre class="wiki">sage: C = CombinatorialFreeModule(QQ, ['x', 'y'])
sage: C.tensor(C)
Free module generated by {'x', 'y'} over Rational Field # Free module generated by {'x', 'y'} over Rational Field
</pre><p>
It is not implemented completely for <code>FreeModule</code>
</p>
<pre class="wiki">sage: V = FreeModule(QQ, 2)
sage: V.tensor(V)
AttributeError: type object 'FreeModule_ambient_field_with_category' has no attribute 'Tensor'
sage:
</pre><p>
In contrast, <code>FiniteRankFreeModule</code> (which is not in <code>ModulesWithBasis</code>) uses a parent method <code>tensor</code> to construct elements.
</p>
<pre class="wiki">sage: F.tensor((2, 2))
Type-(2,2) tensor on the 2-dimensional vector space over the Rational Field
</pre><p>
<code>FilteredVectorSpace</code> has both <code>tensor</code> (from <code>ModulesWithBasis</code>) and <code>tensor_product</code>, but only the latter works.
</p>
<pre class="wiki">sage: FV = FilteredVectorSpace(2)
sage: FV.tensor_product(FV)
QQ^4
sage: FV.tensor(FV)
AttributeError: type object 'FilteredVectorSpace_class_with_category' has no attribute 'Tensor'
</pre><p>
The same is true for <code>FreeQuadraticModule_integer_symmetric</code>:
</p>
<pre class="wiki">sage: L = IntegralLattice(Matrix(ZZ, 2, [2,1,1,-2]))
sage: L.tensor_product(L)
Lattice of degree 4 and rank 4 over Integer Ring
Standard basis
Inner product matrix:
[ 4 2 2 1]
[ 2 -4 1 -2]
[ 2 1 -4 -2]
[ 1 -2 -2 4]
sage: L.tensor(L)
AttributeError: type object 'FreeQuadraticModule_integer_symmetric_with_categor' has no attribute 'Tensor'
</pre><p>
The proposed solution in this ticket is to standardize on the method <code>tensor_product</code>, making <code>tensor</code> a deprecated alias.
</p>
<p>
<code>Modules</code> already has a <code>tensor_square</code> method, which <code>tensor_product</code> complements well.
</p>
<p>
We also add <code>tensor_power</code>.
</p>
<p>
No changes are made to the global <code>tensor</code> (unique instance of <code>TensorProductFunctor</code>).
</p>
<p>
See also: <a class="new ticket" href="https://trac.sagemath.org/ticket/18349" title="defect: One-fold tensor products: fix repr and document the behavior (new)">#18349</a>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/30373
Trac 1.1.6mkoeppeSun, 16 Aug 2020 00:39:15 GMTdescription changed
https://trac.sagemath.org/ticket/30373#comment:1
https://trac.sagemath.org/ticket/30373#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/30373?action=diff&version=1">diff</a>)
</li>
</ul>
TicketmkoeppeSun, 16 Aug 2020 00:49:45 GMTcc changed
https://trac.sagemath.org/ticket/30373#comment:2
https://trac.sagemath.org/ticket/30373#comment:2
<ul>
<li><strong>cc</strong>
<em>jhpalmieri</em> added
</li>
</ul>
TicketmkoeppeSun, 16 Aug 2020 00:51:03 GMTdescription changed
https://trac.sagemath.org/ticket/30373#comment:3
https://trac.sagemath.org/ticket/30373#comment:3
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/30373?action=diff&version=3">diff</a>)
</li>
</ul>
TicketmkoeppeSat, 05 Sep 2020 19:21:58 GMTmilestone changed
https://trac.sagemath.org/ticket/30373#comment:4
https://trac.sagemath.org/ticket/30373#comment:4
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
TicketmkoeppeSun, 29 Nov 2020 23:44:32 GMTdescription changed
https://trac.sagemath.org/ticket/30373#comment:5
https://trac.sagemath.org/ticket/30373#comment:5
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/30373?action=diff&version=5">diff</a>)
</li>
</ul>
TicketjhpalmieriWed, 20 Jan 2021 18:43:58 GMT
https://trac.sagemath.org/ticket/30373#comment:6
https://trac.sagemath.org/ticket/30373#comment:6
<p>
A few other things to think about:
</p>
<ul><li>In the first example, <code>C.tensor(C, C)</code> works as expected. In contrast, the <code>tensor</code> function doesn't take multiple inputs, but instead an iterable: <code>tensor([C,C,C])</code> instead of <code>tensor(C, C, C)</code>. I would prefer a consistent syntax.
</li><li>What about tensoring elements together? Right now the <code>tensor</code> function works on elements, although the documentation doesn't make this clear. I am happy for this to continue, but again, the syntax is different for <code>tensor([a,b,c])</code> vs. <code>a.tensor(b,c)</code>.
</li></ul>
Ticketgh-mjungmathThu, 21 Jan 2021 18:01:49 GMT
https://trac.sagemath.org/ticket/30373#comment:7
https://trac.sagemath.org/ticket/30373#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:6" title="Comment 6">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
A few other things to think about:
</p>
<ul><li>In the first example, <code>C.tensor(C, C)</code> works as expected. In contrast, the <code>tensor</code> function doesn't take multiple inputs, but instead an iterable: <code>tensor([C,C,C])</code> instead of <code>tensor(C, C, C)</code>. I would prefer a consistent syntax.
</li></ul></blockquote>
<p>
+1. I don't have a strong opinion which one we choose. Multiple inputs feels more flexible (and doesn't need an additional bracket).
</p>
<blockquote class="citation">
<ul><li>What about tensoring elements together? Right now the <code>tensor</code> function works on elements, although the documentation doesn't make this clear. I am happy for this to continue, but again, the syntax is different for <code>tensor([a,b,c])</code> vs. <code>a.tensor(b,c)</code>.
</li></ul></blockquote>
<p>
I like that behavior, too. However, it feels to me like this behavior was not intended and just works because the element provides a <code>tensor</code> method (that's probably why it's not mentioned in the documentation). From a mathematical-categorial viewpoint this behavior is anyway unexpected (functors usually do not act on objects of objects).
</p>
<p>
If we want to promote this, which I would agree with, the syntax should indeed be the same.
</p>
<p>
This might also be a good opportunity to introduce the <code>@</code> notation you have proposed in <a class="ext-link" href="https://trac.sagemath.org/ticket/30244#comment:3"><span class="icon"></span>here</a> which I really like (so +1 from my side, too).
</p>
<p>
As for <code>FiniteRankFreeModule</code>, introducing methods like <code>tensor_product</code> and <code>tensor_power</code> is readily done (I already finished the former).
</p>
<p>
So, should we split the task into several pieces, and I provide the <code>FiniteRankFreeModule</code> add-on? You just have to tell me which syntax you prefer.
</p>
TicketmkoeppeThu, 21 Jan 2021 18:10:23 GMT
https://trac.sagemath.org/ticket/30373#comment:8
https://trac.sagemath.org/ticket/30373#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This might also be a good opportunity to introduce the <code>@</code> notation you have proposed in <a class="ext-link" href="https://trac.sagemath.org/ticket/30244#comment:3"><span class="icon"></span>here</a> which I really like (so +1 from my side, too).
</p>
</blockquote>
<p>
-1 on this - as per discussion in <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/30244" title="enhancement: Use _matmul_ operator (@) for matrix multiplication, map composition, ... (needs_work)">#30244</a>, <code>@</code> should be for tensor contraction, not tensor product
</p>
Ticketgh-mjungmathThu, 21 Jan 2021 18:15:24 GMT
https://trac.sagemath.org/ticket/30373#comment:9
https://trac.sagemath.org/ticket/30373#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:8" title="Comment 8">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This might also be a good opportunity to introduce the <code>@</code> notation you have proposed in <a class="ext-link" href="https://trac.sagemath.org/ticket/30244#comment:3"><span class="icon"></span>here</a> which I really like (so +1 from my side, too).
</p>
</blockquote>
<p>
-1 on this - as per discussion in <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/30244" title="enhancement: Use _matmul_ operator (@) for matrix multiplication, map composition, ... (needs_work)">#30244</a>, <code>@</code> should be for tensor contraction, not tensor product
</p>
</blockquote>
<p>
But the idea in principle remains, doesn't it? What about <code>#</code> instead? That's already the symbol for tensor products as in <code>categories/tensor.py</code>.
</p>
<p>
Arrrg, that's commenting...
</p>
TicketmkoeppeThu, 21 Jan 2021 18:18:34 GMT
https://trac.sagemath.org/ticket/30373#comment:10
https://trac.sagemath.org/ticket/30373#comment:10
<p>
Python has only a fixed set of binary operators available. One can resort to overloading something that's rarely used otherwise. In <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/30244" title="enhancement: Use _matmul_ operator (@) for matrix multiplication, map composition, ... (needs_work)">#30244</a> I suggested <code>&</code> as a possibility, but I am not sure if it's a good idea.
</p>
Ticketgh-mjungmathThu, 21 Jan 2021 18:21:56 GMT
https://trac.sagemath.org/ticket/30373#comment:11
https://trac.sagemath.org/ticket/30373#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:10" title="Comment 10">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Python has only a fixed set of binary operators available. One can resort to overloading something that's rarely used otherwise. In <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/30244" title="enhancement: Use _matmul_ operator (@) for matrix multiplication, map composition, ... (needs_work)">#30244</a> I suggested <code>&</code> as a possibility, but I am not sure if it's a good idea.
</p>
</blockquote>
<p>
It feels rather uncanonical. But tensor products seem to be used quite frequently, so if there's no better bet...
</p>
<p>
What's your opinion on the syntax?
</p>
<p>
Should I open another ticket to provide <code>tensor_product</code>, <code>tensor_power</code> for <code>FiniteRankFreeModule</code> or just push it into here as open branch?
</p>
TicketjhpalmieriThu, 21 Jan 2021 18:50:40 GMT
https://trac.sagemath.org/ticket/30373#comment:12
https://trac.sagemath.org/ticket/30373#comment:12
<p>
We should make people use the unicode <code>⊗</code> for tensor product.
</p>
<p>
More seriously, if we can switch the syntax to <code>tensor(a,b,c,...)</code> with no extra brackets, that would be nice. I don't know if any of the tensor constructors take optional arguments, so I don't know how hard that would be to implement.
</p>
Ticketgh-mjungmathThu, 21 Jan 2021 21:15:56 GMT
https://trac.sagemath.org/ticket/30373#comment:13
https://trac.sagemath.org/ticket/30373#comment:13
<p>
I've opened a ticket for the <code>FiniteRankFreeModule</code> case: <a class="new ticket" href="https://trac.sagemath.org/ticket/31276" title="enhancement: Tensor Product Method for FiniteRankFreeModule (new)">#31276</a>.
</p>
TickettscrimFri, 22 Jan 2021 01:12:52 GMT
https://trac.sagemath.org/ticket/30373#comment:14
https://trac.sagemath.org/ticket/30373#comment:14
<p>
Multiple inputs can also be really annoying when you want to create a list dynamically as you then have to add a <code>*</code> and possibly extra parentheses. The easiest thing to do is to support both behaviors. This is simple enough to implement.
</p>
<p>
The tensor unicode would be good, except it would depend on how the Python interpreter takes that. Most likely, we would need to implement another find-replace case in the preparser to go to some overloaded infix operator such as <code>&</code>.
</p>
Ticketgh-mjungmathFri, 22 Jan 2021 23:54:28 GMT
https://trac.sagemath.org/ticket/30373#comment:15
https://trac.sagemath.org/ticket/30373#comment:15
<p>
Speaking of shortcuts for operations: what about using <code>^</code> for the wedge product? There is nothing more appropriate than that!
</p>
<p>
If that meets your approval, I'll open a ticket for this.
</p>
TicketjhpalmieriSat, 23 Jan 2021 00:02:16 GMT
https://trac.sagemath.org/ticket/30373#comment:16
https://trac.sagemath.org/ticket/30373#comment:16
<p>
I find it too easily confused with the exponentiation operator, so I would not like to see it featured prominently in doctests.
</p>
Ticketgh-mjungmathSat, 23 Jan 2021 00:22:27 GMT
https://trac.sagemath.org/ticket/30373#comment:17
https://trac.sagemath.org/ticket/30373#comment:17
<p>
So far, the <code>^</code> is not supported for exterior algebras:
</p>
<pre class="wiki">sage: M = FiniteRankFreeModule(QQ, 3)
sage: AM = M.dual_exterior_power(2)
sage: a = AM.an_element()
sage: a^2
Traceback (most recent call last)
...
TypeError: unsupported operand parent(s) for ^: '2nd exterior power of the dual of the 3-dimensional vector space over the Rational Field' and 'Integer Ring'
</pre><p>
But I agree. One would rather expect <code>a^3 == a.wedge(a).wedge(a)</code> if supported.
</p>
<p>
Mh, one minute ago, I thought it was an ingenious idea. :D
</p>
TickettscrimSat, 23 Jan 2021 05:51:19 GMT
https://trac.sagemath.org/ticket/30373#comment:18
https://trac.sagemath.org/ticket/30373#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:16" title="Comment 16">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I find it too easily confused with the exponentiation operator, so I would not like to see it featured prominently in doctests.
</p>
</blockquote>
<p>
However, I think it would be a nice syntactic sugar since <code>a ^ b</code>, for a,b in an exterior algebra, as exponentiation does not make sense.
</p>
Ticketgh-mjungmathSat, 23 Jan 2021 09:48:19 GMT
https://trac.sagemath.org/ticket/30373#comment:19
https://trac.sagemath.org/ticket/30373#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:18" title="Comment 18">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:16" title="Comment 16">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I find it too easily confused with the exponentiation operator, so I would not like to see it featured prominently in doctests.
</p>
</blockquote>
<p>
However, I think it would be a nice syntactic sugar since <code>a ^ b</code>, for a,b in an exterior algebra, as exponentiation does not make sense.
</p>
</blockquote>
<p>
How do we treat <code>^</code> with integers then? As a wedge product, this is the simple multiplication. And I still agree, that this case can easily be confused with the exponential since exponentiation is the standard behavior of Sage anywhere else.
</p>
TicketegourgoulhonSat, 23 Jan 2021 10:23:39 GMT
https://trac.sagemath.org/ticket/30373#comment:20
https://trac.sagemath.org/ticket/30373#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:12" title="Comment 12">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
We should make people use the unicode <code>⊗</code> for tensor product.
</p>
</blockquote>
<p>
A relevant ticket here: <a class="closed ticket" href="https://trac.sagemath.org/ticket/30473" title="enhancement: Unicode operators for sage.manifolds (closed: fixed)">#30473</a>
</p>
TicketegourgoulhonSat, 23 Jan 2021 10:29:55 GMT
https://trac.sagemath.org/ticket/30373#comment:21
https://trac.sagemath.org/ticket/30373#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:19" title="Comment 19">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/30373#comment:18" title="Comment 18">tscrim</a>:
</p>
<blockquote class="citation">
<p>
However, I think it would be a nice syntactic sugar since <code>a ^ b</code>, for a,b in an exterior algebra, as exponentiation does not make sense.
</p>
</blockquote>
<p>
How do we treat <code>^</code> with integers then? As a wedge product, this is the simple multiplication. And I still agree, that this case can easily be confused with the exponential since exponentiation is the standard behavior of Sage anywhere else.
</p>
</blockquote>
<p>
+1 (and IMHO <code>a^b</code> looks too far from a wedge product).
</p>
TicketmkoeppeSat, 13 Feb 2021 20:51:01 GMTmilestone changed
https://trac.sagemath.org/ticket/30373#comment:22
https://trac.sagemath.org/ticket/30373#comment:22
<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>
TicketmkoeppeMon, 19 Jul 2021 01:43:17 GMTmilestone changed
https://trac.sagemath.org/ticket/30373#comment:23
https://trac.sagemath.org/ticket/30373#comment:23
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.4</em> to <em>sage-9.5</em>
</li>
</ul>
TicketmkoeppeTue, 14 Dec 2021 02:04:49 GMTmilestone changed
https://trac.sagemath.org/ticket/30373#comment:24
https://trac.sagemath.org/ticket/30373#comment:24
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.5</em> to <em>sage-9.6</em>
</li>
</ul>
Ticket