CombinatorialFreeModules

80 views

Simon Wood

Apr 13, 2014, 9:51:02 AM4/13/14
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 Fielde=M.basis();eOutput=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:    iOutput=```

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

Apr 13, 2014, 10:54:58 AM4/13/14
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

Apr 13, 2014, 9:52:38 PM4/13/14
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.

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
> For more options, visit https://groups.google.com/d/optout.

John H Palmieri

Apr 13, 2014, 11:37:11 PM4/13/14
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

Apr 13, 2014, 11:59:23 PM4/13/14
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

Apr 14, 2014, 12:51:27 AM4/14/14
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

Apr 14, 2014, 12:52:51 AM4/14/14
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

Apr 14, 2014, 1:20:44 AM4/14/14
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
`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])]`