CombinatorialFreeModules

[Simon Wood]

Good day everyone,

I am trying to get to grips with CombinatorialFreeModules. The combinatorial basis I am trying to use is 3-coloured partitions. But I'm not sure how to correctly define combinatorial classes.

What I've done so far is the following:

def genThreeColouredPartitions(weight): #generates all triples of partitions with total weight equal to 'weight'
    threecolouredpart= []
    for i in range(weight+1):
        for j in range(weight-i+1):
            threecolouredpart+=[[x,y,z] for x in Partitions(i) for y in Partitions(j) for z in Partitions(weight-i-j)]
    return threecolouredpart

If I try to use these 3-coloured partitions to define a Combinatorial free module things don't work the way I expect.

M = CombinatorialFreeModule(QQbar,FiniteCombinatorialClass(genThreeColouredPartitions(2))); M

Output=

Free module generated by Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] over
Algebraic Field

e=M.basis();e

Output=
Lazy family (Term map from Combinatorial class with elements in [[[],
[], [2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1],
[]], [[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] to
Free module generated by Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]] over
Algebraic Field(i))_{i in Combinatorial class with elements in [[[], [],
[2]], [[], [], [1, 1]], [[], [1], [1]], [[], [2], []], [[], [1, 1], []],
[[1], [], [1]], [[1], [1], []], [[2], [], []], [[1, 1], [], []]]}

Why is this a lazy family and not a finite family? I do not seem to be able to iterate over the basis.

for i in e:
    i

Output=

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_sage_input_11.py", line 10, in <module>
    exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("Zm9yIGkgaW4gZToKICAgIGk="),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))
  File "", line 1, in <module>
    
  File "/tmp/tmpm0bNnU/___code___.py", line 2, in <module>
    exec compile(u'for i in e:\n    i
  File "", line 1, in <module>
    
  File "/home/sageuser/sage/local/lib/python2.7/site-packages/sage/sets/family.py", line 952, in __iter__
    yield self[i]
  File "/home/sageuser/sage/local/lib/python2.7/site-packages/sage/sets/family.py", line 968, in __getitem__
    return self.function(i)
  File "/home/sageuser/sage/local/lib/python2.7/site-packages/sage/categories/poor_man_map.py", line 125, in __call__
    return self._function(*args)
  File "/home/sageuser/sage/local/lib/python2.7/site-packages/sage/combinat/free_module.py", line 2176, in _monomial
    return self._from_dict( {index: self.base_ring().one()}, remove_zeros = False )
TypeError: unhashable type: 'list'

Can anyone tell me what I am doing wrong?

[John H Palmieri]

You ask at the end what you're doing wrong. There are at least two things: first, you should probably also post this message to sage-combinat-devel, which gets a lot more traffic. I'm cc'ing that group. Second, the very last error message is partly a clue:

   TypeError: unhashable type: 'list'

Try using tuples everywhere instead of lists. For example, you could use the line

    threecolouredpart+=tuple([tuple([x,y,z]) for x in Partitions(i) for y in Partitions(j) for z in Partitions(weight-i-j)])

in your function. Also, I'm not sure what FiniteCombinatorialClass is supposed to do for you here; if I do

    FiniteCombinatorialClass(genThreeColouredPartitions(2))

it seems to work just fine (after replacing the lists with tuples): it can tell that the basis is a FiniteFamily. If I do use FiniteCombinatorialClass, then I just see LazyFamily, the way you do.

-- 
John

[Simon Wood]

Hi John,

That was very helpful thank you! Now I can generate the basis elements
and add them up and the likes.
There are two more things things I want to do:
1) Allow the 3-coloured partitions to be any non-neg integer weight,
i.e., take the direct sum over all non-neg integer weights.
2) Define operations on the basis elements and extend them linearly to
the entire module.
I'll just keep playing around with the code and see how far I get.
Thanks again for your help.

Best,
Simon

