Opened 2 years ago

Last modified 5 weeks ago

#27652 needs_review defect

parent of plethysm

Reported by: mantepse Owned by:
Priority: major Milestone: sage-9.4
Component: combinatorics Keywords:
Cc: zabrocki Merged in:
Authors: Martin Rubey Reviewers:
Report Upstream: N/A Work issues:
Branch: u/mantepse/parent_of_plethysm (Commits, GitHub, GitLab) Commit: 9280ad9c33c878b77bd607d77d2188896456f243
Dependencies: Stopgaps:

Status badges

Description


Change History (14)

comment:1 Changed 2 years ago by mantepse

  • Branch set to u/mantepse/parent_of_plethysm

comment:2 Changed 2 years ago by mantepse

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

New commits:

9280ad9make plethysm with tensor return result as element of second parent

comment:3 Changed 2 years ago by mantepse

  • Cc zabrocki added

comment:4 Changed 2 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 2 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 2 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 2 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 2 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 2 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 22 months 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 16 months ago by embray

  • Milestone changed from sage-8.9 to sage-9.1

Ticket retargeted after milestone closed

comment:12 Changed 12 months 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 7 months ago by mkoeppe

  • Milestone changed from sage-9.2 to sage-9.3

comment:14 Changed 5 weeks 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.

Note: See TracTickets for help on using tickets.