Sage: Ticket #27652: parent of plethysm
https://trac.sagemath.org/ticket/27652
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/27652
Trac 1.1.6mantepseFri, 12 Apr 2019 05:41:23 GMTbranch set
https://trac.sagemath.org/ticket/27652#comment:1
https://trac.sagemath.org/ticket/27652#comment:1
<ul>
<li><strong>branch</strong>
set to <em>u/mantepse/parent_of_plethysm</em>
</li>
</ul>
TicketmantepseFri, 12 Apr 2019 08:26:44 GMTstatus, component, type changed; author, commit set
https://trac.sagemath.org/ticket/27652#comment:2
https://trac.sagemath.org/ticket/27652#comment:2
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>component</strong>
changed from <em>PLEASE CHANGE</em> to <em>combinatorics</em>
</li>
<li><strong>author</strong>
set to <em>Martin Rubey</em>
</li>
<li><strong>type</strong>
changed from <em>PLEASE CHANGE</em> to <em>defect</em>
</li>
<li><strong>commit</strong>
set to <em>9280ad9c33c878b77bd607d77d2188896456f243</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=9280ad9c33c878b77bd607d77d2188896456f243"><span class="icon"></span>9280ad9</a></td><td><code>make plethysm with tensor return result as element of second parent</code>
</td></tr></table>
TicketmantepseMon, 15 Apr 2019 07:51:29 GMTcc set
https://trac.sagemath.org/ticket/27652#comment:3
https://trac.sagemath.org/ticket/27652#comment:3
<ul>
<li><strong>cc</strong>
<em>zabrocki</em> added
</li>
</ul>
TicketzabrockiMon, 15 Apr 2019 14:31:59 GMT
https://trac.sagemath.org/ticket/27652#comment:4
https://trac.sagemath.org/ticket/27652#comment:4
<p>
Can you explain why you would do this? It seems wrong to me.
</p>
<pre class="wiki">sage: s[2,1](p[1]+1)
s[1] + s[1, 1] + s[2] + s[2, 1]
sage: s[2,1](tensor([p[1],p[1]]))
1/3*p[1, 1, 1] # p[1, 1, 1] - 1/3*p[3] # p[3]
</pre>
TicketmantepseMon, 15 Apr 2019 15:34:58 GMT
https://trac.sagemath.org/ticket/27652#comment:5
https://trac.sagemath.org/ticket/27652#comment:5
<p>
I have two reasons:
</p>
<p>
1.) the result of plethysm with a tensor is a tensor.
</p>
<p>
2.) I have a class that inherits from <code>CombinatorialFreeModule_Tensor</code>. Essentially, it is a parent for tensor products of symmetric functions, with some extra methods. I want that plethysm with an element from this class works. It almost does, except that the result is then a tensor product, and not an element from my class.
</p>
<p>
To elaborate on 2., here is my code. (The <code>tensor_constructor</code> method works around another thing, which I think is a bug.)
</p>
<pre class="wiki">"""
sage: S = SymmetricFunctions(QQ)
sage: S.inject_shorthands()
sage: t = tensor([s[1,1], h[2]])
sage: P = TwoPositions(S.s(), S.h())
sage: x = P(t)
sage: 2*x
sage: h[2](x)
"""
def from_ch_characters(t):
P = TwoPositions(*t.parent()._sets)
return P(t)
class TwoPositionsElement(CombinatorialFreeModule_Tensor.Element):
pass
from sage.combinat.free_module import CombinatorialFreeModule_Tensor, CartesianProductWithFlattening
class TwoPositions(CombinatorialFreeModule_Tensor):
def __init__(self, *modules):
cat = HopfAlgebrasWithBasis(QQ).TensorProducts()
CombinatorialFreeModule_Tensor.__init__(self,
modules,
category = cat)
@cached_method
def tensor_constructor(self, modules):
assert(module in ModulesWithBasis(self.base_ring()) for module in modules)
# assert(tensor(modules) == self)
# a list l such that l[i] is True if modules[i] is readily a tensor product
is_tensor = [isinstance(module, CombinatorialFreeModule_Tensor) for module in modules]
# the tensor_constructor, on basis elements
result = self.monomial * CartesianProductWithFlattening(is_tensor) #.
# TODO: make this into an element of Hom( A x B, C ) when those will exist
for i in range(0, len(modules)):
result = modules[i]._module_morphism(result, position = i, codomain = self)
return result
def __repr__(self):
return "TwoPositions in %s"%(self._sets,)
Element = TwoPositionsElement
</pre>
TicketzabrockiMon, 15 Apr 2019 15:53:56 GMT
https://trac.sagemath.org/ticket/27652#comment:6
https://trac.sagemath.org/ticket/27652#comment:6
<p>
A change like this may make yours work but at the expense of breaking other's code.
</p>
<p>
This change is not consistent with other uses of plethysm. I don't think that your "1.) the result of plethysm with a tensor is a tensor" is a reason at all because the plethysm of a tensor is already a tensor. What you are doing is proposing changing the output basis. The choice of making the basis output of <code>f(g)</code> the basis that f is expressed in not arbitrary and should not be changed without fundamental reasons ("it doesn't work with my code" is not fundamental, find another way to make your code work, I am sure that there are a dozen ways of doing that without changing the behavoir of plethysm).
</p>
<blockquote class="citation">
<p>
except that the result is then a tensor product, and not an element from my class.
</p>
</blockquote>
<p>
But then you should cast the output into your class.
</p>
TicketmantepseMon, 15 Apr 2019 16:41:47 GMT
https://trac.sagemath.org/ticket/27652#comment:7
https://trac.sagemath.org/ticket/27652#comment:7
<p>
OK, no problem, although I do not understand your reasons.
</p>
<p>
Possibly I miscommunicated item 1: what I meant to say is that <code>f(g)</code> is more naturally an element of the parent of <code>g</code> than of the parent of <code>f</code>. The basis <code>f</code> is expressed in cannot possibly be a basis for <code>g</code> or <code>f(g)</code>, except when <code>f</code> and <code>g</code> are both symmetric functions (in a single alphabet, so to say).
</p>
<p>
In other words, the change of basis <code>plethysm</code> currently does is much more drastic than what I am proposing.
</p>
<p>
I agree that item 2 is not a good reason. However, I do not know an easy workaround. In particular, I do not know how to cast the output into my class, because <code>plethysm</code> is a method of symmetric functions, not of my class.
</p>
TicketzabrockiMon, 15 Apr 2019 17:00:22 GMT
https://trac.sagemath.org/ticket/27652#comment:8
https://trac.sagemath.org/ticket/27652#comment:8
<p>
In my example I showed you that the plethysm of a Schur basis element and a power basis element outputs something in the Schur basis. That is the default behavior.
</p>
<blockquote class="citation">
<p>
what I meant to say is that <code>f(g)</code> is more naturally an element of the parent of <code>g</code> than of the parent of <code>f</code>.
</p>
</blockquote>
<p>
Maybe sometimes, but not in my uses of plethysm. I might be able to be convinced, but I would examples and even then I would hesitate to make a change like this because that is not what happens for <code>f(g)</code> currently and it is likely to break users' code.
</p>
<blockquote class="citation">
<p>
In particular, I do not know how to cast the output into my class, because plethysm is a method of symmetric functions, not of my class.
</p>
</blockquote>
<p>
I think that what you are proposing is a way to <code>f(g)</code> when <code>g</code> is not a symmetric function or a tensor of symmetric functions, but instead an element of your new class. That is, you are proposing adding another case into the computation of <code>f(g)</code> : if <code>g</code> is of new class then do yet a different computation. I don't think that this requires you to change the default behavior of the computation of <code>f(g)</code> when <code>g</code> is a tensor of symmetric functions.
</p>
TicketmantepseMon, 15 Apr 2019 18:46:59 GMT
https://trac.sagemath.org/ticket/27652#comment:9
https://trac.sagemath.org/ticket/27652#comment:9
<blockquote class="citation">
<p>
Maybe sometimes, but not in my uses of plethysm.
</p>
</blockquote>
<p>
I agree that other conventions may be more convenient for other uses. Of course, I know nothing about your uses of plethysm.
</p>
<p>
In my computations, it happens frequently that the basis of the tensor product is chosen for a reason, and the basis of <code>f</code> in <code>f(g)</code> is rather arbitrary. But this is very likely only by coincidence.
</p>
<pre class="wiki">sage: s[2](tensor([s(h[2]), s(m[2])]))
s[2, 2] # s[2, 2] - s[2, 2] # s[3, 1] + s[2, 2] # s[4] + s[3, 1] # s[1, 1, 1, 1] - s[3, 1] # s[2, 1, 1] + s[3, 1] # s[2, 2] + s[4] # s[2, 2] - s[4] # s[3, 1] + s[4] # s[4]
sage: s[2](tensor([(h[2]), (m[2])]))
h[2, 2] # m[2, 2] + h[2, 2] # m[4] - h[3, 1] # m[4] + h[4] # m[4]
</pre><p>
I guess that the only real reason I have to offer is that a basis for the symmetric functions cannot possibly be a basis for a tensor power of symmetric functions. Since the result is in tensor space, I really have to choose a basis for the tensor space, and taking a power of the basis of <code>f</code> seems more arbitrary than taking the basis of <code>g</code>.
</p>
<p>
Concerning the other question: no I do not want to add another case into the computation of <code>f(g)</code>, my class for <code>g</code> is simply a tensor product of symmetric functions with some more methods. I guess it might be possible to define an action of symmetric functions on my class, but I don't know how to do that. I wonder how generic plethysm really is (I think Borger and Wieland studied that).
</p>
TicketembrayWed, 03 Jul 2019 11:37:56 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:10
https://trac.sagemath.org/ticket/27652#comment:10
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.8</em> to <em>sage-8.9</em>
</li>
</ul>
<p>
Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).
</p>
TicketembrayMon, 30 Dec 2019 14:48:17 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:11
https://trac.sagemath.org/ticket/27652#comment:11
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.9</em> to <em>sage-9.1</em>
</li>
</ul>
<p>
Ticket retargeted after milestone closed
</p>
TicketmkoeppeTue, 14 Apr 2020 19:41:51 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:12
https://trac.sagemath.org/ticket/27652#comment:12
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.1</em> to <em>sage-9.2</em>
</li>
</ul>
<p>
Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.
</p>
TicketmkoeppeSat, 05 Sep 2020 19:21:58 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:13
https://trac.sagemath.org/ticket/27652#comment:13
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
TicketmkoeppeMon, 15 Mar 2021 22:07:04 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:14
https://trac.sagemath.org/ticket/27652#comment:14
<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 00:44:56 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:15
https://trac.sagemath.org/ticket/27652#comment:15
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.4</em> to <em>sage-9.5</em>
</li>
</ul>
<p>
Setting a new milestone for this ticket based on a cursory review.
</p>
TicketmkoeppeSat, 18 Dec 2021 19:53:12 GMTmilestone changed
https://trac.sagemath.org/ticket/27652#comment:16
https://trac.sagemath.org/ticket/27652#comment:16
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.5</em> to <em>sage-9.6</em>
</li>
</ul>
<p>
Stalled in <code>needs_review</code> or <code>needs_info</code>; likely won't make it into Sage 9.5.
</p>
Ticket