> --
> You received this message because you are subscribed to the Google Groups
> "sage-algebra" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-algebra...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[John H Palmieri]

You might look at the code in the file

   http://trac.sagemath.org/attachment/ticket/9280/trac_9280_nomodule.patch

This is a patch (which *should* have been merged into Sage 4 years ago, but forces beyond my control have so far prevented this; don't get me started) which uses CombinatorialFreeModules to define a simple-minded version of a graded polynomial algebra, partly to illustrate the sorts of things you're talking about. In particular, it has an infinite basis which is made up of finite pieces, and it also uses the category structure in Sage to define the produce just on basis elements.

You can also browse the existing Sage code (execute for example search_src('CombinatorialFreeModule')) to see other uses of CombinatorialFreeModule. Maybe some of them will be helpful.

  John

[Simon Wood]

Thank you John. I'll give that code a spin. Graded algebras are exactly what I am interested in. The code snippet I presented in my first post was a stepping stone on the way to defining Verma modules over affine Kac-Moody algebras (which are graded as you probably know).

Anyway, I'll keep fiddling with the code. Thanks for your help.

Best,
Simon

[tsc...@ucdavis.edu]

Hey John,

A good part of that is my fault. I need to get that dependency done, or we need to switch the indexing set for the example.

Hey Simon,

You might also be interested in #14901 (http://trac.sagemath.org/ticket/14901) (which I'll rebase shortly once I fix a few things I've broken trying to refactor things). I'm hoping to get a big chunk of work on finishing that over the next few months. I'd appreciate it if you could keep me in the loop on your progress.

Best,
Travis

[tsc...@ucdavis.edu]

PS - For defining things on basis elements and extending linearly, you should look into defining the operations via the method `module_morphim()`.

[John H Palmieri]

Hi Travis,

I appreciate your trying to accept some of the blame. I'm not really convinced that much of it is really your fault, and I wasn't asking for anyone to step forward. (Not that it really matters, but ere you even involved in Sage development 4 years ago?)

Instead, I have two points: Sage could have been better 4 years ago with this code in it, and the reasons (as far as I understand them) for not merging it when it was first submitted don't really hold water. For the first point: with this particular ticket, there have been a number of times, in these newsgroups, at ask.sagemath.org, and probably in other contexts, where someone asked "how do you do X with CombinatorialFreeModule" or "what's a basic example of how to define an algebra with a distinguished basis" or ..., and rather than be able to point to this code as part of Sage, I could only refer to the patch (along with some of the existing code in categories/examples, etc.). There were probably other people with similar questions and concerns who didn't ask, and so didn't find out about this. Documentation and good examples are very important to any computer code, and certainly to Sage. So I think real damage may have been done by the slowness in merging this particular code. For the second point, I think that after I submitted the code, the response was basically, "that's good, but we really need to get some of the underlying framework in place first". In retrospect, since it has taken 4 years and may take another 4 for all I know, it would have been *much* better to merge the code first, then revise it accordingly when (or if) the underlying framework is part of Sage. Maybe future situations can be dealt with better, keeping this sort of experience in mind.

  John

[Andrew]

This is a slightly old post, but you might be interested in the PartitionTuple
class that allows arbitrary coloured partitions.

sage: PartitionTuples(3,3)[:]
[([3], [], []),
 ([2, 1], [], []),
 ([1, 1, 1], [], []),
 ([2], [1], []),
 ([1, 1], [1], []),
 ([2], [], [1]),
 ([1, 1], [], [1]),
 ([1], [2], []),
 ([1], [1, 1], []),
 ([1], [1], [1]),
 ([1], [], [2]),
 ([1], [], [1, 1]),
 ([], [3], []),
 ([], [2, 1], []),
 ([], [1, 1, 1], []),
 ([], [2], [1]),
 ([], [1, 1], [1]),
 ([], [1], [2]),
 ([], [1], [1, 1]),
 ([], [], [3]),
 ([], [], [2, 1]),
 ([], [], [1, 1, 1])]