Opened 3 years ago

# parent of plethysm

Reported by: Owned by: mantepse major sage-9.7 combinatorics zabrocki Martin Rubey N/A u/mantepse/parent_of_plethysm 9280ad9c33c878b77bd607d77d2188896456f243

### comment:1 Changed 3 years ago by mantepse

• Branch set to u/mantepse/parent_of_plethysm

### comment:2 Changed 3 years ago by mantepse

• Authors set to Martin Rubey
• Component changed from PLEASE CHANGE to combinatorics
• Status changed from new to needs_review
• Type changed from PLEASE CHANGE to defect

New commits:

 ​9280ad9 `make plethysm with tensor return result as element of second parent`

### comment:4 Changed 3 years ago by zabrocki

Can you explain why you would do this? It seems wrong to me.

```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]
```

### comment:5 Changed 3 years ago by mantepse

I have two reasons:

1.) the result of plethysm with a tensor is a tensor.

2.) I have a class that inherits from `CombinatorialFreeModule_Tensor`. 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.

To elaborate on 2., here is my code. (The `tensor_constructor` method works around another thing, which I think is a bug.)

```"""
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
```

### comment:6 Changed 3 years ago by zabrocki

A change like this may make yours work but at the expense of breaking other's code.

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 `f(g)` 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).

except that the result is then a tensor product, and not an element from my class.

But then you should cast the output into your class.

### comment:7 Changed 3 years ago by mantepse

OK, no problem, although I do not understand your reasons.

Possibly I miscommunicated item 1: what I meant to say is that `f(g)` is more naturally an element of the parent of `g` than of the parent of `f`. The basis `f` is expressed in cannot possibly be a basis for `g` or `f(g)`, except when `f` and `g` are both symmetric functions (in a single alphabet, so to say).

In other words, the change of basis `plethysm` currently does is much more drastic than what I am proposing.

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 `plethysm` is a method of symmetric functions, not of my class.

### comment:8 Changed 3 years ago by zabrocki

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.

what I meant to say is that `f(g)` is more naturally an element of the parent of `g` than of the parent of `f`.

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 `f(g)` currently and it is likely to break users' code.

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.

I think that what you are proposing is a way to `f(g)` when `g` 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 `f(g)` : if `g` 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 `f(g)` when `g` is a tensor of symmetric functions.

### comment:9 Changed 3 years ago by mantepse

Maybe sometimes, but not in my uses of plethysm.

I agree that other conventions may be more convenient for other uses. Of course, I know nothing about your uses of plethysm.

In my computations, it happens frequently that the basis of the tensor product is chosen for a reason, and the basis of `f` in `f(g)` is rather arbitrary. But this is very likely only by coincidence.

```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]
```

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 `f` seems more arbitrary than taking the basis of `g`.

Concerning the other question: no I do not want to add another case into the computation of `f(g)`, my class for `g` 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).

### comment:10 Changed 3 years ago by embray

• Milestone changed from sage-8.8 to sage-8.9

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).

### comment:11 Changed 3 years ago by embray

• Milestone changed from sage-8.9 to sage-9.1

Ticket retargeted after milestone closed

### comment:12 Changed 2 years ago by mkoeppe

• Milestone changed from sage-9.1 to sage-9.2

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.

### comment:13 Changed 2 years ago by mkoeppe

• Milestone changed from sage-9.2 to sage-9.3

### comment:14 Changed 17 months ago by mkoeppe

• Milestone changed from sage-9.3 to sage-9.4

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

### comment:15 Changed 13 months ago by mkoeppe

• Milestone changed from sage-9.4 to sage-9.5

Setting a new milestone for this ticket based on a cursory review.

### comment:16 Changed 8 months ago by mkoeppe

• Milestone changed from sage-9.5 to sage-9.6

Stalled in `needs_review` or `needs_info`; likely won't make it into Sage 9.5.

### comment:17 Changed 5 months ago by mkoeppe

• Milestone changed from sage-9.6 to sage-9.7
Note: See TracTickets for help on using tickets.