[sage-combinat-devel] Re: ABC
Hi Bruce,
I think that what you have is fine. Compare with:
{{{
sage: mu=Partition([3,2])
sage: type(mu)
}}}
If you try adding a method to `PathTableau`, such as with
{{{
class PathTableau(ClonableList):
@abstract_method(optional=False)
def check(self):
pass
def test(self):
print('a test')
}}}
then you will see that it is inherited:
{{{sage: c=CatalanTableau([0,1,2])
sage: c
[0, 1, 2]
sage: c.test()
}}}
On Wednesday, 13 June 2018 14:08:55 UTC+2, Bruce wrote:
>
> I am trying to implement an Abstract Base Class, but have hit something I
> don't understand.
>
> I have attached a file with a minimal example of what I am trying to do.
> There is an Element ABC PathTableau and a Parent ABC PathTableaux.
> I then inherit from these with Element CatalanTableau and Parent
> CatalanTableaux.
>
> PathTableau inherits from CloneableList so I want to do some preprocessing
> on the
> argument before creating the object. For this minimal example I have
> removed the
> methods in PathTableau.
>
> My problem is that when I run this I get:
>
> sage: c = CatalanTableau([0,1,0])
> sage: type(c)
>
>
> This is not what I want. I want c to be an instance of CatalanTableau
> and therefore to inherit the (missing) methods from PathTableau.
>
> I suspect it will only take a minor adjustment to get what I want but I
> don't
> know what that would be.
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products
On Friday, 17 February 2017 17:18:20 UTC+11, Travis Scrimshaw wrote: > > Hey Andrew, >> >> >> >> Yea, it comes from the fact that it is only a simple wrapped element and > doesn't do anything beyond forwarding the repr/latex/ascii-art outputs. I > go back and forth on whether or not to pass along some (all?) extra > methods. Probably the easiest thing to work with is the facade with the > ticket (at least if you don't care if the element belongs to this specific > parent). > There's certainly an argument for passing magic methods along but then the question is where to you stop. One possibility would be to do something like: def __getattr__(self,attr): """ Any unrecognised method calls/attributes get passed on to the wrapped element """ try: return getattr(self,attr) except AttributeError: pass try: return getattr(self.value,attr) except AttributeError: raise AttributeError, '%s has no attribute %s\n'%(self,attr) Not sure what untended consequences something like this would have. Anyway, your ticket solves my problem so thanks for that! (and my wrapped elements know their parents so a facade is fine) Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products
On Thursday, 16 February 2017 15:41:37 UTC+11, Andrew wrote: > > Thanks Travis! Obviously I didn't read the documentation well enough as I > thought `Facade` was `False` by default -- so I'd tried setting > `Facade=True` with no joy. > > Cheers, > Andrew > > Unfortunately, now it seems that I can't access the elements of the tuple directly: sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])), facade= False) sage: s=StandardTableau([[1,2],[3]]) sage: ss=tabs( (s,s) ) sage: ss[0] --- TypeError Traceback (most recent call last) in () > 1 ss[Integer(0)] TypeError: 'sage.structure.element_wrapper.ElementWrapper' object has no attribute '__getitem__' > (1)() > 1 ss[Integer(0)] On the other hand, the following works: sage: ss.value[0], ss.value[1] ([[1, 2], [3]], [[1, 2], [3]]) Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products
Thanks Travis! Obviously I didn't read the documentation well enough as I thought `Facade` was `False` by default -- so I'd tried setting `Facade=True` with no joy. Cheers, Andrew pd. I will have a look at your ticket. On Thursday, 16 February 2017 13:52:22 UTC+11, Travis Scrimshaw wrote: > > Hey Andrew, >Well, I've recently been looking at DisjointUnionEnumeratedSets (see > https://trac.sagemath.org/ticket/22382) and came across this problem. The > first issue is that DisjointUnionEnumeratedSets does not behave like an > actual facade parent like it claims to be (at least with default values). > The second is that __call__ calls a morphism, which in turn calls > _element_constructor_ and expects a subclass of element to be returned. > Thus for facade parents that want to return a tuple, this causes a problem > (see the ticket). > >Actually, looking at what you want more closely now, you want this to > be a proper parent, so just pass the facade=False. This works with the > current Sage: > > sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: > cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])), > facade=False) > sage: s = StandardTableau([[1,2],[3]]) > sage: (s,s) in tabs > True > sage: tabs((s,s)) > ([[1, 2], [3]], [[1, 2], [3]]) > > Best, > Travis > > On Wednesday, February 15, 2017 at 6:01:17 PM UTC-6, Andrew wrote: >> >> I am working with disjoint enumerated sets like the following >> >> sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: >> cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()]))) >> sage: tabs[:] >> [([[1, 2, 3]], [[1, 2, 3]]), >> ([[1, 3], [2]], [[1, 3], [2]]), >> ([[1, 3], [2]], [[1, 2], [3]]), >> ([[1, 2], [3]], [[1, 3], [2]]), >> ([[1, 2], [3]], [[1, 2], [3]]), >> ([[1], [2], [3]], [[1], [2], [3]])] >> >> I need to be able to construct elements of this set from a tuple of >> elements in the underlying sets but I can't work out a nice way to do this. >> I thought that the following would work but it doesn't: >> >> sage: s = StandardTableau([[1,2],[3]]) >> sage: (s, s) in tabs >> True >> sage: tabs( (s,s) ) >> >> --- >> NotImplementedError Traceback (most recent call >> last) >> in () >> > 1 tabs( (s,s) ) >> >> /usr/local/src/sage/src/sage/structure/parent.pyx in sage.structure. >> parent.Parent.__call__ (build/cythonized/sage/structure/parent.c:9584)() >> 934 self._element_init_pass_parent = >> guess_pass_parent(self, self._element_constructor) >> 935 except (AttributeError, AssertionError): >> --> 936 raise NotImplementedError >> 937 cdef Py_ssize_t i >> 938 cdef R = parent_c(x) >> >> NotImplementedError: >> >> One way around this is the following, but I would guess that this is far >> too inefficient to use inside an element_constructor method: >> >> sage: ss = tabs.unrank( tabs.rank( (s,s) ) ) >> sage: type(ss) >> > 'sage.sets.cartesian_product.CartesianProduct_with_category.element_class' >> > >> >> Is there a better way to do his? >> >> Andrew >> > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Constructing elements in disjoint enumerated sets that are Cartesian products
I am working with disjoint enumerated sets like the following sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()]))) sage: tabs[:] [([[1, 2, 3]], [[1, 2, 3]]), ([[1, 3], [2]], [[1, 3], [2]]), ([[1, 3], [2]], [[1, 2], [3]]), ([[1, 2], [3]], [[1, 3], [2]]), ([[1, 2], [3]], [[1, 2], [3]]), ([[1], [2], [3]], [[1], [2], [3]])] I need to be able to construct elements of this set from a tuple of elements in the underlying sets but I can't work out a nice way to do this. I thought that the following would work but it doesn't: sage: s = StandardTableau([[1,2],[3]]) sage: (s, s) in tabs True sage: tabs( (s,s) ) --- NotImplementedError Traceback (most recent call last) in () > 1 tabs( (s,s) ) /usr/local/src/sage/src/sage/structure/parent.pyx in sage.structure.parent. Parent.__call__ (build/cythonized/sage/structure/parent.c:9584)() 934 self._element_init_pass_parent = guess_pass_parent( self, self._element_constructor) 935 except (AttributeError, AssertionError): --> 936 raise NotImplementedError 937 cdef Py_ssize_t i 938 cdef R = parent_c(x) NotImplementedError: One way around this is the following, but I would guess that this is far too inefficient to use inside an element_constructor method: sage: ss = tabs.unrank( tabs.rank( (s,s) ) ) sage: type(ss) Is there a better way to do his? Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: strange convention for column words of (skew) tableaux
Hi Anne, One of the problems with tableaux is that almost every possible variation of any definition is used by some one. With this in mind we probably should implement variations whenever possible. I don't know anything about the history of this particular method (git blame might help), but I suspect that some one just copied the code from tableaux to skew tableaux. I certainly have no objection either way as I don't use this method. Andrew On Tuesday, 29 November 2016 05:41:52 UTC+11, Anne Schilling wrote: > > Hi Combinat developers, > > Who came up with these conventions: > > sage: s=Tableau([[4,5],[6,7],[7],[8]]) > sage: s.to_word_by_column() > word: 876475 > sage: s=SkewTableau([[4,5],[6,7],[7],[8]]) > sage: s.to_word_by_column() > word: 574678 > > The column word of a skew tableau is the reverse of that > of a regular tableau. I think we should make the convention > the same (using the tableau convention!!!). > > What do you think? > > Anne > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: CartanTypes
This is now https://trac.sagemath.org/ticket/20973.
Andrew
On Wednesday, 6 July 2016 22:34:00 UTC+1, Travis Scrimshaw wrote:
>
> We also should determine how we want to distinguish between (and input)
> A_{+oo} and A_{oo}, i.e., index sets of NN and ZZ. In fact, the only
> place where I really see this fundamentally breaking is the CartanMatrix
> and DynkinDiagram. All of the root/weight lattice stuff should work since
> those are based around Family and CombinatorialFreeModule (although
> roots() and friends probably won't work so well).
>
> I don't really see a problem with just implementing a subclass of
> CartanType_abstract for A_{+oo}/A_{oo} and allowing the methods to just
> raise NotImplementedError's.
>
> Best,
> Travis
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] CartanTypes
On Wednesday, 6 July 2016 16:20:12 UTC+1, Nicolas M. Thiery wrote:
>
> Dear Andrew,
>
> Currently, there is no support for `A_\infty`. This is mostly because
> most of the interesting stuff that a cartan type provides in Sage
> (e.g. the Cartan matrix, ...) is returned as a non lazy object.
>
> Could you provide a couple examples of use that you have in mind?
>
Thanks Nicolas!
At this point I only need the rank and to be able differentiate A_oo from
other types. Down the track it might be useful to have the weight and root
lattices but again I don't really need them. Mostly I'd like CartanType()
to support A_oo for compatibility with the other types that I am playing it.
>
> In the simplest form, returning a formal object with very few methods
> implemented (maybe just `is_crystalographic` and friends) would be
> straightforward: add a file type_A_infinity.py with a CartanType class
> and whatever you want inside it, and update CartanType.__call__ to use
> it as appropriate.
>
Thanks for the description of what needs to be done. I'll throw something
together and sort out the bug below.
Andrew
> >Whilst looking for this I came across the following, which I guess
> are
> >syntax errors on my part rather than bugs:
> >sage: CartanType(['A',4,1]) # works
> >['A', 4, 1]
> >sage: CartanType(['A',infinity])
> > File "", line unknown
> >^
> >SyntaxError: unexpected EOF while parsing
> >sage: CartanType(['A',-1])
> > File "", line unknown
> >^
> >SyntaxError: unexpected EOF while parsing
> >sage: CartanType(['A',0])
> >['A', 0]
>
> What's happening here is that the above does not fit within the
> standard input formats that Cartan type accepts; and then it gets
> confused and tries to parse the string in search of one of our
> shortcuts like CartanType("A3*xA2~"). Yeah, this is a bug: it should
> instead return a proper not implemented error.
>
> Cheers,
> Nicolas
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] CartanTypes
Sorry if I should post this to sage-support ...
Does CartanType currently support A_\infty? I checked the docs and it seems
not but I wanted to check because I need this. Well, actually, I only need
some very rudimentary combinatorial data from the Cartan type, that I can
easily manufacture myself, but thematically I really should index the
objects that I am playing with by the appropriate Cartan types as I am
hoping that what I am doing will work in types A^{(1)}_l, A^{(2)}_{2l},
C^{(1)}_l, D^{(2)}_l and A_\infty.
Whilst looking for this I came across the following, which I guess are
syntax errors on my part rather than bugs:
sage: CartanType(['A',4,1]) # works
['A', 4, 1]
sage: CartanType(['A',infinity])
File "", line unknown
^
SyntaxError: unexpected EOF while parsing
sage: CartanType(['A',-1])
File "", line unknown
^
SyntaxError: unexpected EOF while parsing
sage: CartanType(['A',0])
['A', 0]
Andrew
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] ClonableIntArray
Hi Travis, I want this functionality too. I tried adding: __metaclass__ = ClasscallMetaclass but this produces the error: TypeError: Error when calling the metaclass bases metaclass conflict: the metaclass of a derived class must be a (non- strict) subclass of the metaclasses of all its bases I found that using __metaclass__ = InheritComparisonClasscallMetaclass works, although I am not yet sure if I need rich comparison. Anyway, apart from this minor quibble about meta classes it seems to be working for now. Cheers, Andrew On Wednesday, 16 March 2016 02:36:31 UTC+11, Travis Scrimshaw wrote: > > Hey Andrew, > Just for reference, you do not need these lines as they are in the > Tableau code so you can call Tableau(...) directly without having to > explicitly create the parent object. > > @staticmethod > def __classcall_private__(cls, elt): > return MyParent().element_class(MyParent(), elt) > > Although considering that the metaclass has not been set to the classcall > metaclass, it should not be called. > > Best, > Travis > > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: ClonableIntArray
Hi Simon and Travis, Thanks for the explanations. I am not sure if there are that many additional use cases, but a meta meta class sounds reasonable to me:) As always the main problem is finding the right place to look in the documentation - or the right person to explain it to you. Thanks again, Andrew On Thursday, 17 March 2016 01:10:44 UTC+11, Simon King wrote: > > Hi Andrew, > > On 2016-03-16, Andrew wrote: > > I want this functionality too. I tried adding: > > > > __metaclass__ = ClasscallMetaclass > > > > but this produces the error: > > > > TypeError: Error when calling the metaclass bases > > metaclass conflict: the metaclass of a derived class must be a (non- > > strict) subclass of the metaclasses of all its bases > > That's a general problem. The point is: If a class C with a meta-class M > has several base classes B1,...,Bn with meta-classes M1,...,Mn, then > Python will give you that error unless one of the meta-classes is > a sub-class of all other meta-classes. > > By consequence, if we want to combine the features provided by the > meta-classes M, M1, M2,... then we need to explicitly create another > meta-class Mx that combines the features from the other meta-classes. > And then you have to explicitly invoke Mx for C, rather than just inherit > it from M and the meta-classes of C's base classes. > > I once tried to solve that problem, by introducing a meta-meta-class MM. > I.e., each meta-class M, M1, M2,... in Sage would be instance of MM, and > when you try to combine their features, then MM would create a common > sub-meta-class Mx of M, M1, M2, ... on the fly (i.e., what we now have > to do manually would become automatic). > > It did work. But I guess that idea is just too confusing and the use > cases (at that time) have been too few. Perhaps there are more use cases > now? > > Best regards, > Simon > > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] ClonableIntArray
Could some one please tell me ho to use ClonableIntArray? I am trying to write a new family of classes that wrap what is essentially an integer list (actually, possibly I should use an integer array but I would be happy with a list for now). As CombinatorialElement is slated for depreciation I thought that I should be a good citizen and use one of ClonableList, ClonableIntArray or ClonableArray but I can't get them to work, and the documentation doesn't provide any solace as I have not been able to find anywhere what is required (this is not to say that it isn't there, only that I haven't found it). The general framework that I want is a factory class, class MyElement(ClonableIntArray) that has a generic parent class MyParent(UniqueRepresentation,Parent): This parent will then assign the elements to various derived classes depending on the input: class MyParent_A(MyParent): pass class MyParent_B(MyParent): pass Looking at the code in tableau.py I thought that the following should get me started: from sage.structure.list_clone import ClonableIntArray from sage.structure.unique_representation import UniqueRepresentation from sage.structure.parent import Parent class MyElements(ClonableIntArray): @staticmethod def __classcall_private__(cls, elt): return MyParent().element_class(MyParent(), elt) class MyParent(UniqueRepresentation,Parent): Element=MyElements @staticmethod def __classcall_private__(cls, *args): return MyParent_A() class MyParent_A(MyParent): def __init__(self): super(MyParent_A, self).__init__(category=Sets()) but this returns the following type error: TypeError: __init__() takes at least 2 positional arguments (1 given) Probably I also want to have class MyElements_A, MyElements_B, ... that the elements are automatically assigned to, but first I need to get the basic structure working. It's a bit frustrating that I can't even get the bare classes working... Is any one able to point me in the right direction? Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: combinat.math.washington.edu
Hi William, Is it possible to access beta code and git branches from SMC? Last Year I was running calculations on the combinat server using some private git branches. Once I have brushed up the code a little I'd like to start these again. I can certainly push this code to trac but it will be a while before it is ready for review as I'll have a busy year. Andrew On Sunday, 4 January 2015 15:23:56 UTC+11, William Stein wrote: Hi, The computer combinat.math.washington.edu is down... again. Sort of. It responds to ping requests, but I can't ssh in. I suspect that not a lot of people are actively using it lately, since this is the second time it has gone down for over a week in the last 3 months, and nobody (except my student Hao Chen), seems to have noticed. I'm considering doing the following. I'll shutdown combinat completely, reformat the disk, and set it up as a node of the cloud.sagemath.com (SMC). It'll still have the amazing 64 cores and huge (192GB) RAM. However, instead of login in directly to it, people can email me to request that I move a particular SMC project to combinat. It will then have access to expanded compute resources. The advantage of this, is that it is much easier for me to maintain. In particular, SMC has automated scripts to take care of using cgroups to explicitly limit usage of compute resources by a given project, I have extensive monitoring code in place so I know when things go down, and I everything runs in virtual machines, so when there are problems I can easily fix them in a few minutes remotely. Also, it's much easier to grant fair usage to projects.As it is now with default linux on combinat, basically any user can just bring down the computer by using too much memory/disk/whatever, which is probably what happened in this case (I don't know). Thoughts? Obviously, this may be a bit slower and the max memory will be less (as things are in a VM) for specific research-level computations. However, a working computer is way better than a regularly-crashing computer, in my opinion.Also, given the weeks of downtime that nobody (except Hao) notices, maybe people aren't using combinat at all anyways, due to it being only a remote linux box. Personally, I think SMC makes using remote Linux boxes much easier. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On Saturday, 22 November 2014 12:23:31 UTC+11, Travis Scrimshaw wrote:
Something which would be benefit from having a category for Hecke algebra
representations would be methods for constructing the Grothendieck group, a
list of simples (up to isomorphism), and a canonical place to look for
constructing examples (via ``an_element()``).
Yes, this would be a nice feature.
For general representation categories, we'd have an abstract method
``representation_action()``
Currently, I have this built into the class
IwahoriHeckeAlgebraRepresentation.
This week will be a nightmare for me, so I'll try and finalise this patch
next week. I now have the general framework in place and it remains to
document and doc-test the code (always fun), to add the explicit formulas
for the different actions (corresponding to the different bases). All of
this is straightforward but will of course take longer than I expect:)
I have realised that I do have one issue that I am unsure what to do with:
I am implementing seminormal representations for the the algebras of type
G(r,1,n). As special cases these include the Iwahori-Hecke algebras
algebras, with equal parameters, of types A and B. The action of the Hecke
algebras of type A on my modules will be easy because the Hecke algebra
generator T(r) corresponds to the simple reflection (r,r+1).
Unfortunately, the action of the Hecke algebras of type B is going to be
painful because the the subalgebra T(1),...,T(n-1) is isomorphic to a
Hecke algebra of type A with the additional generator T(n) satisfying the
relation T_{n-1}T_nT_{n-1}T_n=T_nT_{n-1}T_nT_{m-1}. The generator T(n) is
conjugate to the generator that I would like to use: I would prefer the
algebra to be generated by T_0, T_1,...,T_{n-1} where
T_0T_1T_0T_1=T_1T_0T_1T_1 etc., These two presentations differ by a diagram
automorphism, but it is not entirely clear to me how T(n) acts on my
representations...perhaps this is easy, but I need to think about this.
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
I'm currently going around in circles with some CombinatorialFreeModule woes. The previous code for these alternating seminormal forms works, but in order to cope with the many variations of seminormal representations that I decided to implement working I've have had to jazz things up quite a lot. Now my basic class structure looks something like this: from sage.combinat.free_module import CombinatorialFreeModule from sage.rings.polynomial.polynomial_ring_constructor import PolynomialRing class A(CombinatorialFreeModule): def __init__(self, base_ring, basis_keys, prefix='a', **kwargs): super(A,self).__init__(base_ring, basis_keys, prefix=prefix, ** kwargs) class Element(CombinatorialFreeModule.Element): pass class B(A): def __init__(self, base_ring, basis_keys, prefix='b', **kwargs): super(B,self).__init__(base_ring, basis_keys, prefix=prefix, ** kwargs) class C(B): def __init__(self, shape, prefix='c', **kwargs): base_ring=PolynomialRing(Integers(), 'q') super(B,self).__init__(base_ring, shape.standard_tableaux(), prefix= prefix, **kwargs) This simplified code works fine. For example, sage: C(Partition([3,2])).an_element() 2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5], [2, 4 ]]] Unfortunately my real code does not work, having issues like: sage: rep=SeminormalRepresentation([2,1]); rep SeminormalRepresentation([2,1])# seems to work OK sage: rep.an_element() # try to construct an element repr(sage.algebras.iwahori_hecke_algebras. iwahori_hecke_algebra_representations.SeminormalRepresentation_with_category .element_class at 0x119a88c80) failed: AttributeError: 'SeminormalRepresentation_with_category' object has no attribute '_prefix' sage: rep(StandardTableau([[1,2],[3]])) AttributeErrorTraceback (most recent call last) ... AttributeError: 'SeminormalRepresentation_with_category' object has no attribute '_basis_keys' Does anyone have an idea of what is going wrong. Part of the issue might be all of the super calls, but I tried taking though ut and explcitly calling the previous class (they are linearly ordered), but this doesn't help. For anyone feeling masochistic, the full code is at trac:17303 http://trac.sagemath.org/ticket/17303 (it uses 6.5beta0) Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On Saturday, 22 November 2014 10:24:43 UTC+11, Nicolas M. Thiery wrote: Hi Andrew, Hmm, I haven't taken the time to think with a pen and paper, but I don't guarantee that the what the super call do is as straightforward as it ought to, given that the instance of A being initialized will end up being in a subclass A_with_category, and similarly for the others. Does it work if instead you call explicitly A.__init__ in B.__init__, and so on? Hi Nicolas, I fixed my problem so the code is working now. It is possible that there are some issues with the super calls but as far as I can tell it is working as I expect. One question that I should ask you, however, is the following. I have a suspicion that I should define a category for the Hecke algebra representations, however, I don't know what the benefits are of doing this or how to do it. Certainly the code seems to work without this (not that I have added extensive tests yet or properly implemented the mathematics), but if this is necessary, or desirable, I would like to understand what this gives me over and above having a dedicated class for Hecke algebra representations. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
I mean: without knowing something about the semantic of those methods, how do we know that: sage: x.antipode() will return an element of the algebra, and therefore the result shall be retracted back, whereas: sage: x.counit() will return an element of the ground field which needs no transformation? Ah, right, I agree (he says with a sheepish grin). Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
Another disadvantage is that, given that methods in Python are not typed, it's impossible to make a difference between methods that return an element of G or of elsewhere, and add coercions as appropriate. Hence a brute-force approach as above is likely to give out wrong results. I believe we really need to write the wrapper methods by hand. I don't believe this: gap3 is less strongly typed than python and it is possible to do this there! :) The natural way to distinguish between different bases is using their prefix -- indeed this is effectively what chevie does and Eric's manifold's code does. The good news is that there already is infrastructure for this :-) Thanks. Will try to understand:) Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On Tuesday, 11 November 2014 17:20:32 UTC+11, Travis Scrimshaw wrote: Hey Andrew, One of the things that I don't like about (my understanding of) the CombinatorialFreeModule approach to modules is that it is very hard for the (uneducated/unenlightened/unwashed) user to construct their own bases for modules: To construct a new basis you have to explicitly define it using realisations hidden deep inside the code, together with the appropriate coercion maps and I think that the average user won't be able to do this. It would be nice if this provided a mechanism for doing this. I feel that's somewhat unfair as construct *a* basis is easy, you just need to pass an indexing set. However you want to construct multiple basis, so multiple parents/classes, *and* change of basis coercions between them, the latter part is what takes the work that Sage has default mechanisms for doing so (Parent._coerce_map_from_ or Morphism.register_as_coercion). That being said, the WithRealizations framework is a way to deal with multiple but not necessarily a best basis that can be easily extended. Yet IMO it feels slightly heavy-handed because of the categories involved instead of just using ABC's (there could a reason for this that I'm not seeing). For things with a best basis, I decided to just use the main object as the global entry point with the other basis as methods, see the free algebra and it's PBW basis. This is documented in categories/with_realizations.py, but perhaps a modification/expansion as a thematic tutorial would be beneficial. In either case, the hard work still lies in the defining the COB coercions. Hi Travis, My comment wasn't intended as a criticism of the code or of anyone: it is great that Mike, Nicolas, Christian and others developed this. Nor was it meat as a complaint as I think that our general philosophy is that if you don't like something then discuss and put a patch on trac. Your second paragraph is really the point that I was making: given an existing CombinatorialFreeModule, which by definition already has at least one basis, it is hard for non-developers to define a new basis that plays well with the existing ones. For me the coercions aren't really the issue, it shouldn't be hard to streamline this and, in any case, to define a new basis for a given module you have to say how it relates to an existing basis. I have used the With Realizations framework quite a bit in my own code and, of course, in the KL-basis machinery. For people developing code I think this is very workable, but I doubt that a non-developer would get very far with it. Down the track, what I would like to see is a way of *dynamically* adding bases to a CombinatorialFreeModule without these new bases having to be part of the sage source code. For example, it is possible to do this in chevie. From my quick look at the manifold code, it seems that it allows something in this direction. When I have time I'll see if I can find a way of doing this... Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On 12/11/2014 4:26 am, Nicolas M. Thiery wrote:
Is this close enough from what you would want?
sage: F = CombinatorialFreeModule(QQ, [1,2,3])
sage: G = CombinatorialFreeModule(QQ, [4,5,6])
sage: phi = F.module_morphism(lambda i: G.monomial(i+3), codomain=G)
sage: psi = G.module_morphism(lambda i: F.monomial(i-3), codomain=F)
sage: phi.register_as_coercion()
sage: psi.register_as_coercion()
sage: F(G.an_element())
2*B[1] + 2*B[2] + 3*B[3]
sage: G(F.an_element())
2*B[4] + 2*B[5] + 3*B[6]
sage: F.an_element() + G.an_element()
4*B[1] + 4*B[2] + 6*B[3]
Hi Nicolas,
This is a good start but it is not enough: essentially the difference
between what I want and what this does is the same as the difference
between a vector space isomorphism and an A-module isomorphism. As you
pointed out, there are limitations if these objects are algebras. The same
limitations apply to modules because any interesting
CombinatorialFreeModule will come equipped with endomorphisms, actions and
other methods. I would like a mechanism for automatically transferring
these methods to the new module by implicitly invoking the coercions above.
These methods will be both module methods and module element methods and,
more generally, algebra and algebra element methods.
I don't think this this should be hard to do within the existing framework,
and the mechanism should be roughly what you have above. After all, this is
easy enough to do by hand because if F has a nice method then
sage: G(F(G.an_element()).nice_method())
transfers the method to G. The trick is to find an efficient, and seamless,
way of doing this. If F is the original CombinatorialFreeModule (with
distinguished basis), then the simplest hack would be to make __getattr__
in the class for G call the methods of F whenever they are not defined. So
something like:
def __getattr__(self, attr):
try:
return self(getattr(F(self), atttr))
except AttributeError:
pass
raise AttributeError('{} has no attribute {}\n'.format(self,attr))
The disadvantage of this approach is that it does not respect
tab-completion and documentation, so it's probably going to be better to
play some inheritance tricks.
In terms of interface, I'd like to set up something like this:
sage: G=F.new_basis([4,5,6],basis_to_new_basis=phi, new_basis_to_basis=psi
,...)
This should accept a subset of the CombinatorialFreeModule arguments (for
example, basis_keys, prefix, ...), as well as coercions to other bases for
the module. As I said I'll try and think more about this.
This would certainly be useful for me. Let me know if it is unlikely to be
useful for others.
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Left and right cells of Coxeter groups
HI Travis, I found this and I also managed to get a list of cells directly from Chevie but I haven't yet worked out how to convert this into something that sage recognises. I know that I have done this before, but I've forgotten:) Will investigate further. Andrew On Monday, 10 November 2014 17:48:56 UTC+11, Travis Scrimshaw wrote: Hey Andrew, It may not be the best name, but if you pass implementation=permutation, then it will go to the chevie implementation. This isn't explicitly mentioned in the doc (and probably should be), but the doctests testing this are marked as optional needing chevie. So I think what you need is already there. Best, Travis -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Left and right cells of Coxeter groups
OK, I have figured out how to make left cells but now the question is where to put this? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: Left and right cells of Coxeter groups
Hi Nicolas, Yes, I agree, using coxeter3 will almost certainly be much more efficient. I had a brief look at this and thought it looked two hard since I have only a fleeting interest in this:) In terms of syntax, chevie has a *LeftCells* function that returns all of the cells of the Coxeter group, together with the corresponding mu-coefficients -- this, I think, is equivalent to the information that coxeter3 returns as it sounds like coxeter3 returns the W-graph for the cell representation. In terms of the suggested syntax, I think that this is partly driven by what coxeter3 actually does. I was thinking of something like: sage: W=CoxeterGroup(A3); w=W.an_element() sage: W.left_cell( w ) # left cell containing w sage: W.left_cells() # all left cells -- as chevie's LeftCells(W) does now In particular, rather the computing the complete decomposition of the Coxeter group into a disjoint union of cells I think that it would be useful to be able to compute only the cell containing a particular element. With the implementation in chevie this isn't really an option, but it might be with coxeter3. The right cells can be obtained from the left cells just by taking inverses. It is not clear to me if we need both. As coxeter 3 and chevie both seem to return the mu-coefficients as well perhaps this information should also be returned -- it seems silly to compute it and then discard it. In fact, I was thinking about the KL cells only because I thought that I would implement the cell representations of the Hecke algebras as anther example of Iwahori-Hecke algebta representations. I was planning to do this using the implementation of the KL-bases inside sage but if the full W-Graph data was available then this would be much more efficient. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On Tuesday, 11 November 2014 01:08:08 UTC+11, Nicolas M. Thiery wrote:
On Thu, Nov 06, 2014 at 04:51:40PM -0800, Anne Schilling wrote:
Wouldn't it make most sense to use the quadratic relation
$(T_r-q)(T_r-v)=0$
since the other ones can be obtained by appropriate specialization?
I definitely vote for this as well.
This is probably the most sensible thing to do, and certainly seems to be
the consensus. Just for fun there are also degenerate and
non-degenerate forms of these representations.
I'm slightly bemused, however, because I'm fairly sure that, for the
quadratic relation (T_r-u)(T_r-v), these representations do not exist in
the literature. Consequently, I suspect that this level of generality will
never be used. There may also be a speed penalty because rational function
fields in one variable are probably more efficient than function fields in
two variables (for type B and higher this comment isn't relevant.). On the
other hand, allowing a general quadratic relation is probably the easiest
way to support the two most common forms of the quadratic relations:
(T_r-q)(T_r+1)=0 and (T_r-q)(T_r+q^{-1})=0. (Btw, the same remarks apply to
the implementation of the KL-bases in sage: what we have is more general
than you will find in the literature and it automatically works for
different quadratic relations and for arbitrary coefficient rings provided
that the KL-bases are well-defined.)
sage/combinat/root_system/hecke_algebra_representation.py
I didn't know about the HeckeAlgebraRepresentation class that is defined in
this module. I have defined a class, IwahoriHeckeAlgebraRepresentation,
that is meant to be a generic class for defining representations of an
Iwahori-Hecke algebra as CombinatorialFreeModules. The class in root_system
is mainly for affine Hecke algebras and it is quite different to what I am
doing, but even so I am slightly uneasy about introducing a new class that
has a similar name and functionality to an existing class. It seems to me
that a better name for the root_system class is
*Affine*HeckeAlgebraRepresentation,
at least this would help distinguish between the two. Perhaps this code
would also sit more naturally in the new directory
sage.algebras.iwahori_hecke_algebras? Is there a better name for my class?
Does anyone have any thoughts on this? (Particularly Anne and Nicolas as
this is their code...)
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: Left and right cells of Coxeter groups
On Tuesday, 11 November 2014 00:42:58 UTC+11, Jean Michel wrote:
You should look at the latest version of chevie
http://webusers.imj-prg.fr/~jean.michel/gap3/gap3-jm4.tar.gz
or
http://webusers.imj-prg.fr/~jean.michel/gap3/gap3-jm5.tar.gz
where I implemented the latest stuff of Meinolf Geck and Abbie Hall.
I can give the elements of the left cell containing a given element of E8
in
less than 2 minutes.
Here is an example in E7:
gapW:=CoxeterGroup(E,7);;
gap LeftCell(W,Random(W));time;
LeftCellE7: duflo=18,21,45,53 character=phi{378,14}
40
40 milliseconds!
Dear Jean,
This sounds really impressive. Perhaps it is enough to use chevie...in
which case we should update the version of chevie that ships with sage (or
os gap3 still optional?).
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Left and right cells of Coxeter groups
Am I right in thinking that sage does not (yet) know about the left, right and two-sided Kazhdan-Lusztig cells of Coxeter groups? As sage can compute Kazhdan-Lusztig polynomials I assumed that it knew about cells as well, but it doesn't seem to. Please tell me if I am missing something. Incidentally, I also noticed that we have some identity issues -- that I am sure are well known: sage: WeylGroup(A5) Weyl Group of type ['A', 5] (as a matrix group acting on the ambient space) sage: CoxeterGroup(A5) Coxeter group over Universal Cyclotomic Field with Coxeter matrix: [1 3 2 2 2] [3 1 3 2 2] [2 3 1 3 2] [2 2 3 1 3] [2 2 2 3 1] I am guessing that one of these is just wrapping code from chevie, but I haven't checked. Is there any reason not to amalgamate these two classes? Currently the CoxeterGroup code seems marginally faster but perhaps the WeylGroup classes have more functionality: sage: WeylGroup(A5).cardinality() 720 sage: CoxeterGroup(A5).cardinality() --- NotImplementedError Traceback (most recent call last) ipython-input-6-42496321af01 in module() 1 CoxeterGroup(A5).cardinality() /usr/local/src/sage/local/lib/python2.7/site-packages/sage/categories/ sets_cat.pyc in cardinality(self) 1370 NotImplementedError: unknown cardinality 1371 - 1372 raise NotImplementedError(unknown cardinality) 1373 1374 # Functorial constructions NotImplementedError: unknown cardinality Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Left and right cells of Coxeter groups
Hi Travis, Thanks for the ultra quick reply. I'm impressed that so much work being done on this as I assumed that it was all in the too hard basket. I'll have a quick look at calls and see how hard it is to wrap something around chevie's implementation. Andrew On Monday, 10 November 2014 15:43:30 UTC+11, Travis Scrimshaw wrote: Hey Andrew, Am I right in thinking that sage does not (yet) know about the left, right and two-sided Kazhdan-Lusztig cells of Coxeter groups? As sage can compute Kazhdan-Lusztig polynomials I assumed that it knew about cells as well, but it doesn't seem to. Please tell me if I am missing something. AFAIK, there's no code in Sage or ticket about cells. +1 to adding them. Incidentally, I also noticed that we have some identity issues -- that I am sure are well known: sage: WeylGroup(A5) Weyl Group of type ['A', 5] (as a matrix group acting on the ambient space) sage: CoxeterGroup(A5) Coxeter group over Universal Cyclotomic Field with Coxeter matrix: [1 3 2 2 2] [3 1 3 2 2] [2 3 1 3 2] [2 2 3 1 3] [2 2 2 3 1] I am guessing that one of these is just wrapping code from chevie, but I haven't checked. Is there any reason not to amalgamate these two classes? Currently the CoxeterGroup code seems marginally faster but perhaps the WeylGroup classes have more functionality: I implemented the current CoxeterGroup and it uses Sage's (hence gap's) matrix group code. However the WeylGroup does have more information (features) since it is considered acting on the root/weight lattice, such as reflection_to_root on elements. Combining these classes might be taken care of by http://trac.sagemath.org/ticket/15703. sage: WeylGroup(A5).cardinality() 720 sage: CoxeterGroup(A5).cardinality() --- NotImplementedError Traceback (most recent call last) ipython-input-6-42496321af01 in module() 1 CoxeterGroup(A5).cardinality() /usr/local/src/sage/local/lib/python2.7/site-packages/sage/categories/ sets_cat.pyc in cardinality(self) 1370 NotImplementedError: unknown cardinality 1371 - 1372 raise NotImplementedError(unknown cardinality) 1373 1374 # Functorial constructions NotImplementedError: unknown cardinality There's currently http://trac.sagemath.org/ticket/16630 which should fix some (all?) of these issues (and I will get to that after next week). Best, Travis -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
Dear Bruce and Travis, Thanks for your suggestions. I realised after reading your posts that a much better way to construct my coefficient ring is to start with a polynomial ring over Q(q) with n+1 indeterminants and then quotient out by a suitable ideal. This constructs the ring directly and the factorisation properties that I wanted are now automatic: sage: SeminormalRepresentation([2,2]).tau_character(1,2) 1/q*I*r3 Just a short answer for now: it's been in the TODO list for a while to have representation matrices for the Hecke algebra (there might be a ticket about this, and almost certainly a note in the road map). So progress in this direction is surely welcome, especially if this can be done uniformly for symmetric groups versus hecke algebras and type A versus generic type. Yes, you're right, this is almost certainly on the roadmap. In any case, as Nicolas and Travis are both in favour I'll try and make time to properly wrap and prettify the code, create a ticket and push it to git and trac or comments and review. I'll first have to think a little harder about the best interface.I will probably end up implementing the seminormal representations simultaneously for the symmetric groups and, more generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the end thee are all the same. By the way, this could be an occasion to make those methods of the symmetric group / hecke algebra. Something like: sage: SymmetricGroup(5).representation([3,2], seminormal) Yes this is a good idea, but now there are some questions. 1. Left modules or right modules, or both? (My current methods you can interpret as either.) 2. What is the best syntax for the action? The first question is not a big deal. For the second the following is probably the most natural answer:: sage: A=SymmetricGroupAlgebra(QQ,3) sage: rep=SeminormalRepresentation([2,1]) sage: a=A.an_element(); a 2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3] sage: r=rep.an_element(); r 2*f(1,2/3) + 2*f(1,3/2) sage: a*r # left action ??? Using a*r for the left action, and r*a for the right action, seems to be the natural syntax. Is there already a mechanism in place for doing this? I assume that there is, but I don't know it. Can some one point me in the right direction? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
``_rmul_`` and ``_lmul_`` (it's the module element (i.e., ``self``) on the right or left respectively), and (somewhat unfortunately) I think you need to also inherit from ModuleElement (or copy the ``__mul__`` method). Or is it preferred to use ``_acted_upon_`` (see in CombinatorialFreeModule)? Thanks Travis. This is what I tried before I asked yesterday but I couldn't get it to work. The issue is that there is no multiplication defined on elements in a representation. In any case I have something working using sage.categories.action.Action. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Making code for some seminormal representations faster
On Friday, 7 November 2014 03:56:16 UTC+11, Nicolas M. Thiery wrote:
This might be the occasion to add a ``cartan type'' for G(r,1,n).
Implementing these algebras properly would be painful...however,
implementing their action on a representation in terms of the natural
generators is not, which I guess is what you are suggesting.
I have realised that attaching the seminormal representations to the Hecke
algebras creates a few additional headaches that are associated with the
choice of base ring and the choice of parameters of the Iwahori-Hecke
algebra. For example, the seminormal representations are naturally defined
over Q(q), but the Hecke algebra defined over Z[q,q^-1] also acts on them
since this algebra embeds in the algebra over Q(q). Technically, however,
the seminormal representation is not a representation for the Hecke algebra
defined over Z[q,q^-1].
The question here is whether we should follow the strict mathematical
definitions and only allow the Hecke algebras with exactly the same base
ring to act or should we be more flexible? The former is easier in terms
of coding whereas the latter is more useful (but technically incorrect).
Then there are other annoyances in that the seminormal representations for
the algebras with different quadratic relations, for example
$(T_r-q)(T_r+1)=0$, $(T_r-q)(T_r+q^{-1})=0$ or $(T_r-q)(T_r+v)=0$, are all
different and, of course, there are several different flavours of
seminormal representations. Any suggestions on what we should try and
support here would be appreciated.
Another thought that occurs to me, which I don't promise to follow through
on, is that I could use the seminormal representation to define Specht
modules for these algebras over an arbitrary ring. It is possible to do
this using some specialisation tricks. I am not sure how efficient this
would be but I suspect that it would be at least as good as my
implementation of the Murphy basis in chevie
http://webusers.imj-prg.fr/~jean.michel/chevie/index.html that I wrote
for the Hecke algebras of type A.
In thinking about this it seems to me that currently there is no framework
in sage for dealing with module that has more than one natural basis. Is
this right? Of course, it is possible to define several different
CombinatoriaFreeModules and coercions between them.
So, if you think of rep as a module, this could be:
rep.action(a, r)
Then we can optionally setup the following as syntactic sugar:
a*r or r*a
I'll implement both. I have the second alternative working already,
although some necessary sanity checks relating to the questions above are
missing.
A final question: where should this code go? Currently the Iwahori-Hecke
algebras are defined in sage.algebras and the seminormal matrix
representations in sage.combinat. I think the best place might be to put
all of this code in a new directory sage.algebras.iwahoriheckeagebras/
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Making code for some seminormal representations faster
Sorry, this is a longish post...there are some questions at the end that
roughly come down to can you see how to improve my code. If you don't care
about representations of symmetric groups and Hecke algebras, or about
CombinatorialFreeModules, then you may want to stop reading now!
Some time ago Franco (and possibly others?), wrote some code for
constructing the irreducible matrix representations of the symmetric groups
in characteristic zero. Recently I have been looking at the corresponding
representations for the Hecke algebra of the symmetric group and the
questions that I am interested in relate to how these representations
restrict to the subalgebra of the Hecke algebra corresponding to the
alternating group. The easiest way to answer this question is to work with
slightly different matrix representations over slightly horrible rings
where these representations split when restricted to the alternating Hecke
algebra.
I have written some code that implements all of this in sage (see
attached). For the symmetric groups this is roughly equivalent to the
existing code in sage.combinat.symmetric_group_representations *except*
that the existing computes the matrices that give the action for the
symmetric groups on the ordinary irreducible representations whereas my
code defines a `CombinatorialFreeModule` for computing inside these modules
for the Hecke algebras (so the symmetric group is a special case):
sage: rep=SeminormalRepresentation([3,2,1]); rep
SeminormalRepresentation([3,2,1])
sage: rep([[1,2,3],[4,5],[6]]).T(1)
q*f(1,2,3/4,5/6)
sage: rep([[1,2,3],[4,5],[6]]).T(1,2)
q^2*f(1,2,3/4,5/6)
Currently the code is geared towards restricting to the alternating Hecke
algebras (meaning that it works over quite horrible rings) but it would be
easy enough to make it use nicer rings for the symmetric groups and their
Hecke algebras.
If people think this is interesting I would be happy to include this code
in sage, however, the main reason that I am writing is because the code is
much slower than I expected (I have similar code written in gap 3 that is
faster). In addition, the output is quite horrible. I am fairly sure that
the reason why the code is slow, and certainly the reason for the horrible
output, is because of the rings that I have work over. If people are
interested in having this ins sage then I'll make it possible to choose
nicer rings (here the code should also be much faster).
To define the rings that I want to work over I start with the Laurent
polynomial ring `Z[q,q^{-1}]` and then I adjoin the inverses and square
roots of the Gaussian polynomials `[k]=1+q^2+q^4+\dots+q^{2k-2}`, for `1\le
kn`, where `n` is the size of the partition that indexes the
representation. The only way that I found to construct this ring in sage is
by recursively adjoining more and more square roots to the Laurent
polynomial ring (in gap I hacked their polynomial code to do roughly the
same thing, but somehow it works better). Sadly because my rings are
iterated extensions sage is no longer able to cancel common factors in the
denominators and numerators of the polynomials that arise, so I get things
like
sage: SeminormalRepresentation([2,2]).tau_character(1,2)
(((-1 - 2*q^2 - q^4)*r3)*I)/(-q - 2*q^3 - q^5)
Nothing that I have tried convinces sage to cancel the common factor of
`(q^2-1)^2` here. What I am actually computing, `tau_character`, is a
twisted character value that is the interesting part of the character of
the alternating group -- and `r3` is shorthand for the square root of
`[3]=1+q^2+q^4`. Of course, this actual character value is just `q*I*r3`
but I can't see how to convince sage to do this simplification for me. (In
fact, I alerady know these character values in general, but that's another
story.)
So here are my questions:
1. Is there a better way to define the rings that I need to work over?
2. Is there a way to make sage cancel common factors in expressions like
the one above?
3. Is there anything obviously inefficient in my code? For example,
would it be better to define the element method `T` as a linear
endomorphism?
4. Is there interest in putting this into sage?
Apologies for the long post, especially as I know that this will be of
limited interest AND because I know that asking people to wade through my
code is a huge ask. For what it's worth, the code is fully documented, and
doctested, and the actual code is not so long.
Cheers,
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
from sage.combinat.free_module
[sage-combinat-devel] Re: Sage grant
Hi Anne, I agree with Dima in that it would be great to have some of the basic ring theory available in improved. There are some basic deficiencies with (Laurent) polynomial rings, especially in more than one variable and it would great if all of the problems with quite basic rings could be ironed out. In addition, my life would be much easier if sage were able to efficiently compute in the location of a ring at a ideal -- what I would really like is to be able to calculate in modular systems with parameters, which is my way of saying that I would like to be able to explicit calculations in modular systems for Iwahori-Hecke algebras. Implementing all of these gadgets is, perhaps, not so exciting from the point of view of a grant application, but not having these basic ring constructions available limits what you can currently do with sage. So far I have always found way to get around these problems, but it has been much harder than I expected. Regarding you suggested wish-list, I have already implemented graded Specht modules for KLR algebras for quivers of type A and when I have time I can get the finite dimensional standards as well. My work on this has stalled, but I am hoping to be able to restart soon, so perhaps we should talk more about this aspect of what you are planning. Andrew On Wednesday, 29 October 2014 10:42:53 UTC+11, Anne Schilling wrote: Dear All! Dan Bump, Ben Salisbury, Mark Shimozono and I are planning to apply for an NSF grant for Sage (to fund Sage Days and other Sage related activities). We will mostly focus on topics in combinatorics/algebra/ representation theory. It would be great to hear from you what your wishlists are in this area. What are features you would like to implement/ see implemented? Particular areas we would like to emphasis are representation theory of semigroups, representations of affine Lie algebras and hyperbolic Kac-Moody Lie algebras, KLR algebras, the power of the category code and functorial constructions to implement the DAHA and more. But we are open to other suggestions. Best, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Is combinat.math.washington.edu down?
Is the combinat.math.washington.edu machine down? I just tried to ssh there and ping it and got no response. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: Extednding tableaux
Thanks for your replies Travis and Nicholas. As the tableaux space is already quite full I might implement a separate shuffles class instead as this is closer to my application anyway. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Extednding tableaux
I have this vague memory that some one was thinking of extending/rationalising/reorganising the tableaux code so that it fitted together better (whatever this might mean:). Does this ring any bells with anyone? I ask because I think that I need to implement row standard tableaux (possibly of composition shape). Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
On Wednesday, 30 April 2014 16:12:33 UTC+10, Nathann Cohen wrote: There is also the problem of these __add__ and _add_. From just looking at the names you have no idea what the difference is, except if you wrote the code yourself. Now, in the graph classes we have function like add_vertex, add_vertex_unsafe, stuff like that. Wouldn't it be much better if those _add_ were renamed to something more meaningful, like _add_coerced_elements_, i.e. something that describes better what they do ? Noticing that a function is called _add_ instead of __add__ is not exactly straightforward when you don't expect it. +1. I seem to remember that there are quite a few of these _blah_ and __blah__ variants and that, usually, I wasn't quite sure what the difference was and which one I should use. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: Computing the action of S_n over standard Tableaux
Are you looking for something like this: sage: StandardTableau([[1,2,4],[3,5]]).symmetric_group_action_on_entries( Permutation(((4,5))) ) [[1, 2, 5], [3, 4]] If you also wants straightening then I guess it is implicit in the action of implementation of seminormal forms. Andrew On Tuesday, 18 February 2014 03:52:46 UTC+11, Nicolas Borie wrote: Hi all, Is there currently a way in Sage-combinat to compute the action of a permutation over standard tableaux ? For example, I would like something like : Permutation([2,1,3,4]) * B([[1,2],[3,4]]) = B([[1,2],[3,4]]) - B([[1,3],[2,4]]) This thing is called in French algorithme de redressement (In the same time, what is the equivalent in English ?) and is related to Ganir identity (Or Garnir rules...). They are a lot of thing in combinat but I didn't find it... Can someone confirm that or give my a pointer otherwise... Cheers, Nicolas B. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Computing the action of S_n over standard Tableaux
I'm highly in favor of adding more meat to the representations of the Specht modules in Sage. Currently, the way I understand them, they're but a container for matrices. At some point I will release my graded Specht module code (arbitrary level) which is IMHO is state of the art for representations of symmetric groups in positive characteristic. I'm not ready to do this yet...and I haven't had time to play with this for a long time... Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: list papers citing sage!
I couldn't see how to edit the page. Sorry! I wanted to add the following preprint/book chapter (book chapters don't seem to exist in the list yet): Andrew Mathas, a href=http://front.math.ucdavis.edu/1310.2142;Cyclotomic quiver Hecke algebras of type A/A, *arXiv:1310.2142* *Andrew* On Monday, 17 February 2014 04:07:33 UTC+11, Anne Schilling wrote: Dear All! It's the time of the year when we need to report to our funding agencies. Please, if you have written papers that used sage or sage-combinat, post them at http://www.sagemath.org/library-publications-combinat.html (or respond to this e-mail to get them posted)! Thank you, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Review request for group cycle index series
Hello, and happy holidays! I'd be very grateful if someone would be willing to take the time to review my patch at #14347. This code implements Γ-cycle indices, an extension of the classical species-theoretic cycle index series which incorporates information about structural group actions. I believe this code is functional and complete--I'm actively using it in my research, so everything should be reasonably well-tested. (In fact, the reason I'm so eager to get the code into main is that I have some papers in the pipeline which include code based on this patch, and I'd very much like to have that code work!) I'll be very happy to talk through the math involved with any interested parties. In particular, I'm working on a draft of an expository paper on the topic of Γ-species which I'd be glad to share. Thanks! --Andrew -- Andrew Gainer-Dewar, Ph.D. Visiting Assistant Professor of Mathematics (2012-2014) Carleton College, Northfield, MN USA http://people.carleton.edu/~againerdewar -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Fast Implementation for Character Values of Symmetric Groups
Amri, this is quiet an impressive speed difference! If it's not too
difficult I'd be interested in seeing the timings for computing the full
character tables using your implemenentation of Murnaghan-Nakayama,
symmetric functions and the in-built character_table() method for the
symmetric groups..
Cheers,
Andrew
Saturday, 21 December 2013 18:29:47 UTC+1, Amri wrote:
Just to convince (myself and) Nicolas, I have a quick and dirty
implementation of the recursive Murnaghan-Nakayama formula.
https://www.dropbox.com/s/8xfz4jo8bzjf7kf/mnr.py
There are two functions implemented here, both of which compute a
character value of the symmetric group.
The first uses symmetric functions exactly as suggested by Darij and is
called X
The second used the recursive Murnaghan-Nakayama formula and is called MNR
A typical timeit for a partition of 40:
sage: la = Partitions(40).random_element()
sage: mu = Partitions(40).random_element()
sage: timeit('X(la,mu)')
5 loops, best of 3: 854 ms per loop
sage: timeit('MNR(la,mu)')
125 loops, best of 3: 2.62 ms per loop
And most importantly:
sage: X(la,mu)==MNR(la,mu)
True
So if you just need one character value of a large symmetric group, the
recursive formula of Murnaghan-Nakayama is 300 times faster.
Another question: what is a good name for this function?
best,
Amri.
On Saturday, December 21, 2013 5:14:56 PM UTC+5:30, darijgrinberg wrote:
Hi Nicolas,
the question is, I think, the one of doing it for one partition vs.
doing it for all partitions of n. In the latter case, I think we
should do what we say (replace Symmetrica if we can do it better, or
leave it be if we can't), but Amri has been talking about the former
case and there is definitely room for improvement there when n is
large. And I think it conceptually fits into partition.py, although
most people like myself probably won't ever use n's greater than 20 or
so.
Best regards,
Darij
On Fri, Dec 20, 2013 at 3:11 PM, Nicolas M. Thiery
nicolas...@u-psud.fr wrote:
Hi!
On Fri, Dec 20, 2013 at 12:37:51PM +0100, Darij Grinberg wrote:
But you are right in saying that this is not an optimal solution,
and it
might be better to implement the Murnaghan-Nakayama rule directly
as a
hook-removal algorithm rather than by building the whole s and p
bases of
Sym.
Well, building the whole s and p bases of Sym is not a deal as big
as the formulation may suggest :-) On a fresh Sage session:
sage: %time SymmetricFunctions(QQ).s()
CPU times: user 0.19 s, sys: 0.03 s, total: 0.23 s
Wall time: 0.27 s
Symmetric Functions over Rational Field in the Schur basis
sage: %time SymmetricFunctions(QQ).p()
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
Symmetric Functions over Rational Field in the powersum basis
And from now on the overhead of going through Sym to compute
characters is essentially negligible. If really you want to save on
this minimal overhead, look at the symmetric functions code, and call
Symmetrica directly.
On the other hand, what would be costly would be to have to maintain
two implementations of the MN rules just because they are used in
different places. If someone has an alternative implementation of MN
that is more efficient than that of Symmetrica, then we should drop
that piece of Symmetrica, and have the symmetric function code use the
alternative implementation.
Cheers,
Nicolas
--
Nicolas M. Thiéry Isil nth...@users.sf.net
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google
Groups sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-comb...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Fast Implementation for Character Values of Symmetric Groups
If you want the full character table then you can also do: sage: SymmetricGroup(Integer(5)).character_table() [ 1 -1 1 1 -1 -1 1] [ 4 -2 0 1 1 0 -1] [ 5 -1 1 -1 -1 1 0] [ 6 0 -2 0 0 0 1] [ 5 1 1 -1 1 -1 0] [ 4 2 0 1 -1 0 -1] [ 1 1 1 1 1 1 1] From memory this calls gap in the background, so using symmetric functions as Darij suggests will definitely be faster for individual entries and it may even be faster for the whole character table. Andrew On Friday, 20 December 2013 11:33:55 UTC+1, Amri wrote: Is there a fast implementation for characters values of symmetric groups in Sage? It looks like sage.combinat.symmetric_group_representations.pyconstructs the representation explicitly to compute the character values. In any case, it's not fast. I am looking for a function which, when fed two partitions ``la`` and ``mu`` returns the value of the character of the Specht module corresponding to ``la`` at a class with cycle type ``mu``. I would like something at least as fast as the Murnaghan-Nakayama formula (Theorem 2.4.7 in *Representation Theory of the Symmetric Group* by James and Kerber). I am also curious to know what the fastest known algorithm is. Thanks, Amri. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Bug in Core
Hi Christian, I agree that this probably is a bug, but looking at the class a little more closely I think that it needs some TLC. In particular, it seems to me that the object that Core returns does not really know that it is a core. Consider: sage: Core([2],4) is Partition([2]).core(4) False sage: Core([2],4) == Partition([2]).core(4) True sage: Core([2],4) == Core([2],5) True sage: Cores([2],4) in Cores(5,2) True If core-ness is intrinsic to what is being returned here then I would think/hope that the first two return values should be True and that the last two should be False. The hash values seem to be consistent with what is happening above. As some one obviously needs this class it is no doubt a good thing to to have but I think that it would be better if the implementation distinguished a little more between partitions and cores. Further, if A=Core([2],4) then it wasn't obvious to me how to extract the fact that A is a 4-core from A. It turns out that sage: A.parent().k 4 works but this took me a while to find. I think that it would also be better if A._repr_() said that A is a 4-core rather than just printing [2]. Finally, as this class is a little specialised, it probably shouldn't be in the global namespace. Andrew On Monday, 16 December 2013 11:24:05 UTC+1, Christian Stump wrote: Hi, do you consider the following a bug? sage: A = Core([2],4) sage: B = Core([2],5) sage: hash(A) == hash(B) True The hash of a core only depends on the list and not on the core. Since the same list considered as an x- and as a y-core are fundamentally different objects, I would rather suggest to have the hash depending not only on the list. If others agree, I will provide a patch fixing that... Cheers, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Bug in Core
Yes, I agree. I noticed this after I posted but I GG doesn't allow me to edit:) A. On Monday, 16 December 2013 14:22:50 UTC+1, Christian Stump wrote: Thanks, Andrew! sage: Core([2],4) is Partition([2]).core(4) False I agree with all what you write, except that I would not expect this to be true since two instances of the same core are not the same object (thus do not lie in the same place in space, thus X is Y is not True). Best, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: A Partitions Pickle
On Wednesday, 11 December 2013 21:11:00 UTC+1, Travis Scrimshaw wrote: I'm starting to think that we need is a better system for the global options. I'm thinking what we could do is change thing around a bit by having GlobalOptions inherit from UniqueRepresentation with a __classcall__ method that takes no inputs and we subclass that with passing the necessary data up via the __init__() method. For example, PartitionOptions would be a subclass of GlobalOptions instead of an instance, and it then should pickle properly with better separation between different global options. Hi Travis, I agree that this would be a better solution as having a non-pickleable class is distasteful - although I have this vague memory that we argued against subclassing during #13605:). If we're going to mess with GlobalOptons when probably we should also implement Volker's suggestionhttps://groups.google.com/forum/#!searchin/sage-devel/globaloptions/sage-devel/7ApZgwBTU4U/Qe6QoeuYgvAJthat we adopts the ipython syntax, although I guess this is slightly painful as we'd to do this in two steps starting with depreciation [sic]. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: A Partitions Pickle
, can you please find a more informative class name than Partitions_constraints_new. A part from this name not telling me anything meaningful, the name will not be appropriate in a few years time. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Wrongs results again
On Monday, 2 December 2013 09:40:57 UTC+1, Nathann Cohen wrote: Oddly, knowing that it has been known for two years that this function returned wrongs results, and that nobody cared enough to fix it is not exactly a comforting thought. Oddly, given that the sage-combinat discussion referred to above was in 2012, I make it one year (definitely odd since two is even). Although I do share your annoyance when things don't work perfectly I don't find this in the least bit odd because trac lists some (sometimes serious) bugs in sage that have been known since 2007. There's even quite a few old graph theory tickets with your name directly attached to them. That's definitely odd! To be honest Nathan, I also find your penchant for flaming sage-combinat slightly odd but I am sure that there is some rational explanation such as some childhood trauma associated with the counting large primes or the odd order theorem:) I'm sure that How to make friends and influence people warns against flaming in cooperative projects as it rarely achieves any of your desired aims, except possibly for short term amusement. Well, oddly, I've never read this book but I think it would be odd if it didn't say something like this. Any way, these odd issues aside of your aside, thanks for fixing the problem! Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Wrongs results again
On Friday, 29 November 2013 19:49:32 UTC+1, Nathann Cohen wrote: Oh. And on top of everything, the documentation of RestrictedPartitions (a deprecated class) says that the feature it implements is *NOT* available through Partitions. So this thing has been deprecated while there was no other way to get the result. So I guess it will stay there forever, deprecated. Good job. Nathann Hi Nathan, RestrictedPartions were depreciated in trac5478http://trac.sagemath.org/ticket/5478, incorrectly as you point out. See the previous discussion about this point in sage-combinat-develhttps://groups.google.com/forum/#!topicsearchin/sage-combinat-devel/RestrictedPartitions|sort:date/sage-combinat-devel/utAsQzZQKLo, particularly starting from 30/8//2012. It's listed on trac12278http://trac.sagemath.org/ticket/12278as an issue to be fixed. Andrew On 29 November 2013 17:17, Nathann Cohen nathan...@gmail.comjavascript: wrote: Okay, this time it did not take long. Quote from the constructor of Partitions : if 'parts_in' in kwargs: return Partitions_parts_in(n, kwargs['parts_in']) elif 'starting' in kwargs: return Partitions_starting(n, kwargs['starting']) elif 'ending' in kwargs: return Partitions_ending(n, kwargs['ending']) From this code, we learn that we can build a partitions with a starting parameter, an ending parameter, OR a parts_in parameter, but that those arguments CAN NEVER BE COMBINED. Honestly, you cannot look at a code like that and not notice that something wrong is going on. I will create (as in #13742) a patch that screams when bad input is given. Actually I just did, it is #15467. Nathann -- You received this message because you are subscribed to a topic in the Google Groups sage-combinat-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-combinat-devel/vyMs7PQ8KbA/unsubscribe . To unsubscribe from this group and all its topics, send an email to sage-combinat-devel+unsubscr...@googlegroups.com javascript:. To post to this group, send email to sage-comb...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Some rebasing and the end of #10963?
On Thursday, 31 October 2013 10:29:22 UTC+1, Nicolas M. Thiery wrote: Works for me for 5.13.beta1 (but we have a reject for trac_Kleshchev-partitions-am.patch there ...). I've just rebased this patch so the full queue should apply now -- well, at least using 5.12. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Some rebasing and the end of #10963?
As you mentioned that you installed a new version of xcode the discussion on sage-dev about OS mavericks might be relevant. I haven't been reading this as I haven't touched xcode, but I don't think they've solved all of the issues yet so even if it is relevant it might only count as moral support at this this juncture... A. On Thursday, 31 October 2013 19:07:06 UTC+1, Mike Zabrocki wrote: Does anyone have any advice about what might be wrong with the compilation or who to ask? I doubt that I will be able to compile much of anything until I get this fixed: The file /Applications/sage/local/bin/../lib/gcc/x86_64-apple-darwin12.4.0/4.7.3/include-fixed/limits.h:169:61 contains the lines at the end that are triggering the error fatal error: limits.h: No such file or directory: #else /* not _GCC_LIMITS_H_ */ #ifdef _GCC_NEXT_LIMITS_H #include_next limits.h /* recurse down to the real one */ #endif #endif /* not _GCC_LIMITS_H_ */ - If I remove the line #include_next limits.h then it fixes the problem in that file but the same problem pops up in other files. The problem must be that some path variables are not set correctly for my system. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: StandardTableaux broken
Sorry, Jean-Yves is correct: with the **full** queue applied StandardTableaux was broken. This was my fault and it is now fixed: ┌┐ │ Sage Version 5.12, Release Date: 2013-10-07│ │ Type notebook() for the browser-based notebook interface.│ │ Type help() for help.│ └┘ sage: StandardTableaux(4)[:] [[[1, 2, 3, 4]], [[1, 3, 4], [2]], [[1, 2, 4], [3]], [[1, 2, 3], [4]], [[1, 3], [2, 4]], [[1, 2], [3, 4]], [[1, 4], [2], [3]], [[1, 3], [2], [4]], [[1, 2], [3], [4]], [[1], [2], [3], [4]]] On the plus side, there is a slight speed up when running through the list of all standard tableaux. Jean-Yves, to fix your version of sage just type: sage -combinat update from the shell. Andrew On Tuesday, 15 October 2013 16:53:59 UTC+2, Jean-Yves Thibon wrote: Salut Fred, J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle machine (un mac). Je viens juste de la compiler et d'installer combinat ... Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit : Salut Jean-Yves chez moi, je n'ai pas ton problème non plus quelle version de sage tu as ? tape version() pour voir tu peux me telephoner au boulot si tu veux (voir mon tel sur http://math.univ-lyon1.fr/~chapoton/) Fred Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit : sage: tt=StandardTableaux(4) tt.list() hangs, and that's why: sage: tt[1] [[1, 2, 3, 4]] sage: tt[2] [[1, 2, 3, 4]] sage: tt[3] [[1, 2, 3, 4]] sage: -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: StandardTableaux broken
This seems to come from the patch http://trac.sagemath.org/ticket/7983 which was merged in 5.12. Perhaps what you want is now given by standard_descents() which is included in the same patch: sage: StandardTableau( [[1,3,4],[2,5]] ).standard_descents() [1, 4] sage: StandardTableau( [[1,2],[3,4]] ).standard_descents() [2] sage: StandardTableau( [[1,2,5],[3,4],[6,7],[8],[9]] ).standard_descents() [2, 5, 7, 8] sage: StandardTableau( [] ).standard_descents() [] Andrew On Wednesday, 16 October 2013 17:51:11 UTC+2, Jean-Yves Thibon wrote: OK, thanks. It works now. But new problems arise. Now that I can get my hands on standard tableaux, I call a function written a few months ago, which uses t.descents(). It does not work anymore, the output of t.descents has changed type in the meantime, and the doc mentions Warning: This is not to be confused with the descents of a standard tableau. This leaves me voiceless ... Le mercredi 16 octobre 2013 16:35:25 UTC+2, Andrew Mathas a écrit : Sorry, Jean-Yves is correct: with the **full** queue applied StandardTableaux was broken. This was my fault and it is now fixed: ┌┐ │ Sage Version 5.12, Release Date: 2013-10-07│ │ Type notebook() for the browser-based notebook interface.│ │ Type help() for help.│ └┘ sage: StandardTableaux(4)[:] [[[1, 2, 3, 4]], [[1, 3, 4], [2]], [[1, 2, 4], [3]], [[1, 2, 3], [4]], [[1, 3], [2, 4]], [[1, 2], [3, 4]], [[1, 4], [2], [3]], [[1, 3], [2], [4]], [[1, 2], [3], [4]], [[1], [2], [3], [4]]] On the plus side, there is a slight speed up when running through the list of all standard tableaux. Jean-Yves, to fix your version of sage just type: sage -combinat update from the shell. Andrew On Tuesday, 15 October 2013 16:53:59 UTC+2, Jean-Yves Thibon wrote: Salut Fred, J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle machine (un mac). Je viens juste de la compiler et d'installer combinat ... Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit : Salut Jean-Yves chez moi, je n'ai pas ton problème non plus quelle version de sage tu as ? tape version() pour voir tu peux me telephoner au boulot si tu veux (voir mon tel sur http://math.univ-lyon1.fr/~chapoton/) Fred Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit : sage: tt=StandardTableaux(4) tt.list() hangs, and that's why: sage: tt[1] [[1, 2, 3, 4]] sage: tt[2] [[1, 2, 3, 4]] sage: tt[3] [[1, 2, 3, 4]] sage: -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Review request(s): cycle index series code
Hello! I currently have three open tickets with patches which add functionality related to cycle index series. I'd really appreciate reviews, comments, or other input! * #14543: adds a compositional_inverse() method to CycleIndexSeries which, naturally, computes a plethystic inverse for a given cycle index series. I believe this one is all set to go, but it needs a review from someone who is comfortable with the inner workings of CycleIndexSeries and (possibly) LazyPowerSeries. * #14846: shuffles things around so that the derivative() and exponential() methods of CycleIndexSeries correspond to the combinatorial definitions of those operations (which are different than those inherited from LazyPowerSeries). The code works fine (as far as I can tell), but this is a design decision, and I'm a new kid, so I'd appreciate the input of more experienced folks on whether this is appropriate. * #14347: adds a GroupCycleIndexSeries class which implements Γ-cycle index series, which allow for working with species which carry a structural group action as in cf. [1]. I have some papers in draft that use this code, and I'd love to be able to cite a shipped version of Sage! --Andrew [1] http://www.combinatorics.org/ojs/index.php/eljc/article/view/v19i4p45 signature.asc Description: OpenPGP digital signature
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
On Tuesday, 30 July 2013 14:18:28 UTC+2, Simon King wrote: Hi all, On 2013-07-29, Simon King simon...@uni-jena.de javascript: wrote: After all, we have a class, and we call the class as if to create an instance---but what we get is in fact not an instance of this class, but is instance of a *totally* different class. OK, it is possible, Python let's you do it. But not all what can be done should be done. I have nothing against the following pattern: ... And I think this pattern is totally fine, since C(...) returns instances of sub-classes of C (namely of A resp. B)---hence, it returns instance of C! I could imagine that a similar pattern would be available for Partition versus PartitionTuple. I determined all classes-with-ClasscallMetaclass that sometimes return instances that are not instances of this class: sage.combinat.composition.Compositions sage.combinat.integer_vectors_mod_permgroup.IntegerVectorsModPermutationGroup sage.combinat.partition.Partitions sage.combinat.partition_tuple.PartitionTuple sage.combinat.posets.poset_examples.Posets sage.combinat.root_system.type_relabel.CartanType sage.combinat.tableau_tuple.StandardTableauTuple sage.combinat.tableau_tuple.StandardTableauTuples sage.combinat.tableau_tuple.TableauTuple sage.combinat.tableau_tuple.TableauTuples plus three classes that seem only to be made for doctests. What do you think? These are relatively few classes. Would it be reasonable to change them, such that when on tries to create instances of these classes then one is guaranteed to actually get an instance of these classes (or a sub-class, at least)? I have no objection provided that the new code continues to respect the underlying *mathematical relationships* between these classes. I think that changing the classes so that they respect semantic niceities whilst breaking the underlying mathematical relationships, which these classes are meant to emulate, would be a mistake. It would also delay my porting into sage what I think is probably the best avilable code for working with representation theory of the symmetric groups in positive characteristic. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
On Sunday, 28 July 2013 19:56:02 UTC+2, Simon King wrote: Am Sonntag, 28. Juli 2013 14:23:39 UTC+2 schrieb Simon King: It turns out that a lot of stuff in sage.combinat breaks. Apparently some people really want that if C is a class then C(*args,**kwds) is not an instance of this class. Here is an example: sage: mu = PartitionTuple([3,2]) sage: isinstance(mu, PartitionTuple) HI Simon, I wrote this and although I agree it is an abuse is it what I wanted and I think that, mathematically, it is the correct behaviour. The point is that a partition is a 1-tuple of partitions and hence a partition tuple. On the other hand, in most applications (in mathematics or in sage) you don't want to think of a partition as tuple of partitions. As such I think this is a mild abuse as the class s returning a closely related class. In terms of implementation, this was discussed a ittle on sage-combinat. The general feeling was that the implementation of PartitonTuple should not compromise the Partition class because partitions are in so many places. To avoid code duplication I would have liked to have both classes inherit from a common super class (but still with the behaviour above that you don't like), but the general feeling was that this was a bad idea. As it stands now,the Partition and PartitionTuple classes play very well together , I think. Even though PartitionTuple does not always return a PartitionTuple it behaves as if it does. In my own applications I *need* Partition and PartitionTuple to behave identically -- the methods that I use exist in both classes -- and the current code achieves this. To continue your example: sage: mu = PartitionTuple([3,2]) sage: mu in PartitionTuples() True I know your posts are more general than this one example, but hopefully having my (possibly misguided) rationale explained for this one example with help the discussion. If there are better ways to implement these classes Id be very pleased to hear them, but I do want the behaviour above. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Skew tableaux
On Monday, 1 July 2013 21:06:46 UTC+2, darijgrinberg wrote: This isn't the only thing missing, and it seems that skew_tableau.py never got the love that tableau.py received during development. One many things that skew tableaux (and skew partitions) are currently missing is a latex method. As part of a review of Travis huge categorification patch for partitons I updated sage.combinat.output.py so that the routines there now work for skew tableaux (and diagrams of skew partitions) but we didn't add the corresponding methods to skew tableaux. If any one wants these, I think that it is enough to simply copy the corresponding routines across from the non-skew classes, although there will be some trickery due to the global option classes...I'm fairly snowed under at the minute, but if there is sufficient demand I could look in to this. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Installing combinat queue
Thank Travis. I am compiling from source of course. The problem might be
that bash install function I wrote uses make all rarher than just make,
which is what I used to do by handaccorrding to the makefile these
should be equivalent but it is the only difference I can see. Will test
when I have access to a proper internet connection again.
A.
On Friday, 28 June 2013 13:55:38 UTC+2, Travis Scrimshaw wrote:
Hey Andrew,
Are you compiling it from source code or using the prebuilt? Because I
believe building the doc is built during the compilation. As for the
prebuilts, since sage now copies over the doc (previously it just rebuilt
it) and it may not be included in; so look in your sage/doc/output... to
see if there is doc already built. If not, then I guess you'll have to
build the doc first (or at least put a temp folder) and we'll need to make
a ticket on this (likely a blocker).
Best,
Travis
On Friday, June 28, 2013 11:03:26 AM UTC+2, Andrew Mathas wrote:
Hi All,
Whenever I try installing the combinat queue on top of a new verion tehse
days I run into an error like this:
MacAndrew-528-(sage-5.10)-combinat: sage -combinat install
Creating sage-combinat branch:
/usr/local/src/sage/sage-5.10/sage -b main
--
sage: Building and installing modified Sage library files.
Installing c_lib
/usr/local/src/sage/sage-5.10/devel/sage/c_lib
g++ -o libcsage.dylib -single_module -flat_namespace -undefined
dynamic_lookup -dynamiclib src/convert.os src/interrupt.os src/memory.os
src/mpn_pylong.os src/mpz_pylong.os src/mpz_longlong.os src/stdsage.os
src/gmp_globals.os src/ZZ_pylong.os src/ntl_wrap.os
-L/usr/local/src/sage/sage-5.10/local/lib
-L/usr/local/src/sage/sage-5.10/local/lib/python2.7/config -lntl -lpari
-lgmp -lpython2.7
Updating Cython code
Compiling sage/libs/lrcalc/lrcalc.pyx because it changed.
Cythonizing sage/libs/lrcalc/lrcalc.pyx
Finished compiling Cython code (time = 10.7281630039 seconds)
running install
running build
running build_py
running build_ext
building 'sage.libs.lrcalc.lrcalc' extension
Executing 1 command (using 1 thread)
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-I/usr/local/src/sage/sage-5.10/local/include/lrcalc/
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include/python2.7 -c
sage/libs/lrcalc/lrcalc.c -o
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o -w
gcc -bundle -undefined dynamic_lookup
-L/usr/local/src/sage/sage-5.10/local/lib
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o
-L/usr/local/src/sage/sage-5.10/local/lib -lcsage -llrcalc -lstdc++ -lntl
-o build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so
Time to execute 1 command: 2.87031507492 seconds
Total time spent compiling C/C++ extensions: 3.05725002289 seconds.
running install_lib
copying build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so -
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage/libs/lrcalc
running install_egg_info
Removing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
Writing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
real 21.433user 6.020sys 1.829pcpu 36.61
/usr/local/src/sage/sage-5.10/sage -clone combinat
Now cloning the current Sage library branch...
hg clone sage sage-combinat
updating to branch default
2973 files updated, 0 files merged, 0 files removed, 0 files unresolved
Copying over all Cython auto-generated .c, .cpp and .h files...
Copying over hidden Cython version file...
Copying over build directory...
Copying over all auto-generated reference manual .rst files...
Copying over documentation output...
Traceback (most recent call last):
File /usr/local/src/sage/sage-5.10/local/bin/sage-clone, line 101, in
module
shutil.copytree('sage/doc/output', branch + '/doc/output',
symlinks=True)
File /usr/local/src/sage/sage-5.10/local/lib/python/shutil.py, line
171, in copytree
names = os.listdir(src)
OSError: [Errno 2] No such file or directory: 'sage/doc/output'
real 47.575user 5.615sys 3.598pcpu 19.36
Abort
Does this mean that I need to build the documentation before installing
the combinat queue or am I doing something else wrong?
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
[sage-combinat-devel] Installing combinat queue
Hi All,
Whenever I try installing the combinat queue on top of a new verion tehse
days I run into an error like this:
MacAndrew-528-(sage-5.10)-combinat: sage -combinat install
Creating sage-combinat branch:
/usr/local/src/sage/sage-5.10/sage -b main
--
sage: Building and installing modified Sage library files.
Installing c_lib
/usr/local/src/sage/sage-5.10/devel/sage/c_lib
g++ -o libcsage.dylib -single_module -flat_namespace -undefined
dynamic_lookup -dynamiclib src/convert.os src/interrupt.os src/memory.os
src/mpn_pylong.os src/mpz_pylong.os src/mpz_longlong.os src/stdsage.os
src/gmp_globals.os src/ZZ_pylong.os src/ntl_wrap.os
-L/usr/local/src/sage/sage-5.10/local/lib
-L/usr/local/src/sage/sage-5.10/local/lib/python2.7/config -lntl -lpari
-lgmp -lpython2.7
Updating Cython code
Compiling sage/libs/lrcalc/lrcalc.pyx because it changed.
Cythonizing sage/libs/lrcalc/lrcalc.pyx
Finished compiling Cython code (time = 10.7281630039 seconds)
running install
running build
running build_py
running build_ext
building 'sage.libs.lrcalc.lrcalc' extension
Executing 1 command (using 1 thread)
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-I/usr/local/src/sage/sage-5.10/local/include/lrcalc/
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include/python2.7 -c
sage/libs/lrcalc/lrcalc.c -o
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o -w
gcc -bundle -undefined dynamic_lookup
-L/usr/local/src/sage/sage-5.10/local/lib
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o
-L/usr/local/src/sage/sage-5.10/local/lib -lcsage -llrcalc -lstdc++ -lntl
-o build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so
Time to execute 1 command: 2.87031507492 seconds
Total time spent compiling C/C++ extensions: 3.05725002289 seconds.
running install_lib
copying build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so -
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage/libs/lrcalc
running install_egg_info
Removing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
Writing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
real 21.433user 6.020sys 1.829pcpu 36.61
/usr/local/src/sage/sage-5.10/sage -clone combinat
Now cloning the current Sage library branch...
hg clone sage sage-combinat
updating to branch default
2973 files updated, 0 files merged, 0 files removed, 0 files unresolved
Copying over all Cython auto-generated .c, .cpp and .h files...
Copying over hidden Cython version file...
Copying over build directory...
Copying over all auto-generated reference manual .rst files...
Copying over documentation output...
Traceback (most recent call last):
File /usr/local/src/sage/sage-5.10/local/bin/sage-clone, line 101, in
module
shutil.copytree('sage/doc/output', branch + '/doc/output',
symlinks=True)
File /usr/local/src/sage/sage-5.10/local/lib/python/shutil.py, line
171, in copytree
names = os.listdir(src)
OSError: [Errno 2] No such file or directory: 'sage/doc/output'
real 47.575user 5.615sys 3.598pcpu 19.36
Abort
Does this mean that I need to build the documentation before installing the
combinat queue or am I doing something else wrong?
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Terminated jobs on combinat server?
Thanks for letting me know. I should improve the code I was running anyway:) Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Terminated jobs on combinat server?
Hi All, I had some (very long and quite intensive but niced) jobs running on the combinat server but they have all been terminated. I'm not sure whether this was done accidentally or because they were hogging resources or for some other reason (although I was monitoring them and they seemed OK). This calculation has been all that I have had time for sagewise for the past few months:( Unfortunately I have lost some of the calculation but luckily I can restart them within a few days of when they died. Before restarting them I thought that I should check to see if I was breaking the usage guidelines or etiquette. Please advise! Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Terminated jobs on combinat server?
On Tuesday, 18 June 2013 11:26:13 UTC+10, William Stein wrote: I definitely didn't kill them, and the machine hasn't been rebooted in 2 months. Your jobs might have used too much memory and been killed by the Linux kernel. Thanks William, that's probably what happened. I'll try and improve my memory management! Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Sage 5.9 crashing when the queue is applied -- #9439 and #9557
Hi All, I just updated the combinat queue using version 5.9. The queue applies cleanly, sage builds without complaint but sadly sage crashes when you start it. The patch that was causing the problem is trac_9439-hyperbolic_geometry-vd.patch. I have disabled this patch and trac_9557-fundamental_domains-vd.patch, which depends upon it. The queue now applies and sage builds and runs. Presumably the problem is caused by a whole bunch of Vincent's patches being disabled higher up in the queue. The same problem affects sage-5.10.beta2. I don't know about beta3-5 as I don't have these to play with. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: an algorithm generating random young tableaux of given shape
If you check tableau.py you'll find that some one (not sure who?) has already implemented this in sage: see the random element method of StandardTableau. For a StandardableauTuple I implemented a different random_element - this was purely for my own amusement, however, and I have no idea how uniform etc the distribution is... Andrew On Friday, 26 April 2013 17:18:45 UTC+10, Christian Stump wrote: Just for the records, in case we / someone is interested in such an algorithm: http://mathoverflow.net/questions/128540/generating-random-young-tableaux-a-peculiar-probability-identity Cheers, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Wrong rebase...
Oops, sorry, fixed now. Florent: thanks for cleaning up after me. Andrew On Tuesday, 23 April 2013 23:38:00 UTC+10, fhivert wrote: Dear Andrew, During your last rebase you introduced the following lines in your patch: tableaux-combinatorics-am.patch:+del from tableau_tuple import TableauTuple, StandardTableauTuple, TableauTuples, StandardTableauTuples trac_Kleshchev-partitions-am.patch:+del from partition_tuple import PartitionTuple, PartitionTuples This is probably due to some wrongly resolved conflict. I disabled temporarily your patches with the guard +wrong_rebase. Can you resolve the problem or do you need some help ? Cheers, Florent -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: queue needs attention!
Hi Anne, It looks like the conflicts were caused by changes that some one made to ../combinat/all.py. I rebased your trac_12250-ktableaux-as.patch, trac_14145-fix_contains_tableau-ts.patch and two of my patches further down the queue. The queue now applies. Can everyone please remember to check that the whole queue applies before pushing the queue? :) Cheers, Andrew On Friday, 19 April 2013 03:06:04 UTC+10, Anne Schilling wrote: Hi Travis, I think your changes broke the queue due to some conflicts. I fixed one, but now there is another reject: applying tableaux-combinatorics-am.patch patching file sage/combinat/all.py Hunk #1 FAILED at 65 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/all.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh tableaux-combinatorics-am.patch Could you or Andrew please fix this? Thank you, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: The reading tableau of a partition
Hi Travis, What confused me is that the example in the documentation seems to say that the reading tableau for the *partition* (3,2,1) should be 1 4 6 2 5 3 whereas the example in the doc-test says that it is 1 3 6 2 5 4 These two tableaux are different. I need the first of these tableaux and I thought that this is what reading_tableau() was supposed to return. This isn't a big deal for me because I can get this tableau easily a different way. All these concerns aside, however, I am still confused by the documentation as it the example contained in the help for reading_tableau seems to contradict what the function actually does. Notice that this a method for a partition which returns a tableau -- there are no permutations in sight here. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] The reading tableau of a partition
Good Morning! I have been distracted from sage for quite some time but this morning I started playing again and I came across the *reading_tableau *method of a partition. The documentation for this method reads: Return the reading tableau of the reading word under the Robinson-Schensted correspondence of the (standard) tableau `T` labeled down (in English convention) each column to the shape of ``self``. For an example of the tableau `T`, consider the partition `\lambda = (3,2,1)`, then we have:: 1 4 6 2 5 3 For more, see :func:`~sage.combinat.rsk.RSK()`. EXAMPLES:: sage: Partition([3,2,1]).reading_tableau() [[1, 3, 6], [2, 5], [4]] The example in the text and the example that is doc-test appear to disagree. My guess is that the example in the text is what is expected. Is this right? [In 5.8 the behaviour is as in the doc-test.] I suspect that this may have changed when partitions were made to play nicely with categories as I think that the order in which the partitions are generated may have changed then. All this aside, if some one can confirm that this is a bug then I will file a ticket, and probably even a patch. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Upcoming Sage workflow
I for one am delighted to hear about this plan! As a newcomer to the Sage development community, I can say with some authority that the complexity of the development model is a huge barrier to entry. Heck, I still don't feel like I know for sure what I'm supposed to do with new code, and sometimes I'm not even sure which *repository* I should be interacting with. Moving Sage development to a DVCS branching model will be a terrific move forward for people like me. I personally happen to be familiar with git already, so that's an extra bonus, but the rationalization of the community development model is (I think) the real prize here. Bravo, and cheers to the development team! --Andrew On Saturday, March 30, 2013 3:52:16 AM UTC-5, Nicolas M. Thiery wrote: Dear Sage-Combinat developers, It's been quite an intensive Sage Days here in Portland working on the upcoming Sage workflow! Here is a first update. The core feature is that the interaction with the Sage official repository will be done through our version control system: updating to the latest version, sending a modification, reviewing a ticket, ... No more manual posting or downloading patches from trac or extracting a patch from an old version of Sage and manually rebasing it onto a new version. In practice this clears the main hurdle that was preventing us to use standard version control features like branches. Gone should be the Sage-Combinat queue which was isolating us from the other Sage devs and forcing tedious rebasing and bookkeeping. Instead, each project will be able to develop itself on its own branch without perturbing the others. Much more flexibility and productivity. In practice, the team has chosen to base the new workflow on top of the DVCS git instead of mercurial previously. I am not necessarily convinced by this choice, but I respect it: by doing the work they earn the right to do the technical choices. For issue tracking, we will still be using trac; however trac will now be aware of the underlying DCVS and most operations will be doable from the command line, if not offline. The other good news is that, thanks to the hard work the team put into this during all week and before, this could be coming relatively fast. I for myself will be trying out the new workflow in the coming weeks, and maybe a transition period around Sage Days 49? So that all is pretty exciting and now you all should be longing to switch to the new workflow. So I can state the bad news :-) - The transition will require work! Migrating the current patches, playing with the new workflow, smoothing out all the rough edges, training our team, writing documentation and scripts, ... - Experience tells that a key feature for Sage's development is the handling of dependencies between tickets. For various reason we need that more than most other software projects. This means that we are on our own here. We will need to discover ourselves the best (and worst!) practices and develop appropriate tools on top of our DCVS. - How well this all will work in practice is quite open: - How easy will it be to keep an overview of what everybody is working on? To detect conflicts and opportunities of collaborations early on? - How smooth will it be to jump between branches? E.g. will reviewing a branch which is based on the very latest version of Sage require a lot of recompilation time? - How easy and robust will it be to join branches in order to combine all the in-development features that we need for our calculations? Anyway, let's move forward. Work is already in progress to try to tackle those. Beside participating to the many design discussions, I spent most of the week automatizing the migration of the queue from a linear stack of patches to a relatively flat graph of independently branches (see attached file). At this point, I can import most of the queue. A good chunk of the work was to recover the dependencies the hard way. And this is only about the syntactic dependencies. There certainly are semantic dependencies that I did not detect: in fact except for a few branches, I haven't even tried to run Sage, let alone run the tests! I encoded the dependency information in the series file; I'll push it later on this week-end. Please add any dependency information you may be aware of! Oh, and it will help the transition as well if you create tickets for your patches and name your patches accordingly. More information on the transition will come later. For now, a big kudo to those who work hard on this for us: Andrew, Benjamin, Christopher, David, Julyan, Jeroen, Keshav, Keith, Robert, Timo. Cheers, Nicolas -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: http://Nicolas.Thiery.name/ -- You received this message because you
[sage-combinat-devel] Review request: Implement multiplicative inverses of cycle index series (#14350)
Hello! I've written some quick code to compute the multiplicative inverses of cycle index series when that is possible and added a _div_ method to CycleIndexSeries. This code is available as a patch on Trac ticket #14350 [1]. I'd very much appreciate any feedback on this code and/or your support to bring it into Sage! --Andrew [1] http://trac.sagemath.org/sage_trac/ticket/14350 signature.asc Description: OpenPGP digital signature
[sage-combinat-devel] Re: WARNING: Docbuilder patch (#6495) going into combinat
You might have to add the patches from the dependency tickets listed at #6495. All of the patches listed on the ticket are already included BUT there is also a dependency on 5.7.beta2, so I guess that in the series file the guards should really be trac_6495-part1-moving-files-link.patch #+5_8_beta0 #-5_7_beta2 trac_6495-part2-everything-else.patch #+5_8_beta0 #-5_7_beta2 ... Unfortunately, the queue still won't apply to 5.6 even with these guards in place because later the patches which rely on #6495 now fail. As a result, I don't see an easy way to make the queue apply to both 5.6 and 5.7.beta2+. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Help in unconfusing hg and myself
Hello! I'm trying to push patches for #13605-review and #1410[34] but I seem to have screwed up where hg thinks home is. I think that what I must have done is somehow got hg to sync with a local repository rather than with the queue. The reason that I think this might be the problem is that ``hg log`` returns a list of changesets with the user being me even though I have nothing so do with the associated patches. I have tried ``sage -combinat qselect`` but I am not able to sync because: sage -hg qpop -a abort: popping would remove an immutable revision (see hg help phases for details) Nothing in the help on phases or on phase helped. Trying ``qpop -f`` doesn't move the queue either. Does anyone have any ideas as to how I can fix this? Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Permutations... again.
the documentation doing sage -docbuild reference html (with again hundreds of modified files again!!!) I haven't found this to be so painful. I move my patch to the place in the queue where I want it. I then try to reapply the queue. If something beaks I'll rebase the patch if it is obvious, especially if the patch is a slow patch (I'm never entirely comfortable rebasing other people's patches as officially this is frowned upon but it's easy and it keeps the queue healthy I do it and hoped not be get flamed. If the rebase looks too tricky then I put a guard on the patch. Once the queue applies I check to see if sage builds and usually it does. Once or twice I have had to track down a patch that is breaking the queue, but the error messages combined with a grep of the patch directory often identifies the culprit quite quickly. Once a horribly broke the queue. When it became clear that I couldn't fix it quickly I posted on sage-combnat for suggestions ad the issue was soon resolved. I agree that it would be good to make this process more efficient. Some are saying that the move to git will fix this (this is not reallty clear as some of this posts make it sound like git will even write the code for us). There was also a recent suggestion to have different themes in the combinat queue. Perhaps this would be an improvement. By in large, however, I think that the currently workflow is OK. If anything, once you get use to using hg, I think that the main issue is the (volunteer) review process. So far this has been ok for me (that Travis!), but I have a few patches sitting off the queue which may not be so lucky. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Bug in CombinatorialObject?
Hi, I came across this today: sage: Partition(1) Traceback (most recent call last) ... TypeError: 'sage.rings.integer.Integer' object is not iterable sage: Tableau(1) Traceback (most recent call last) ... TypeError: 'sage.rings.integer.Integer' object is not iterable Even though in both cases the input is clearly garbage, I think that this is a bug because rather than failing ungracefully like this I think that a ValueError should be raised with an error message identifying the garbage input. (For what it's worth, I came across this when this error broke some of my code which was expecting a ValueError in such situations. Of course, I could also trap a TypeError and maybe another 20 possibilities but it would be better if I knew what error to expect.) In both cases, the source of this problem iis that in CombinatorialObject.__init__ we have if isinstance(l, list): self._list = l else: self._list = list(l) but it is never checked that ``l`` can be turned into a list. On top of this, Tableau(), Partition() -- and I suspect many others -- never check to see if their calls to CombinatorialObject.__init__ (and Element.__init__) actually work. If CombinatorialObject.__init__ raises a ValueError I can live with the latter. Please let me know if you think this is not a bug. If the consensus is that this is a bug the I will open a ticket and post a patch sometime next week. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Bug in CombinatorialObject?
On Sunday, 10 February 2013 03:37:01 UTC+11, Simon King wrote: Hi Anne, On 2013-02-09, Anne Schilling an...@math.ucdavis.edu javascript: wrote: Please let me know if you think this is not a bug. If the consensus is that this is a bug the I will open a ticket and post a patch sometime next week. Yes, this looks like a bug. I don't think so. A ValueError should be raised on wrong values of the right type, and a TypeError should be raised on arguments of wrong type. This is the case here, and this is also the case in many other occasions, such as: sage: P.x,y = ZZ[] sage: P(1/2) Traceback (most recent call last): ... TypeError: Could not find a mapping of the passed element to this ring. So, no bug, but a behaviour that is consistent with the rest of Sage. I misdescribed how I came across the error. It is: sage: 1 in Tableaux() Traceback (most recent call last) ... TypeError: 'sage.rings.integer.Integer' object is not iterable which I think is definitely a bug. Simon is saying above that this is not a bug in CombinatorialObject because a TypeError is the right error to raise, but I think that this misses the point: I think that CombinatorialObject should raise an error when it gets bad input rather than letting something else fail later as a consequence. Whether it should raise a TypeError or a ValueError is a separate issue. Cheers, Andrew ps. Blizzards nothwithstanding, I hope to be in ICERM. My plane leaves later today:) -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Partition and tableau options in #13605
Hi Anne, Thanks for your comments! Wouldn't it suffice to have a deprecation for sage.combinat.partition in /combinat/partition.py and have an alias there to sage.combinat.partition.partition. That would hopefully not be too much deprecation work at all since the UI does not change. Given the dearth of replies, it is probably not worth the effort to rearrange the code as several files would be affected...but in any case, I couldn't see a way to deprecate a whole module like this. How do you do it? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Sage-combinat won't run with #12940 applied
On Thursday, 24 January 2013 20:31:36 UTC+11, Anne Schilling wrote: Perhaps it should be disabled since *everyone* will have to remove those files (which is annoying). I am not sure. Following Hugh's hint, I found that sage -sync-build took care of the problem. A -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/maFK-VHmLBYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Sage-combinat won't run with #12940 applied
Hi All, I have just disabled #12940 because when trac_12940_affine_permutations-td.patch is applied and you start sage you hit the error: *snip* --- 26 from affine_permutations import AffinePermutationGroup 27 28 #PerfectMatchings ImportError: cannot import name AffinePermutationGroup Error importing ipy_profile_sage - perhaps you should run %upgrade? WARNING: Loading of ipy_profile_sage failed. With #12940 out of the queue, everything applies, builds and runs so I have disabled this patch. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/Z55Xi2hU8YYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Sage-Combinat poster
Thanks Nicolas! The poster looks good. Andrew On Monday, 14 January 2013 07:50:55 UTC+11, Nicolas M. Thiery wrote: Hi Anne, On Sun, Jan 13, 2013 at 09:21:10AM -0800, Anne Schilling wrote: Very nice! Thanks! I like that you put the car with the tail. :-) I should add Andrew to the contributors to the poster! One comment: perhaps it would be a good idea to put sagetex on the server, so that people without it can still latex the source. They are already in the poster's directory, so in principle the compilation should work as is (it worked for Florent). Cheers, Nicolas -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/aSmyHR4QZoYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Problem with CombinatorialFreeModule when queue is applied
Hi Everyone,
Something in the sage-combinat queue appears to be break
CombinatorialFreeModule.
Using the unpatched version of sage 5.5 I get the following expected
behaviour:
--
| Sage Version 5.5, Release Date: 2012-12-22 |
| Type notebook() for the browser-based notebook interface.|
| Type help() for help.|
--
sage: CombinatorialFreeModule(QQ, [4,3,2,1]).sum_of_terms([(i,i) for i in
[4,3,2,1]])
B[1] + 2*B[2] + 3*B[3] + 4*B[4]
If I now apply the complete queue and try exactly the same command then we
get the AttributeError below.
It's late in Sydney so I haven't tracked down the patch which is causing
the problem...but my guess is that (fixing and) unguarding
trac_7980-multiple-realizations-nt.patch might help?
Cheers,
Andrew
---
The broken CombinatorialFreeModule call:
--
| Sage Version 5.5, Release Date: 2012-12-22 |
| Type notebook() for the browser-based notebook interface.|
| Type help() for help.|
--
Loading Sage library. Current Mercurial branch is: combinat
sage: CombinatorialFreeModule(QQ, [4,3,2,1]).sum_of_terms([(i,i) for i in
[4,3,2,1]])
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (151, 0))
---
AttributeErrorTraceback (most recent call last)
/usr/local/src/sage/sage-5.5/devel/sage-combinat/sage/combinat/ipython
console in module()
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/IPython/Prompts.pyc
in __call__(self, arg)
550
551 # and now call a possibly user-defined print mechanism
-- 552 manipulated_val = self.display(arg)
553
554 # user display hooks can change the variable to be
stored in
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/IPython/Prompts.pyc
in _display(self, arg)
576 return IPython.generics.result_display(arg)
577 except TryNext:
-- 578 return self.shell.hooks.result_display(arg)
579
580 # Assign the default display method:
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/IPython/hooks.pyc
in __call__(self, *args, **kw)
139 #print prio,prio,cmd,cmd #dbg
140 try:
-- 141 ret = cmd(*args, **kw)
142 return ret
143 except ipapi.TryNext, exc:
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/misc/pretty_console_print.pyc
in result_display(ip_self, obj)
110 # IPython's default result_display() uses the
IPython.genutils.Term.cout stream.
111 # See also local/lib/python2.6/site-packages/IPython/hooks.py.
-- 112 f_tmp( ip_self, obj )
113
114 def displayhook( obj ):
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/misc/pretty_console_print.pyc
in pretty_display(ip_self, obj)
100 # IPython's default result_display() uses the
IPython.genutils.Term.cout stream.
101 # See also local/lib/python2.6/site-packages/IPython/hooks.py.
-- 102 print IPython.genutils.Term.cout, pretty_console_repr( obj )
103
104 f_tmp = pretty_display
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/misc/pretty_console_print.pyc
in pretty_console_repr(elem)
142 return pretty_repr_set( elem )
143 if hasattr( elem, __pretty_repr__ ):
-- 144 return elem.__pretty_repr__()
145 return PrettyConsoleRepr( repr(elem).splitlines() )
146
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/misc/pcp_monkey_patch.pyc
in __pretty_repr__(self)
164 all_atomic = True
165 for (monomial,c) in terms:
-- 166 b = repr_monomial(monomial) # PCR
167 if c != 0:
168 break_points = []
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/misc/pcp_monkey_patch.pyc
in _pretty_repr_term(self, el)
71 o
72
--- 73 if el == self.one_basis():
74 return PrettyConsoleRepr( [1])
75 pref = PrettyConsoleRepr( [self.prefix()] )
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.__getattr__ (sage/structure/parent.c:6081)()
/usr/local/src/sage/sage-5.5/local/lib/python2.7/site-packages/sage/structure/misc.so
[sage-combinat-devel] Re: conflicts in 5.5.rc0
Sorry, that's be me. Fixed now. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/IjdTpTChI6cJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] partitions
Hi Alex, The best/easiest way is probably to use the max_slope option for Partitions: sage: Partitions(16,max_slope=-1)[:] [[16], [15, 1], [14, 2], [13, 3], [13, 2, 1], [12, 4], [12, 3, 1], [11, 5], [11, 4, 1], [11, 3, 2], [10, 6], [10, 5, 1], [10, 4, 2], [10, 3, 2, 1], [9, 7], [9, 6, 1], [9, 5, 2], [9, 4, 3], [9, 4, 2, 1], [8, 7, 1], [8, 6, 2], [8, 5, 3], [8, 5, 2, 1], [8, 4, 3, 1], [7, 6, 3], [7, 6, 2, 1], [7, 5, 4], [7, 5, 3, 1], [7, 4, 3, 2], [6, 5, 4, 1], [6, 5, 3, 2], [6, 4, 3, 2, 1]] Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/muZq70Aamw4J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] partitions
Oops, sorry I didn't see your length requirement: sage: Partitions(16,max_slope=-1, length=4)[:] [[10, 3, 2, 1], [9, 4, 2, 1], [8, 5, 2, 1], [8, 4, 3, 1], [7, 6, 2, 1], [7, 5, 3, 1], [7, 4, 3, 2], [6, 5, 4, 1], [6, 5, 3, 2]] sage: Partitions(10,max_slope=-1, length=3)[:] [[7, 2, 1], [6, 3, 1], [5, 4, 1], [5, 3, 2]] Andrew On Friday, 14 December 2012 20:15:49 UTC+11, Andrew Mathas wrote: Hi Alex, The best/easiest way is probably to use the max_slope option for Partitions: sage: Partitions(16,max_slope=-1)[:] [[16], [15, 1], [14, 2], [13, 3], [13, 2, 1], [12, 4], [12, 3, 1], [11, 5], [11, 4, 1], [11, 3, 2], [10, 6], [10, 5, 1], [10, 4, 2], [10, 3, 2, 1], [9, 7], [9, 6, 1], [9, 5, 2], [9, 4, 3], [9, 4, 2, 1], [8, 7, 1], [8, 6, 2], [8, 5, 3], [8, 5, 2, 1], [8, 4, 3, 1], [7, 6, 3], [7, 6, 2, 1], [7, 5, 4], [7, 5, 3, 1], [7, 4, 3, 2], [6, 5, 4, 1], [6, 5, 3, 2], [6, 4, 3, 2, 1]] Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/p637RNmLhOcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: problems with documentation build
I am using macosx 10.7.5 and firefox 17.0.1 and the page displays properly for me. So the problem is also operating system dependent. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/0NEjtuUHIx0J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
I will do reverse lex (lex order read from right to left) and reverse
dominance (which I presume is partial sums from right to left). However
what is reverse containment?
AH, I guess that reverse lexicographic is ambiguous as it could mean
either reading the words in the reverse order or simply reversing the
partial order.
For me, and what I meant with all of these orderings, is simply taking the
same order but in the reverse order:
x \le_{rev} y == y \le x
Of course, this is a very trivial difference but it is still a significant
one in terms of the poset and the order in which the partitions are
generated. In my work, the reverse orderings in this sense play a very
important role: they reflect contragredient duality and also the duality
arising from tensoring with the sign representations.
I have never seen an application of the right to left lexicographic
ordering, although I have this vague feeling that it appears in Stanley's
book (but then, so do most things!:). I don't remember ever seeing the
right to left dominance order...
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/YN8MMBbDsgsJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Hi Travis, I have twos questions about the order options that have appeared in your partition clean-ups. The easy one first: should the reverse ordering also exist? That is, reverse lex, reverse dominance, reverse containment? If people agree that it is worth including these explicitly it would be good if there was a systematic way to organise all of the orderings...will let you know if I come up with something. The second question is harder: is it intended that, ultimately, the order in which the partitions are generated by the iterator will be compatible with the order on the parent? If the ordering is part of the parent then I think that this is a reasonable expectation but, of course, it would be painful implement. What do people think is the ideal way this should work for any parent that comes equipped with an (optionable) ordering? Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/wjZucoM2tB8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Partition options and cleanup patch
Basically you would like the iterator to return a linear extension of the ordering? That might be possible if by considering the poset given by the partial order. Yes, that's right. This is most sensible for total orderings, but for partial orders the iterator could return a non-canonical (and presumably not completely guaranteed) linear extension. I think that this would be a useful feature, unfortunately, to do it efficiently would probably require separate iterators for each ordering. Throwing efficiency to the wind, you could of course generate any FiniteEnumerateSet component and then sort this using the already implemented comparision methods. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/jRCWedLaWS8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: End(CombinatorialFreeModule)?
I think that without some extra information this is bound to be difficult. For the modules that I am working with at the moment I can do this and I am in the process of making this more explicit. The modules that I am working with have the following features which make this tractable: - they are cyclic: G = zA for some z (they are all A-modules) - (more importantly) I have a presentation for the modules - the presentation that I have is very efficient in the sense that if I am looking for maps f:G-H then the dimension of the vector subspace of H which can contain f(z) is quite small. This makes it tractable to look at the kernel of the modules relations on this subspace to find a basis for Hom_A(G,H). Currently, I have code which computes a basis for Hom_A(G,H) and returns sage morphisms f:G-H which you can apply to either arbitrary elements of G or to the indexing set of the basis for G. Next I plan to have the the code automatically write compositions f*g in terms of the distinguished bases that I have for these hom-spaces. As a special case, of course, I can compute End_A(G) an work with this. (Although for my examples this is only interesting in characteristic 2.) Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/HeFrlWzYFXQJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: combinat out again?
Are they related to Sage combinatorics research? Of course, otherwise I wouldn't ask. (I'm computing the graded dimensions of simple modules and the graded dimensions of hom-spaces (for some reducible modules).) Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/YgHntXOrxdYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Constructing homs
- Matrices with rows and columns indexed by whatever objects I have a (very) rough prototype for this as it is one of the things that I need. Rather than matrices, however, I am thinking of making the underlying object just an array/table as for my applications the full matrix is often not known and more entries are added as the calculations proceed whereas matrices are immutable. Perhaps I should finally learn about these cloneable arrays... - Morphisms between two finite dimensional free modules G and H (using the above) with arithmetic, ... For what I am doing at the moment the following would be useful: - MorphismOfCombinatorialFreeModule - HomSpaceWthBasis - MorphismFromCyclicModule and graded versions of all of the above. I mainly care about (graded) homs between CombinatorialFreeModules and i f is such a hom, and t indexes a basis element of G then I'd like to have f(t)=f(G(t)). I have a hacked version of this, combining the three categories above, for my modules, without that many features. I'll have make this palatable for human consumption before I release this code:) I.e. the analogue of sage.modules.matrix_morphism.MatrixMorphism. - A parent for those. I.e the analogue of sage.modules.free_module_homspace.HomSpace What would be missing would be the shortcuts so that we could just do Hom(G,H), as well as generic methods that could be shared between. I think that I still don't really undestand what Hom(G,H) represents inside sage. Is it simply supposed to be the parent for all homs from G to H? Typically, it seems to me that Hom(G,H) doesn't -- and, in fact, can't -- do very much: if G and H are (free) modules then Hom(G,H) is just a bunch of matrices, which is easy. But if G and H have any extra structure which these homs should preserve then there often won't even be an algorithm for computing Hom(G,H), and in many cases there won't even be a practical algorithm for determining when a linear map belongs to Hom(G,H). So what is Hom(G,H) suppose to do? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/29S9CF9anMwJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Constructing homs
huh? sage: m=matrix([[1,2],[3,4]]) sage: m [1 2] [3 4] sage: m[1,1]=100 sage: m [ 1 2] [ 3 100] sage: Yes, you're right. My issue with matrices is that I can't write something like: sage: matrix([[1,0],[None,0]]) (Unless, of course, you want to correct me again:) A. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/6Qm7YHqf5g8J. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Constructing homs
Here's a related question: suppose I have an object G in sage. Is there a correct way to ask G if is it a CombinatorialFreeModule? I can check for if hasattr(G,'_basis_keys'): ... but I would have thought that there was a better way to do this... Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/8axqoe8vKCQJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Constructing homs
Yes, I worked it out and deleted my question bot before you replied it seems. Thanks anyway, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/wWxrvtdzHRoJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Constructing homs
Good morning! I have been trolling through the manuals trying to understand
how to construct a basis for a hom-space but I keep going around in
circles. Can anyone help me out?
I have two CombinatorialFreeModules G and H which are modules for some
algebra A. (The algebra A is not implemented in sage, although its action
on G and H is.) The module G is cyclic, generated by z say, so every
homomorphism f:G-H is determined by f(z). The basis of G takes the form
{G(t) = z.psi( t )}, where t runs through a set of tableaux. (In case you
are interested, G and H are Specht modules.) That is, the psi method tells
me how to write G(t)=z*\phi_t so that f(G(t))=f(z).psi(t) as H also has a
psi method.
I can construct a set of elements {h_1,...,h_d} in H such that the maps
{f_1,,f_d} determined by f_i(z)=h_i, for 1\le i\le d, is a basis for
Hom_A(G,H).
My questions are: how do I construct the maps f_i in sage and how do I tell
sage that these maps are a basis of Hom_A(G,H)?
Cheers,
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/AacB6s8D0U8J.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Constructing homs
Thanks Nicolas. I appreciate your efforts in putting the category framework in place! It's beginning to grow on me:) Depending how far my explorations go I may end up adding some of the missing pieces... A. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/5wsvHl8VwcYJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] combinat out again?
Is there any news on when sage-combinat is likely to be up again? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/SZXjOtU8BhoJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: tableaux in 5.4.1
Hi Anne,
The problem appears after trac_13605-partition_options-ts.patch is applied.
Andrew
--
--
| Sage Version 5.4.1, Release Date: 2012-11-15 |
| Type notebook() for the browser-based notebook interface.|
| Type help() for help.|
--
Loading Sage library. Current Mercurial branch is: combinat
sage: StandardTableaux(3).list()
[[[1, 2, 3]], [[1, 3], [2]], [[1, 2], [3]], [[1], [2], [3]]]
sage:
Exiting Sage (CPU time 0m0.03s, Wall time 0m25.64s).
combinat: sage -hg qpush
applying trac_13605-partition_options-ts.patch
now at: trac_13605-partition_options-ts.patch
combinat: sage -br
...
--
| Sage Version 5.4.1, Release Date: 2012-11-15 |
| Type notebook() for the browser-based notebook interface.|
| Type help() for help.|
--
Loading Sage library. Current Mercurial branch is: combinat
sage: StandardTableaux(3).list()
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (505, 0))
---
NotImplementedError Traceback (most recent call last)
/usr/local/src/sage/sage-5.4.1/devel/sage-combinat/sage/combinat/ipython
console in module()
/usr/local/src/sage/sage-5.4.1/local/lib/python2.7/site-packages/sage/combinat/tableau.pyc
in list(self)
2566 NotImplementedError
2567
- 2568 raise NotImplementedError
2569
2570 def __iter__(self):
NotImplementedError:
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/k-UpGbWMyOoJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: tableaux in 5.4.1
Sorry, correction: there are currently two problems with the queue: - trac_13605-partition_options-ts.patch causes StandardTableaux() and friends to die. - finite_semigroup-nt.patch is causing the weakref warnings. (In fact, sage won't run when the queue is applied up to this patch but applying the next patch in the queue fixes this.) Btw, rebuilding sage after moving up and down the queue is taking a huge amount of time now. Does anyone know why? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/2utdr9B9giQJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
YES, but if you were working with the Sage TRAC server the patches would HAVE to be finalised. Please please, that's the whole point ! Nathan, I think that this is the whole point that you are not seeing: we do work with sage and we do use trac. Extensively. Personally, I want my patches posted to trac as quickly as possible and merged into sage. Andrew ps As I am sure you know, putting a patch up on trac in no way guarantees that it will ever be finalised. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/m7NE3uytN6YJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Permutations... again.
H Nathan, I share your frustrations. I think we all do, to some extent. It would be very nice if all of these problems, major an minor, could be fixed but the reality is that until some one cares enough about a particular problem then, as you say, it isn't going to happen. I think this is called open-source. The absent or poor documentation is what I like least about sage. It's annoying that quite a lot of basic things need to be implemented and that others have been done badly. I have fixed the things that I really need, or worked around them. The responsiveness of sage-devel and sage-combinat is nice. I switched to sage because it is the best platform that I found. Sure, many things could be better, but I don't like gap4, magma, malple, mathematica, matlab, C, ... In spite of its many warts and problems I do like writing in python and working with sage. Using sage, I have been able to compute things much more quickly and painless than before when I was writing in gap. I'm happy with that. Does anyone have any *concrete suggestions* for how we could improve the development model? There is definitely room for improvement but short of paying someone I don't have any good suggestions. The problem is that what I want implemented is often different to what everyone else wants, but thankfully there is some overlap and so some give and take. Ideas anyone? Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/eSgox25xV_cJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
