[sage-combinat-devel] Re: Paper publication of the book "Calcul Mathematique avec Sage"
Congratulations! This reminds me that I need to work on my paper interface to the Sage Cell Server. :) On Wednesday, June 12, 2013 12:18:21 AM UTC+3, Dox wrote: > > Great work! Congratulations! > -- 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 problem in the new permutation groups code (and a solution ?)
'Allo! On Tuesday, March 26, 2013 1:34:32 PM UTC+3, Volker Braun wrote: > > The group action framework is just the implementation, you still haven't > answered the question that this thread was about: Should permutation > actions on nested containers automatically discover one possible action or > not. As you said, in the group action framework you can implement either > possibility. You can also implement either if you don't use it. > Yeah, I was thinking that because of the ambiguity that was being discussed in dealing with the nested actions, the best approach would be to provide a simple framework for specifying actions, and easy-to-access examples of That Sort of Thing, for people interested in using it, rather than putting in an implementation which half of users will think is mussed up. I'll be at the Sage-Combinat days in June; helping to build out the action code that others have already started developing sounds like a great way to spend at least a chunk of that week. -- 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: a problem in the new permutation groups code (and a solution ?)
oops, here's the code! I keep getting server erros when trying to attach as a file, so I'm just including the text of the code file below: class GroupAction(Parent): def __init__(self, G, S, phi): #phi a group action G\times S \rightarrow S self.phi=phi self.G=G self.S=S def __repr__(self): return "Action of "+self.G.__repr__()+" on the set "+self.S.__repr__() def action(self, g, s): """ Gives the action of g on s. """ return self.phi(g,s) def group(self): """ Group which acts. """ return self.G def gset(self): """ Set on which the group acts. """ return self.S def action_function(self): """ Function from `G\times S \rightarrow S`. """ return self.phi def check_action(self, g, h, s): """ Checks whether g(hs)=(gh)s. """ return self.phi(g*h,s)==self.phi(g,self.phi(h,s)) def check_action_full(self, gens=None, contragradiant=False): """ Checks that this is actually a group action using a generating set for the group acting on the full set. """ assert self.S.is_finite(), 'Cannot check group action on an infinite set.' if gens==None: #Should check if g has gens implemented. gens=self.group().gens() for g in gens: for h in gens: for s in S: if contragradiant: if not self.phi(g*h,s)==self.phi(g,self.phi(h,s)): stringy=g.__repr__()+', '+h.__repr__()+' '+s.__repr__() assert False, 'Action fails on '+stringy else: if not self.phi(h*g,s)==self.phi(g,self.phi(h,s)): stringy=g.__repr__()+', '+h.__repr__()+' '+s.__repr__() assert False, 'Action fails on '+stringy return True def orbit(self, s): return Set([self.action(g,s) for g in self.group()]) def is_transitive(self): if len(self.gset())==0: return True s=self.gset()[0] return orbit(s)==Set(self.gset()) def twist(self, endomorphism): """ Twists this representation by an endomorphism of the group. """ phi=self.action_function() kappa=lambda g,s: phi( endomorphism(g), s) return GroupAction(self.G, self.S, kappa) def character(self): """ Count fixed points for conjugacy class representatives. """ c=[] for g in self.G.conjugacy_classes_representatives(): fix=0 for s in self.S: if self.action(g,s)==s: fix+=1 c.append(fix) return c def cayley_graph(self, gens=None): """ Builds a cayley graph of the group action, using the specified generating set. """ assert self.S.is_finite(), 'Cannot check group action on an infinite set.' if gens==None: #Should check if g has gens implemented. gens=self.group().gens() G=DiGraph() for g in gens: for s in self.gset(): G.add_edge( s, self.action(g,s) ) return G def product_action(self, B): """ Given a second group action B with the same group and set T, generates the product group action of self and B. """ assert self.group()==B.group(), 'Actions need to have same group acting.' T=B.gset() U=CartesianProduct(self.gset(),T) kappa=lambda g, u: U( [self.action_function()(g,u[0]), B.action(g,u[1])] ) return GroupAction(G,U,kappa) """ #Example 1: Usual symmetric group action. sage: G=SymmetricGroup(4) sage: S=Set([1,2,3,4]) sage: phi = lambda g,s: g(s) sage: A=GroupAction(G,S,phi) sage: A.character() [4, 2, 0, 1, 0] #Example 2: Symmetric group acting on a set. sage: rho=lambda g,s: Set([phi(g,t) for t in s]) sage: T=Subsets(S,2) sage: B=GroupAction(G,T,rho) sage: B.character() [6, 2, 2, 0, 0] #Example 3: Product action. sage: C=A.product_action(B) sage: C.character() [24, 4, 0, 0, 0] #Example 4: Twist by an automorphism. sage: a=G.an_element()^2 sage: ai=a.inverse() sage: auto=lambda g: a*g*ai sage: At=A.twist(auto) sage: y=G.simple_reflection(1) sage: [A.action(y,s) for s in S] [2, 1, 3, 4] sage: [At.action(y,s) for s in S] [1, 2, 4, 3] """ -- 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/gr
[sage-combinat-devel] Re: a problem in the new permutation groups code (and a solution ?)
Specify the action! By making a group action framework, we would also be
providing the possibility of changing the action to something contrary to
the assumptions of the original developers Yes, in fact I think this is
one of the natural reasons for doing an explicit group action framework.
Even for the action of S_n on the set {1,2,3,...,n} one can twist the
'usual' action with an automorphism \phi of S_n, so that \sigma acts on i
by \phi(\sigma)(i).
The 'usual' actions then become special predefined objects, like the
special graphs, maybe summoned up automatically using the
permutation/whatever's __call__ function if it's an idiomatic action like
\sigma(3).
As a category, I would imagine we would have a GroupAction category and/or
a GroupWithAction category, which would put some requirements on the group
and its elements.
I've attached a bit of sample code, which could be used as a base to start
a group action category. (Currently just a class, as I need to go and read
the category tutorials, though...) The examples are at the bottom;
includes products of actions, twisting by a group endomorphism, computing
characters, orbits, checking the action definition, checking transitivity,
and generating the Cayley graph of the action for a given generating
set.
On Monday, March 25, 2013 2:30:57 PM UTC+3, Volker Braun wrote:
>
> The group action category stuff would be nice, but you would run into
> exactly the same question that Dima asked: What are you going to do if
> there is more than one possible action. You'll have to either use some
> heuristics (take the simpler / less nested action) or raise some exception
> telling the user to explicitly disambiguate between them.
>
>
>
> On Monday, March 25, 2013 8:33:57 AM UTC+1, tom d wrote:
>>
>> Hm, wouldn't this just be a direct product of the individual group
>> actions? It seems to me that we're expecting the permutations to act
>> according to an 'obvious' group action. Should we also expect 'obvious'
>> actions of things like a dihedral group when given a 2-dimensional vector?
>> Probably the answer is to generalize and build up a proper group actions
>> category (with obvious methods passing to representations!).
>
>
--
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: a problem in the new permutation groups code (and a solution ?)
Hm, wouldn't this just be a direct product of the individual group actions? It seems to me that we're expecting the permutations to act according to an 'obvious' group action. Should we also expect 'obvious' actions of things like a dihedral group when given a 2-dimensional vector? Probably the answer is to generalize and build up a proper group actions category (with obvious methods passing to representations!). It looks like there's a bare semblance of a glimmer of the idea of actions in Sage: http://combinat.sagemath.org/doc/reference/categories/sage/categories/action.html but it's not very fleshed out One way to deal with the problem at hand would be to define a direct product of group actions and behave/coerce accordingly. This could look something like: 1) Look at the list of things the permutation is supposed to be acting on, like [1, Set([1,2])] 2) Build a group action parent for each of the components, which we then use to build a direct product parent 3) Return the appropriate element of the direct product. Such a framework would have the advantage of being there to deal with similar problems in other groups. cheers! On Friday, March 22, 2013 4:43:18 PM UTC+3, Volker Braun wrote: > > I think its unambiguous to define the orbit of x recursively as > 1. use the action on domain elements if x is a domain element > 2. otherwise, assume that the x is a list/set/... of domain elements > > > > On Thursday, March 21, 2013 3:10:38 PM UTC+1, Dima Pasechnik wrote: >> >> While working on http://trac.sagemath.org/sage_trac/ticket/14291, it >> came to my attention that one can now have permutation groups acting >> on quite arbitrary domains (the only requirement for the domain elements >> seems to be them being hashable). >> >> This leads to the following kind of confusing situations: >> suppose our permutation group G acts on, say, (1,2,3,4,(1,2),(2,3)). >> Then things like "the orbit (1,2) under G" can be interpreted in two >> different incompatible ways: >> * the images under G of the pair of domain elements 1 and 2. >> * the images under G of of the domain element (1,2). >> >> I can see two ways to remedy this: >> 1) a framework with parents, etc >> 2) "boxing" the most "primitive" elements of the domain, i.e. >> as in our example, using ((1),(2),(3),(4),(1,2),(2,3)) instead of >> (1,2,3,4,(1,2),(2,3)); then certainly ((1),(2)) and (1,2) are >> different things, problem solved. >> >> (and certainly you can tell me that actually it's OK as it is... :)) >> >> IMHO, 2) is relatively easy to put into place, and 1) is tricky and quite >> a bit of >> work. >> >> Dima >> >> -- 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] Reviewer for #12940?
I think Ticket #12940 is probably ready for review, at long last, if anyone can find a bit of time to look it over. It's a combinatorial implementation of the affine Weyl groups of types A,B,C,D and G. http://trac.sagemath.org/sage_trac/ticket/12940 cheers! -- 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: Sage-combinat Days in Paris
I'll be at both FPSAC and the combinat meeting, and in my infinite wisdom just realized I missed the funding deadline for main fpsac. Is there a sense of whether the meeting will be in Paris or Orsay yet? (It has some obscure bearing on the question of whether I have a free roof to sleep under that week.) On Tuesday, March 12, 2013 4:01:54 AM UTC+3, Anne Schilling wrote: > > Dear Sage-combinat Community! > > Nicolas Thiery, Alejandro Morales and I are going to organize Sage Days 49 > in Paris June 17th-21st 2013. For more details see: > > http://wiki.sagemath.org/combinat/FPSAC13 > > For people from US institutions: We have some funds for travel and lodging > from our Sage-NSF grant. If you are applying for funding from FPSAC, > you can also indicate on the FPSAC funding website that you are going to > attend > the Sage Days (and indicate funding requests). Alternatively, you can send > your cv and estimated travel costs to me by March 30. > > Hope to see you all in Paris in June, > > 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.
Re: [sage-combinat-devel] queue broken?
Ok,thanks! Just today there was another broken spot in the queue. (I upgraded to 5.8rc0 just in case, too.) I was wanting to rebase my affine permutations patch for the new documentation system so that it can finally get a review, and it was under the broken patch, so I just made the fixes and pushed... hope that's ok. applying trac_12876_category-fix_abstract_class-nt-rel11521.patch patching file sage/categories/homset.py Hunk #6 FAILED at 261 1 out of 11 hunks FAILED -- saving rejects to file sage/categories/homset.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_12876_category-fix_abstract_class-nt-rel11521.patch Abort On Saturday, March 16, 2013 12:57:22 AM UTC+3, Anne Schilling wrote: > > Hi Tom, > > Yes, I got the same error with sage-5.8.bet4. I rebased Ben Salisbury's > patch. > It should work now. > > Ben, please pull from the sage-combinat server before you keep working on > your patch! > > Best, > > Anne > > On 3/15/13 2:51 PM, tom d wrote: > > From tonight's attempt to apply the queue in Sage 5.7rc0: > > > > > > applying trac_4327-root_system_plot_refactor-nt.patch > > patching file sage/combinat/root_system/type_affine.py > > Hunk #1 succeeded at 237 with fuzz 2 (offset -54 lines). > > applying trac_14143-alcove-path-al.patch > > applying trac_14192-infinity_crystal-bs.patch > > patching file sage/combinat/crystals/all.py > > Hunk #1 FAILED at 11 > > 1 out of 1 hunks FAILED -- saving rejects to file > sage/combinat/crystals/all.py.rej > > patch failed, unable to continue (try -v) > > patch failed, rejects left in working dir > > errors during apply, please fix and refresh > trac_14192-infinity_crystal-bs.patch > > > > > > This persists after trying to qselect guards and recloning the combinat > branch. Is this happening for others or do I need to suck it up and move > on to true 5.7? > -- 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] queue broken?
>From tonight's attempt to apply the queue in Sage 5.7rc0: applying trac_4327-root_system_plot_refactor-nt.patch patching file sage/combinat/root_system/type_affine.py Hunk #1 succeeded at 237 with fuzz 2 (offset -54 lines). applying trac_14143-alcove-path-al.patch applying trac_14192-infinity_crystal-bs.patch patching file sage/combinat/crystals/all.py Hunk #1 FAILED at 11 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/crystals/all.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_14192-infinity_crystal-bs.patch This persists after trying to qselect guards and recloning the combinat branch. Is this happening for others or do I need to suck it up and move on to true 5.7? -- 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: Longest element in a Coxeter Group - name decision
I think longest_element is fine; long_word indicates that there will be a word returned instead of an element, which is maybe not what we're after here. Wiser minds than mine will have more knowledge of how to handle deprecation, but here's an example from skew_partition.py: sage: x.r_quotient?? Type: instancemethod String Form: File: /home/kaibutsu/sage-5.7/local/lib/python2.7/site-packages/sage/combinat/skew_partition.py Definition: x.r_quotient(self, length) Source: def r_quotient(self, length): """ This method is deprecated. EXAMPLES:: sage: SkewPartition([[3, 3, 2, 1], [2, 1]]).r_quotient(2) doctest:1: DeprecationWarning: r_quotient is deprecated. Use quotient instead. See http://trac.sagemath.org/5790 for details. [[[3], []], [[], []]] """ from sage.misc.superseded import deprecation deprecation(5790, 'r_quotient is deprecated. Use quotient instead.') return self.quotient(length) On Tuesday, March 5, 2013 12:37:17 PM UTC+3, Kannappan Sampath wrote: > > Hello friends, > > I am writing this mail to ask for your help in a naming decision. > In the file sage/categories/finite_coxeter_groups.py, there is a function > called long_element. The docstring asks if this should be renamed and if > so, to what? > > There are two suggestions from the authors: longest_element, > maximal_element. > > Now, I think "longest_element" is pretty common. But, LiE, Marc's Lie > Group computation software seems to call this `long_word()`. > > 1) what should we pick? > > 2) I started a ticket to clean up this file on trac: > http://trac.sagemath.org/sage_trac/ticket/14050 > > I understand that name changes are to be handled with care. How do we go > about this one? Deprecate? > > With Sincere Regards, > Kannappan. > -- 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: combinat installation fails on sage-5.7 (fixed)
Ok, thanks for the quick fix! On Sunday, March 3, 2013 9:43:29 PM UTC+3, Nicolas M. Thiery wrote: > > Hi Tom > > On Sun, Mar 03, 2013 at 10:27:05AM -0800, tom d wrote: > >Yup, just hit this myself, also with a missing plot module? here's > my > >crash report: > > 44 To describe the embedding, a root lattice realization > must > > ImportError: No module named plot > > Oops, I forgot to add that file indeed. Sorry! > > Fixed and pushed. > > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" > > 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-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
Sorry, I was traveling and missed this. The file name has been changed to 'affine_permtation.py' as recommended, which should remove the headaches mentioned. On Thursday, January 24, 2013 1:14:01 PM UTC+3, Andrew Mathas wrote: > > > > 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 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. 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: sage combinat on 5.5
Thanks! That did the trick. (And I've folded in your fix patch, Anne.) On Tuesday, January 22, 2013 12:34:20 PM UTC+3, Anne Schilling wrote: > > Hi! > > In discussion with Christian Stump and Nicolas Thiery, I learned that the > way to fix a problem when sage remembers a wrong link (for example, > in Tom's case with affine permutations, he previously had the file > in a directory /combinat/affine_permutations/affine_permutations.py and > changed > it to a file in /combinat/affine_permutations.py), you need to remove the > old links by hand. > > Make a small change somewhere, run > > sage -br > > Then sage tells you where it puts the files. For me: > > ... > copying > build/lib.macosx-10.6-x86_64-2.7/sage/combinat/affine_permutations/affine_permutations.py > > -> > /Applications/sage-5.5/local/lib/python2.7/site-packages/sage/combinat/affine_permutations > > > copying > build/lib.macosx-10.6-x86_64-2.7/sage/combinat/affine_permutations/all.py > -> > /Applications/sage-5.5/local/lib/python2.7/site-packages/sage/combinat/affine_permutations > > > > I had to remove the directory affine_permutations in these directories by > hand. Then it works. > > Best, > > Anne > > > > > On 1/19/13 8:39 PM, Hugh Thomas wrote: > > > > Hi! > > > > The short explanation of the problem is that > sage/combinat/some_hopf_algebras/all.py was not importing parking functions > from the right place. It should have been using > > sage.combinat.parking_functions. I have added a patch > temporary_parking_import_fix-ht.patch which fixes this. Jean-Baptiste, > please feel free to fix the problem however you like and delete my > > patch. Martin, sage should now run okay with the queue installed. > > > > I had trouble replicating this issue, and for a reason that is a bit > interesting (I think). > > > > The point is that the import statement used to be right; the parking > functions files moved. And by default, sage does not clean up the old .py > and .pyc files from the old compilations, so they are > > still sitting in > local/lib/python2.7/site-packages/sage/combinat/some_hopf_algebra, and as > a result, sage is willing to import from them. If you want sage to remove > them when doing the rebuild, you > > have to tell it to. See #5977. > > > > cheers, > > > > Hugh > > > > On Saturday, January 19, 2013 10:29:20 AM UTC-4, Martin wrote: > > > > Hi there, > > > > I just installed sage 5.5 from source and then did > > > > sage -combinat install > > > > But now I get what's reproduced below. > > > > :-( What should I do? (upgrade does not work, since sage doesn't > start) > > > > Martin > > > > rubey@convex3:~/sage-5.5$ sage > > > -- > > | Sage Version 5.5, Release Date: 2012-12-22 > | > > | Type "notebook()" for the browser-based notebook interface. > | > > | Type "help()" for help. > | > > > -- > > > --- > > ImportError Traceback (most recent > call last) > > > > > /home/rubey/sage-5.5/local/lib/python2.7/site-packages/IPython/ipmaker.pyc > > in force_import(modname, force_reload) > > 61 reload(sys.modules[modname]) > > 62 else: > > ---> 63 __import__(modname) > > 64 > > 65 > > > > /home/rubey/sage-5.5/local/bin/ipy_profile_sage.py in () > > 5 preparser(True) > > 6 > > > 7 import sage.all_cmdline > > 8 sage.all_cmdline._init_cmdline(globals()) > > 9 > > > > > /home/rubey/sage-5.5/local/lib/python2.7/site-packages/sage/all_cmdline.py > > in () > > 12 try: > > 13 > > ---> 14 from sage.all import * > > 15 from sage.calculus.predefined import x > > 16 preparser(on=True) > > > > /home/rubey/sage-5.5/local/lib/python2.7/site-packages/sage/all.py > in > > () > > 106 > > 107 from sage.coding.all import * > > --> 108 from sage.combinat.all import * > > 109 > > 110 from sage.lfunctions.all import * > > > > > /home/rubey/sage-5.5/local/lib/python2.7/site-packages/sage/combinat/all.py > in () > > 152 from sidon_sets import sidon_sets > > 153 > > --> 154 from some_hopf_algebra.all import * > > 155 > > 156 #Affine Permutation Group(s) > > > > > /home/rubey/sage-5.5/local/lib/python2.7/site-packages/sage/combinat/some_hopf_algebra/all.py > > > > in () > > 1 > > > 2 from packed_words import PackedWord, PackedWords > >
[sage-combinat-devel] Re: Problem with the nilcoxeter algebra
Ok, thanks; I'll just stick to working lower in the queue for now then. On Saturday, January 19, 2013 3:28:20 PM UTC+3, tom d wrote: > > There's been a change to the init function for the Iwahori Hecke Algebra > that causes the NilCoxeterAlgebra to fail. I _think_ this is happening in > the affine_iwahori_hecke_algebras.patch; the nilcoxeter algebra is still > working fine with combinat unapplied. > > There's an extra parameter (omega) in the IwahoriHecke Algebra now, and > since the NilCoxeter is calling the __init__ function directly, it's > apparently expected to provide a value for this new parameter. I'm not > terribly sure if it's better to change the IHA constructor to not expect > the omega, or to change the Nilcoxeter to provide a value. > > Any thoughts? > > sage: W=WeylGroup(['A',5,1]) > sage: NilCoxeterAlgebra(W) > --- > TypeError Traceback (most recent call last) > > /home/kaibutsu/ in () > > /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/classcall_metaclass.so > > in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ > (sage/misc/classcall_metaclass.c:991)() > > /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/cachefunc.so > > in sage.misc.cachefunc.WeakCachedFunction.__call__ > (sage/misc/cachefunc.c:5077)() > > /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/structure/unique_representation.pyc > > in __classcall__(cls, *args, **options) > 464 True > 465 """ > --> 466 instance = typecall(cls, *args, **options) > 467 assert isinstance( instance, cls ) > 468 if instance.__class__.__reduce__ == > UniqueRepresentation.__reduce__: > > > > /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/classcall_metaclass.so > > in sage.misc.classcall_metaclass.typecall > (sage/misc/classcall_metaclass.c:1350)() > > /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/algebras/nil_coxeter_algebra.pyc > > in __init__(self, W, base_ring, prefix) > 63 self._base_ring = base_ring > 64 self._cartan_type = W.cartan_type() > ---> 65 IwahoriHeckeAlgebraT.__init__(self, W, 0, 0, base_ring, > prefix=prefix) > 66 > 67 def _repr_(self): > > TypeError: __init__() takes exactly 7 arguments (6 given) > > -- 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/-/yXgzT3koFCAJ. 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 the nilcoxeter algebra
There's been a change to the init function for the Iwahori Hecke Algebra that causes the NilCoxeterAlgebra to fail. I _think_ this is happening in the affine_iwahori_hecke_algebras.patch; the nilcoxeter algebra is still working fine with combinat unapplied. There's an extra parameter (omega) in the IwahoriHecke Algebra now, and since the NilCoxeter is calling the __init__ function directly, it's apparently expected to provide a value for this new parameter. I'm not terribly sure if it's better to change the IHA constructor to not expect the omega, or to change the Nilcoxeter to provide a value. Any thoughts? sage: W=WeylGroup(['A',5,1]) sage: NilCoxeterAlgebra(W) --- TypeError Traceback (most recent call last) /home/kaibutsu/ in () /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/classcall_metaclass.so in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (sage/misc/classcall_metaclass.c:991)() /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/cachefunc.so in sage.misc.cachefunc.WeakCachedFunction.__call__ (sage/misc/cachefunc.c:5077)() /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/structure/unique_representation.pyc in __classcall__(cls, *args, **options) 464 True 465 """ --> 466 instance = typecall(cls, *args, **options) 467 assert isinstance( instance, cls ) 468 if instance.__class__.__reduce__ == UniqueRepresentation.__reduce__: /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/misc/classcall_metaclass.so in sage.misc.classcall_metaclass.typecall (sage/misc/classcall_metaclass.c:1350)() /home/kaibutsu/sage-5.5/local/lib/python2.7/site-packages/sage/algebras/nil_coxeter_algebra.pyc in __init__(self, W, base_ring, prefix) 63 self._base_ring = base_ring 64 self._cartan_type = W.cartan_type() ---> 65 IwahoriHeckeAlgebraT.__init__(self, W, 0, 0, base_ring, prefix=prefix) 66 67 def _repr_(self): TypeError: __init__() takes exactly 7 arguments (6 given) -- 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/-/qzJfyqJpvlkJ. 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: k-Schur functions and affine Schubert calculus
Fantastic! Good to know there's a solid book I can point people to now for some background! On Thursday, January 17, 2013 6:24:05 AM UTC+3, Anne Schilling wrote: > > Hi All! > > Mike just posted our book on $k$-Schur functions and affine Schubert > calculus > on the arXiv ( http://arxiv.org/abs/1301.3569 ). It contains many Sage > examples. Thank you to everyone who helped to make this possible! > > Anne > > > > Thomas Lam, Luc Lapointe, Jennifer Morse, Anne Schilling, Mark Shimozono, > Mike Zabrocki > k-Schur functions and affine Schubert calculus > (Submitted on 16 Jan 2013) > http://arxiv.org/abs/1301.3569 > > This book is an exposition of the current state of research of affine > Schubert calculus and $k$-Schur functions. This text is based on a series > of lectures given at a workshop titled "Affine > Schubert Calculus" that took place in July 2010 at the Fields Institute in > Toronto, Ontario. The story of this research is told in three parts: 1. > Primer on $k$-Schur Functions 2. Stanley symmetric > functions and Peterson algebras 3. Affine Schubert calculus > -- 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/-/LLwyTd4hb38J. 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: comments on highlights for NSF
Hello! The write-up looks good! I have a bunch of stuff planned for the coming term incorporating Sage in Kenya and South Africa. Perhaps the line about Africa could be expanded to something like: 'The open nature of the Sage and Sage-Combinat projects encourages participation in developing countries like Kenya and Burkina Faso, increasing the breadth of the world mathematical community.' (I'm planning on doing a bunch of things around mathematical problem solving with Sage this coming term: we're giving a three week intensive course at AIMS in South Africa, and I'll be running a weekly seminar/problem solving session with undergrads in Kenya. We're also going to be strategically deploying some Raspberry Pi computers with secondary students, hopefully with Sage included if I can get it to compile! I'll also be running some sessions at an algebraic geometry conference in Mombasa in June. So there's stuff happening with Sage (and sage-combinat!) on the secondary, undergrad and post grad levels here in Kenya.) Best, -tom On Wednesday, December 12, 2012 3:40:35 AM UTC+3, Anne Schilling wrote: > > Hi All! > > We were asked by the NSF to provide a short report on our > sage-combinat project. It is supposed to be in simple language > and to be understood by a lay person. > > You can find the current version here: > > http://www.math.ucdavis.edu/~anne/highlights2012.pdf > > If you have any comments or suggestions for improvements, please > let me know (this grant so far funded Sage Days 40 at IMA in July 2012, > the new sage-combinat server as well as individual students and > research meetings). > > Thank you! > > Anne > -- 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/-/X-AeHAfNiFgJ. 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: Sage Days in Bobo-Dioulasso debriefing; Sage in developping countries
Hey, all; So the Mombasa algebraic geometry workshop is set for 6-28 July, 2013. Which is really long! They're interested in having some sage sessions; if anyone's interested in coming out I can plan to be there for an overlapping time and co-hosting the Sage sessions. (However, the first week I'll be in Ethiopia.) Basically, drop me a line and we can talk about scope and further details that should be nailed down. Best, -tom On Sunday, November 11, 2012 12:00:34 PM UTC+3, Nicolas M. Thiery wrote: > > Dear Sage devs, > > The fall school on Discrete Mathematics in Bobo Dioulasso, Burkina > Faso, aka Sage Days 43, just finished. For two weeks we had courses > (combinatorics of words, dynamics, tilings, ...) interspersed with > on-hands tutorials using Sage. The public consisted mostly from > graduate students, from subsaharian Africa and some further away > countries. > > That was a good occasion for a real-life evaluation of a claim I have > been desiring to make for a long time: �Sage, being open-source, is > well adapted for universities in developing countries�. > > Let's see about this. > > A couple words of context: > -- > > - 70 participants total; in average 40-50 were there. > - Most participants had a laptop (or netbook for a few of them): > - 90%: windows, 5% mac, 5% Linux Ubuntu (usually in double-boot with > Windows) > - Laptop age ranging from 2003 to 2012; 4 years on average > - RAM: 500k-6Gb; 1Gb on average? > - Network: one ADSL line for 60 persons in the conference center > Well, when it actually worked, which was not that often. > We finished using a cell-phone shared over wifi. > The local wireless network itself was down quite often. > No network at the university itself or nearby > - Among the organizers were Sage devs with good experience on running > Sage workshops and doing system/network administration, ... > - Sam had brought a big bunch of power cables. I screwed up not > bringing my own wireless router to at least guarantee a reliable > local network. > > Strategies we tried or considered: > -- > > (a) Installing Sage on Linux/Mac with the binaries from Sagemath.org > (b) Installing Sage on Linux/Mac from sources > (c) Installing Sage on Linux from a custom built fat binary > (d) Installing Sage on Windows with the virtual machine > (e) Running a Sage server on my laptop (8 cores, 8Gb) > (f) Using a remote Sage server > (g) Installing Linux and reducing the problem to (a-c) > (h) Booting on a live Debian USB key, custom-build by Thierry Monteil > with Sage, self-cloning and persistence. > (i) Using a local PC lab after installing Sage on them > > I would like to use the occasion to send my kudos to all those who > strive hard at making Sage easier to use one way or the other. > > How it went: > > > (a) Went smoothly on Mac when appropriate binaries were available. We > had to recompile a few of those binaries. > > (a) failed most of the time on Linux by lack of gfortran. Since we did > not have a reasonable network, apt-get install was not an option. > We did not have iso's of all the Ubuntu versions that were in use. > 3D plotting was usually not available (by lack of appropriate Java > plug-ins). > > (b) Compiling from source was not a viable option on Linux for the > same reason as above: build-essentials was usually not there. On > Mac that was ok, provided we had under hand the appropriate > version of XCode. > > (c) This fat binary was built by Thierry Monteil on an old pentium 3 > (!) with a minimal Debian install. Installation and usage went > smoothly, except that 3D plotting was usually not available. > > (d) Virtual machine: Installation went smoothly on about 20 machines > (with close guidance). It failed on 2-3 machines due to resource > limitations (disk, ...). > > However, except for about five recent machines, the memory > footprint was just too high: any non trivial calculation or plot > made the laptop swap and become simply too slow to use. > > The french keyboard was not properly self-detected. Due to the > network, we could not look up on the web for help. We ended up > finding how to configure it from a shell. I'll create a ticket. > > The Sage version available was a bit old (5.1) though that was not > an issue for us this time (but it could have been). > > The usage was on the complex side for most participants. They > typically tended to reclick on the ova, creating a new virtual > machine each time. Also uploading worksheets was tricky; it would > be much simpler if the virtual machine was setup to access the > user directory on the host machine or if the web client was > running on the host. > > (e) Running a local Sage server: This is a priori good short term
[sage-combinat-devel] Re: Sage Days in Bobo-Dioulasso debriefing; Sage in developping countries
Hey, all! Thanks for running this, Nicolas, and providing the detailed report! For converting people to linux: I'm working with a computer lab in Maseno, where we've now got linux dual-booting on all of the machines (about 40). Over the last couple months, we've gained a number of linux converts: windows in the developing world tends to be pirated and without regularly updating anti-virus software. So the machines 'gunk up' over the course of just a week or two of use to the point of being nigh-unusable. Providing an easily-accessible linux desktop as an option lets people decide for themselves, and once they've tried it, they're overwhelmingly preferring linux. Of course, live-usb's are a perfectly good way to provide such an experience as well. I just got a pile of 8gb usb sticks for $5 each from Canada; setting aside $250 and a bit of time could then provide live usb sticks for up to 50 participants at a sage-days event (with leftovers going towards the next event, of course). 4gb is probably a bit tight for a full installation plus sage, but could cut cost a bit. And with 8gb, we could also include open-office and a couple good text editors, making a good case for general linux use. As a last note, there's an algebraic geometry workshop happening in Mombasa, Kenya, sometime between May and June next year; I'm trying to figure out what the dates are now! We could potentially try some things out there, as well! Best, -tom On Sunday, November 11, 2012 12:00:34 PM UTC+3, Nicolas M. Thiery wrote: > > Dear Sage devs, > > The fall school on Discrete Mathematics in Bobo Dioulasso, Burkina > Faso, aka Sage Days 43, just finished. For two weeks we had courses > (combinatorics of words, dynamics, tilings, ...) interspersed with > on-hands tutorials using Sage. The public consisted mostly from > graduate students, from subsaharian Africa and some further away > countries. > > That was a good occasion for a real-life evaluation of a claim I have > been desiring to make for a long time: �Sage, being open-source, is > well adapted for universities in developing countries�. > > Let's see about this. > > A couple words of context: > -- > > - 70 participants total; in average 40-50 were there. > - Most participants had a laptop (or netbook for a few of them): > - 90%: windows, 5% mac, 5% Linux Ubuntu (usually in double-boot with > Windows) > - Laptop age ranging from 2003 to 2012; 4 years on average > - RAM: 500k-6Gb; 1Gb on average? > - Network: one ADSL line for 60 persons in the conference center > Well, when it actually worked, which was not that often. > We finished using a cell-phone shared over wifi. > The local wireless network itself was down quite often. > No network at the university itself or nearby > - Among the organizers were Sage devs with good experience on running > Sage workshops and doing system/network administration, ... > - Sam had brought a big bunch of power cables. I screwed up not > bringing my own wireless router to at least guarantee a reliable > local network. > > Strategies we tried or considered: > -- > > (a) Installing Sage on Linux/Mac with the binaries from Sagemath.org > (b) Installing Sage on Linux/Mac from sources > (c) Installing Sage on Linux from a custom built fat binary > (d) Installing Sage on Windows with the virtual machine > (e) Running a Sage server on my laptop (8 cores, 8Gb) > (f) Using a remote Sage server > (g) Installing Linux and reducing the problem to (a-c) > (h) Booting on a live Debian USB key, custom-build by Thierry Monteil > with Sage, self-cloning and persistence. > (i) Using a local PC lab after installing Sage on them > > I would like to use the occasion to send my kudos to all those who > strive hard at making Sage easier to use one way or the other. > > How it went: > > > (a) Went smoothly on Mac when appropriate binaries were available. We > had to recompile a few of those binaries. > > (a) failed most of the time on Linux by lack of gfortran. Since we did > not have a reasonable network, apt-get install was not an option. > We did not have iso's of all the Ubuntu versions that were in use. > 3D plotting was usually not available (by lack of appropriate Java > plug-ins). > > (b) Compiling from source was not a viable option on Linux for the > same reason as above: build-essentials was usually not there. On > Mac that was ok, provided we had under hand the appropriate > version of XCode. > > (c) This fat binary was built by Thierry Monteil on an old pentium 3 > (!) with a minimal Debian install. Installation and usage went > smoothly, except that 3D plotting was usually not available. > > (d) Virtual machine: Installation went smoothly on about 20 machines > (with close guidance). It failed on 2-3 machines due to r
[sage-combinat-devel] Re: Sage-Combinat days in Paris, June 2013
It's looking like there's a good chance that I'll be able to come through! On Friday, September 28, 2012 11:12:05 AM UTC+3, Nicolas M. Thiéry wrote: > > Dear Sage / Sage-Combinat fans, > > FPSAC (Formal Power Series and Algebraic Combinatorics) is the main > yearly international conference in algebraic combinatorics. It will > happen this year in Paris, June 24th-28th. We are planning to organize > a Sage-Combinat Days as a satellite event the week before: > > Sage Days ???: Free and Practical Software for (Algebraic) > Combinatorics > Paris or Orsay (near Paris) > June 17th-21st 2013 > > To start organizing it, it would be helpful to have a rough idea of > how many people would attend. If you are considering to join, please > drop me a line. At this point, it is likely that we won't have much > funding, except for people from American institutions through our NSF > grant. So please mention if you would need funding for lodging and > travel, but don't plan too much on it! > > If anyone interested in joining for the organization, please contact > me as well! > > Cheers, > Nicolas > > PS: the week after FPSAC, there will be the yearly conference > Permutation Patterns in the same location. > > -- > Nicolas M. Thi�ry "Isil" > > 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/-/YwFxqokzyvQJ. 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] Fast check for updates?
I could certainly look into writing the modification - I've written a shell script or ten in my day. How much different is the process for patching up the combinat script as opposed to the main sage sources? Cheers, -tom On Tuesday, October 16, 2012 11:50:10 AM UTC+3, Nicolas M. Thiery wrote: > > On Tue, Oct 16, 2012 at 01:31:11AM -0700, tom d wrote: > > Is there a way to (easily) check whether there are updates on the > mercurial > > server without popping all patches, reapplying, and rebuilding?� With > the > > amount of cython in the queue, it's taking quite a while for sage to > rebuild > > itself after each check.� I just want to check that there are no > changes, then > > commit (or update if there are changes)!� In fact, if possible, this > should > > probably be the default behaviour for 'sage --combinat update'. > > cd /devel/sage-combinat/.ht/patches > hg incoming > > I agree that this would be a nice and easy to implement feature of the > sage-combinat script. Volunteers? > > Cheers, > Nicolas > > PS: It could even be fancy and only pop off those patches that > have been modified (but that's tricky, because we need to check the > series as well). > > -- > Nicolas M. Thi�ry "Isil" > > 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/-/CMv6ZW4jS5YJ. 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] Fast check for updates?
Is there a way to (easily) check whether there are updates on the mercurial server without popping all patches, reapplying, and rebuilding? With the amount of cython in the queue, it's taking quite a while for sage to rebuild itself after each check. I just want to check that there are no changes, then commit (or update if there are changes)! In fact, if possible, this should probably be the default behaviour for 'sage --combinat update'. Best, -tom -- 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/-/-k92mDC7g-AJ. 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] setup.py and the prime directive.
Ok, I just put my line in after all the other combinat stuff, and everything applies ok. This has the disadvantage of (further) breaking the seeming convention that the combinat bits be listed alphabetically. But if setup.py is headed for the graveyard in the long run, it may not matter much. Also, there's only about fifteen lines for the combinat portion, so the failed lexicographic ordering may be not a terrible problem. On Tuesday, October 16, 2012 11:11:32 AM UTC+3, Nicolas M. Thiery wrote: > > On Mon, Oct 15, 2012 at 08:59:16PM -0700, Anne Schilling wrote: > > On 10/15/12 4:34 PM, tom d wrote: > > > I'm working on a patch which contains a modification to the setup.py > file, in order to indicate that a new directory exists in Sage. > > ... patch conflicts issues ... > > For information, I just asked on sage-devel if we could get rid of this > setup.py thingy: > > https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/tVTAQYFUgG0 > > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" > > 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/-/T0kH1hiSl34J. 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] setup.py and the prime directive.
This is probably a simple question, but here goes. I'm working on a patch which contains a modification to the setup.py file, in order to indicate that a new directory exists in Sage. I'm following the instructions for exporting a patch on the mercurial howto, and it says to move the patch to the front of the queue. When I do so, the queue breaks because many other people have also modified the setup.py file in their patches. So I fix it up and refresh. But now the setup.py doesn't match what the later patches expect, so they fail to apply. The obvious solution seems to be to make the small modification to the setup.py file for each of these patches and merge in the changes. But that violates the primary rule of the patch queue, which is to generally not mess with other people's patches. What does one do in this circumstance? Best, -tom -- 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/-/RYTaa1etEOYJ. 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: reflection groups vs. Weyl groups and their root systems
Hey, all; Christian asked for a way to get a permutation group without running through the matrix representation. There's an object called the 'Numbers Game' which essentially constructs the Coxeter Group from a coxeter graph by tracking application of reflections to the simple roots. This is all described in Bjorner-Brenti, chapter 4. There's a really almost brain-dead way to build this without even saying the words 'root space,' but it's essentially tracking the action on the roots. A while ago I wrote a (short) file to implement the numbers game, and now have it working for the following two kinds of input: 1) A cartan type (it then retrieves the associated dynkin diagram, and works from that), or 2) An edge-labeled graph, the Coxeter Graph. It seems like it would be reasonable to (re)factor my file to match your scheme. I would imagine some functionality where one builds the CoxeterMatrix, and then have a numbers_game method that returns this permutation-type realization of the associated Coxeter group. One would also want methods to recover the CoxterMatrix from th enumbers game, and also to recover a collection of roots from a numbers game element. I've attached my file for your consideration... Does this seem like a sensible thing to get into Sage, or is a Gap-type implementation preferable? Best, -tom On Thursday, April 26, 2012 6:16:04 AM UTC-4, Christian Stump wrote: > > Hi -- > > last week, Nicolas and I had a first look at how to get root systems for > non-crystallographic and infinite Coxeter groups. > > Here is a basic problem of which I have either not yet understood its > reason in the implementation, or which might be done better: > > - all constructions depend on a Cartan matrix, but we do not have a class > CartanMatrix > > - we do have a class DynkinDiagram that (seems to me to) serve(s) as the > Cartan datum including the Cartan matrix. But Dynkin diagrams are hard to > manipulate, can only be constructed from known types, and keep their string > rep and pretty print after being manipulated. This makes it hard to > construct the Dynkin diagram from a given Cartan matrix, while I might only > want to use it to get its Cartan matrix in order to construct the root > system. > > Why don't we implement a class CartanMatrix containing a symmetrizable > matrix, and the indexing. If one constructs a Cartan matrix from a Cartan > type, then we might also want to store this. From this, one can then get > back everything including Dynkin diagrams and root systems. > > What do you think? > > After solving this, I would then go and start solving glitches when > working with Cartan matrices over the universal cyclotomic field. > > Christian > -- 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/-/MpyqhKi0ogcJ. 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. #* # Copyright (C) 2012 Tom Denton , # # Distributed under the terms of the GNU General Public License (GPL) # as published by the Free Software Foundation; either version 2 of # the License, or (at your option) any later version. # http://www.gnu.org/licenses/ #* #Implementation of certain coxeter groups via the numbers game of Eriksson. from sage.structure.list_clone import ClonableArray, ClonableElement, ClonableList from sage.interfaces.all import gap from sage.misc.cachefunc import cached_method from sage.structure.unique_representation import UniqueRepresentation from sage.structure.parent import Parent from sage.categories.affine_weyl_groups import AffineWeylGroups from sage.rings.arith import binomial from sage.combinat.root_system.cartan_type import CartanType from sage.misc.prandom import randint from sage.combinat.root_system.weyl_group import WeylGroup from sage.combinat.composition import Composition from sage.misc.misc_c import prod class NumbersGameElement(ClonableArray): """ Realization of a Coxeter Group in terms of a numbers game. Currently only builds crystallographic types, though the basic methods should extend to arbitrary Coxeter type. """ def __init__(self, parent, lst, reduced_word=None, check=True): """ Initialize ``self`` """ self._lst=lst self._ct=parent.cartan_type() self._reduced_word=reduced_word ClonableArray.__init__(self, parent, lst, check) def _repr_(self): """ """ return "Numbers Game element with window " + str(self
[sage-combinat-devel] Re: [sage-devel] Call for vote: lrcalc as standard or optional spkg?
[x] standard package (...sang the choir to itself) On Jun 28, 1:57 pm, Franco Saliola wrote: > On Tue, Jun 28, 2011 at 11:04 AM, Florent Hivert > > > > > > > > > > wrote: > > Hi, > > >> With Mike and Anne we are about to finalize an interface with lrcalc: > > >> -- > >> #10333: An interface to Anders Buch's Littlewood-Richardson Calculator > >> lrcalc > > >> The "Littlewood-Richardson Calculator" is a C library for fast > >> computation of Littlewood-Richardson (LR) coefficients and products of > >> Schubert polynomials. It handles single LR coefficients, products of > >> and coproducts of Schur functions, skew Schur functions, and fusion > >> products. All of the above are achieved by counting LR (skew)-tableaux > >> of appropriate shape and content by iterating through > >> them. Additionally, lrcalc handles products of Schubert polynomials. > > >> The web page of lrcalc is: http://math.rutgers.edu/~asbuch/lrcalc/ > >> -- > > >> lrcalc weights 500Ko (100Ko of C code + administrative files + > >> mercurial repo). It's GLPV2+ with no dependencies. The code is quite > >> clean and so far proved to be portable: we used it in MuPAD-Combinat, > >> under MacOS, various flavors of Linux, and CYGWIN; tests on solaris > >> are welcome! > > > One more argument for using it. Having it in standard Sage is a good step > > toward getting rid of Symmetrica which often causes problems and is no more > > maintained. > > >> lrcalc will progressively become a key low-level component for Sage's > >> symmetric functions library. This evolution will be simpler if lrcalc > >> is always available. > > >> I therefore would like to cast a vote. Should lrcalc become: > > > Therefore: > > >> [X] A standard spkg > >> [ ] An optional spkg > > [X] A standard spkg > > Franco > > -- -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: combinat queue issue?
Just as a heads-up, I just installed Ubuntu 11 on my laptop and rebuilt Sage and it's now having tis same problem on a second machine. Perhaps something to do with a piece of upgraded software in Ubuntu 11? I'll play with this a bit more and see if I can make any headway in identifying the issue. -tom On May 15, 12:25 pm, "Nicolas M. Thiery" wrote: > On Sun, May 15, 2011 at 03:29:41AM -0700, tom d wrote: > > Yeah, so the failure's definitely happening in the check for version > >guards. I added a couple print statements in the update script to try > > to figure out what's happening; does this look like the right kind of > > thing to you? > > > current sage version: [4, 6, 2] > > hg_all_guards: ['guardsin series file:', ' 1 +4_1_2', ' 2 -4_3_1', > > ' 3 +4_3_1', ' 1 -4_3_2', ' 2 +4_3_2', ' 2 +4_3_3', ' 1 +4_3_3:', > > ' 2 +4_3_4', ' 1 -4_4', ' 1 +4_4', ' 2 +4_4_1', ' 1 +4_4_2', ' 1 > > +4_4_3', ' 1 +4_4_4', ' 2 -4_5', ' 4 +4_5', ' 3 -4_5_2', ' 1 > > +4_5_2', ' 1 +4_5_3', ' 1 -4_6', ' 1 +4_6', ' 9 -4_6_1', ' 1 > > +4_6_1', ' 4 -4_6_2', ' 2 +4_6_2', ' 1 -4_7', '45 +4_7', ' 7 > > +4_7_1', ' 1 +5_0', '150 NONE', ' 3 +coerce', '18 +disabled', ' 3 > > +experimental', ' 1 +free_to_assign', ' 1 +fun', ' 1 > > +keep_for_possible_future_use', ' 1 +long_compilation', ' 1 > > +needs_rebase', ' 1 +not_finished', ' 1 +not_wanted', ' 1 > > +power_zero', ' 2 +tentative_implementation', ' 1 +words_ng_fixme'] > > versionguards: [] > > allguards: [] > > > The script takes the output of the hg_all_guards() function (given > > above) and then uses a method to figure out if it's a new version > > guard or not; this check is apparently always returning false. So the > > question is whether the hg_all_guards output above looks sensible, or > > whether it's funky somehow (like, say, those leading numerals). > > Ah! The leading numerals seem funky indeed, and could well point to > the issue. I don't get them when I do > > > sage -hg qselect -s > +4_1_2 > -4_3_1 > ... > > Can you try disabling everything in your hgrc except for the > hgext.mq=, and see if sage -hg qselect -s returns to a normal > behaviour? > > Cheers, > Nicolas > -- > Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: strange examples behavior for crystals
Ok, so long as it's understood, I'm happy to ignore it, too. I was mainly concerned with making sure that old tests still worked with my patched code. On Jun 27, 12:26 am, "Nicolas M. Thiery" wrote: > Hi Anne! > > > > > > > > > > On Sun, Jun 26, 2011 at 07:18:16PM -0700, Anne Schilling wrote: > > Whilst reviewing Tom's patch for the crystal Stembridge rules, the following > > strange behavior came up: > > > sage: from sage.categories.examples.crystals import > > HighestWeightCrystalOfTypeA > > sage: C = HighestWeightCrystalOfTypeA(n=4) > > sage: D = Crystals().example(n=4) > > sage: C is D > > True > > > sage: C = HighestWeightCrystalOfTypeA(4) > > sage: D = Crystals().example(4) > > sage: C > > Highest weight crystal of type A_4 of highest weight omega_1 > > sage: D > > Highest weight crystal of type A_4 of highest weight omega_1 > > sage: C is D > > False > > > So without specifying n=4 in the definition of the examples, the two > > crystals > > are not considered as equal even though on print they appear to be the > > same. Why? > > In this example, UniqueRepresentation gets two different inputs: > > - An optional named argument ``n=4`` in the first case > - A positional argument ``4`` in the second case > > and because of that creates two distinct objects. > > Ideally, UniqueRepresentation would handle this automatically by > having its cached_method look up the optional arguments of __init__ > and do appropriate straightening as cached method usually does. This > is not yet the case. So instead, we have been so far handling this > issue by having a __classcall__ that straighten the arguments. And in > the case of category examples, we just ignored this minor issue in > favor of simplicity. > > You are welcome to open a ticket upon UniqueRepresentation and/or add > a comment in some TEST section, but otherwise I vote for just ignoring > this. > > Cheers, > Nicolas > -- > Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: combinat queue issue?
Yeah, so the failure's definitely happening in the check for version
guards. I added a couple print statements in the update script to try
to figure out what's happening; does this look like the right kind of
thing to you?
current sage version: [4, 6, 2]
hg_all_guards: ['guards in series file:', ' 1 +4_1_2', ' 2 -4_3_1',
' 3 +4_3_1', ' 1 -4_3_2', ' 2 +4_3_2', ' 2 +4_3_3', ' 1 +4_3_3:',
' 2 +4_3_4', ' 1 -4_4', ' 1 +4_4', ' 2 +4_4_1', ' 1 +4_4_2', ' 1
+4_4_3', ' 1 +4_4_4', ' 2 -4_5', ' 4 +4_5', ' 3 -4_5_2', ' 1
+4_5_2', ' 1 +4_5_3', ' 1 -4_6', ' 1 +4_6', ' 9 -4_6_1', ' 1
+4_6_1', ' 4 -4_6_2', ' 2 +4_6_2', ' 1 -4_7', '45 +4_7', ' 7
+4_7_1', ' 1 +5_0', '150 NONE', ' 3 +coerce', '18 +disabled', ' 3
+experimental', ' 1 +free_to_assign', ' 1 +fun', ' 1
+keep_for_possible_future_use', ' 1 +long_compilation', ' 1
+needs_rebase', ' 1 +not_finished', ' 1 +not_wanted', ' 1
+power_zero', ' 2 +tentative_implementation', ' 1 +words_ng_fixme']
version guards: []
all guards: []
The script takes the output of the hg_all_guards() function (given
above) and then uses a method to figure out if it's a new version
guard or not; this check is apparently always returning false. So the
question is whether the hg_all_guards output above looks sensible, or
whether it's funky somehow (like, say, those leading numerals).
Best,
-tom
On May 12, 9:21 am, "Nicolas M. Thiery"
wrote:
> On Wed, May 11, 2011 at 11:09:55AM -0700, tom d wrote:
> >
> > :/mnt/data/sage-4.6.2/devel/sage-combinat$ sage -hg qselect -s
> > guards in series file:
> > 1 +4_1_2
> > 2 -4_3_1
>
> ...
>
> >
> > info("Updating guards")
> > system(hg+" qselect -q -n")
> > system(hg+" qselect "+
> > " ".join(non_version_guards + version_guards))
> >
> > When a system hg call happens, does it use sage's local hg install, or
> > does it rely on hg being installed elsewhere on the host system?
> > Because I don't have hg installed outside of sage...
>
> It uses Sage's hg. See the def of `hg` earlier in the file.
>
> Hmm. I am pretty stuck at that point ...
>
> Cheers,
> Nicolas
> --
> Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
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: combinat queue issue?
:/mnt/data/sage-4.6.2/devel/sage-combinat$ sage -hg qselect -s
guards in series file:
1 +4_1_2
2 -4_3_1
3 +4_3_1
1 -4_3_2
2 +4_3_2
2 +4_3_3
1 +4_3_3:
2 +4_3_4
1 -4_4
1 +4_4
2 +4_4_1
1 +4_4_2
1 +4_4_3
1 +4_4_4
2 -4_5
4 +4_5
3 -4_5_2
1 +4_5_2
1 +4_5_3
1 -4_6
1 +4_6
9 -4_6_1
1 +4_6_1
4 -4_6_2
2 +4_6_2
1 -4_7
45 +4_7
7 +4_7_1
1 +5_0
150 NONE
3 +coerce
18 +disabled
3 +experimental
1 +free_to_assign
1 +fun
1 +keep_for_possible_future_use
1 +long_compilation
1 +needs_rebase
1 +not_finished
1 +not_wanted
1 +nt
1 +power_zero
2 +tentative_implementation
1 +words_ng_fixme
This is in the sage-combinat script:
info("Updating guards")
system(hg+" qselect -q -n")
system(hg+" qselect "+
" ".join(non_version_guards + version_guards))
When a system hg call happens, does it use sage's local hg install, or
does it rely on hg being installed elsewhere on the host system?
Because I don't have hg installed outside of sage...
Best,
-tom
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
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: combinat queue issue?
Ah, the -v has to go before the update command; sorry. Here's the (hopefully relevant) excerpt from the verbose update command... patch queue now empty Pulling the new version of the patches from the patch server (cd .hg/patches ; /mnt/data/sage-4.6.2/sage -hg --config 'extensions.hgext.mq=' pull -u http://combinat.sagemath.org/patches/) pulling from http://combinat.sagemath.org/patches/ searching for changes no changes found Current non version guards: Updated non version guards: Updating guards /mnt/data/sage-4.6.2/sage -hg --config 'extensions.hgext.mq=' qselect -q -n /mnt/data/sage-4.6.2/sage -hg --config 'extensions.hgext.mq=' qselect no active guards Warning: the former top patch 70 A trac_10998-categories-posets- nt.patch does not exist anymore Applying all patches /mnt/data/sage-4.6.2/sage -hg --config 'extensions.hgext.mq=' qpush - a On May 11, 3:02 am, "Nicolas M. Thiery" wrote: > On Wed, May 11, 2011 at 11:49:11AM +0200, Viviane Pons wrote: > > I seem to have similar issues : > > > I am still with sage-4.6.2, I did a hg pull and hg update and then > > tried to pop and push all the patches and here's what I get : > > > applying trac_10998-categories-posets-nt.patch > > unable to find 'sage/categories/facade_sets.py' for patching > > 2 out of 2 hunks FAILED -- saving rejects to file > > sage/categories/facade_sets.py.rej > > patch failed, unable to continue (try -v) > > patch failed, rejects left in working dir > > errors during apply, please fix and refresh > > trac_10998-categories-posets-nt.patch > > > The above qselect fixed it but it should have worked without this fix, > > the problem came from the update itself. > > "The above qselect": was this `sage -combinat qselect`, or a manual > `hg select ...` as Tom had to do? > > As stated in the documentation: if you use hg pull and hg push > directly to update instead of using the sage-combinat script, you are > responsible for running `sage -combinat qselect` yourself. > > Cheers, > Nicolas > -- > Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: combinat queue issue?
Here's information from 4.6.2. I don't remember whether it was binary or source-built. The 4.7.1.rc2 that's having troubls was definitely source-built, though. Version output: :/mnt/data/sage-4.6.2$ sage -version | Sage Version 4.6.2, Release Date: 2011-02-25 | Here's the output of sage -combinat update -v, run after setting up the guards manually: popping trac_10998-categories-posets-nt.patch popping trac_8-finite_enumset_list_cache-review-nt.patch popping trac_8-finite_enumset_list_cache-fh.patch popping trac_11165-partitions_core_quotient_fix-fh.patch popping trac_11224-lazy_import-get-nt.patch popping trac_10333-lrcalc-final.patch popping trac_11315-remove_pstricks_from_preamble-fs.patch popping trac_11314-tableau-from-shape-and-word-ht.patch popping trac_11290-nilCoxeter-cb.patch popping trac_11292-inputs-lattice-meet-join.patch popping trac_11293-all-relations-poset-v2.patch popping trac_11289-docs-checks-random-poset.patch popping trac_7922_alpha3-changes.patch popping trac_7922-final-review-nt.patch popping trac_7922-rebased-4.7.alpha2.patch popping trac_9949_major_index_really_final-nb.patch patch queue now empty pulling from http://combinat.sagemath.org/patches/ searching for changes no changes found no active guards applying trac_9949_major_index_really_final-nb.patch patching file sage/groups/perm_gps/permgroup_named.py sage/groups/perm_gps/permgroup_named.py skipping trac_10776_poset_top.patch - guarded by ['+4_7'] skipping trac_10890_partitions_in_box-om.patch - guarded by ['+4_7'] skipping trac_10939-graph-relabel_with_function-nt.patch - guarded by ['+4_7'] skipping trac_10995-fixing_getitem_on_ambient_space-vp.patch - guarded by ['+4_7'] skipping trac_9109-finite_set_maps-fh.patch - guarded by ['+4_7'] skipping trac_11156-sage_unittest-init-nt.patch - guarded by ['+4_7'] skipping trac_8670_folded-sl.patch - guarded by ['+4_7'] skipping trac_10788_return_words-sl.patch - guarded by ['+4_7'] skipping trac_10660_modify_str_of_word-sl.patch - guarded by ['+disabled'] skipping trac_8673_out_of_range_index-sl.patch - guarded by ['+4_7'] skipping trac_11128_word_conjugacy-sl.patch - guarded by ['+4_7'] skipping trac_11128-minor_docfix-abm.patch - guarded by ['+4_7'] skipping trac_10055-words_clean_history-tm.patch - guarded by ['+4_7'] skipping sage-4.7.1.patch - guarded by ['+4_7_1'] skipping trac_10961-lie_bracket_in_rings-nt.patch - guarded by ['+4_7_1'] skipping trac_10938-Set-issubset_issuperset-nt.patch - guarded by ['+4_7_1'] skipping trac_11108-classgraph-nt.patch - guarded by ['+4_7_1'] skipping trac_10446_schuetzenberger_involution-as.patch - guarded by ['+4_7_1'] skipping trac_11236-test_eq_for_python_2_7-nt.patch - guarded by ['+4_7_1'] skipping trac_9065-facade_parents-nt.patch - guarded by ['+4_7_1'] skipping sage-5.0.patch - guarded by ['+5_0'] applying trac_7922-rebased-4.7.alpha2.patch patching file doc/en/thematic_tutorials/lie/branching_rules.rst patching file doc/en/thematic_tutorials/lie/weight_ring.rst patching file doc/en/thematic_tutorials/lie/weyl_character_ring.rst patching file sage/categories/classical_crystals.py patching file sage/combinat/root_system/all.py patching file sage/combinat/root_system/ambient_space.py patching file sage/combinat/root_system/weyl_characters.py doc/en/thematic_tutorials/lie/branching_rules.rst doc/en/thematic_tutorials/lie/weight_ring.rst doc/en/thematic_tutorials/lie/weyl_character_ring.rst sage/categories/classical_crystals.py sage/combinat/root_system/all.py sage/combinat/root_system/ambient_space.py sage/combinat/root_system/weyl_characters.py applying trac_7922-final-review-nt.patch patching file doc/en/thematic_tutorials/lie/weight_ring.rst patching file doc/en/thematic_tutorials/lie/weyl_character_ring.rst patching file sage/combinat/root_system/weyl_characters.py doc/en/thematic_tutorials/lie/weight_ring.rst doc/en/thematic_tutorials/lie/weyl_character_ring.rst sage/combinat/root_system/weyl_characters.py applying trac_7922_alpha3-changes.patch patching file doc/en/thematic_tutorials/lie/weyl_character_ring.rst patching file sage/combinat/root_system/weyl_characters.py doc/en/thematic_tutorials/lie/weyl_character_ring.rst sage/combinat/root_system/weyl_characters.py applying trac_11289-docs-checks-random-poset.patch patching file sage/combinat/posets/poset_examples.py sage/combinat/posets/poset_examples.py applying trac_11293-all-relations-poset-v2.patch patching file sage/combinat/posets/posets.py sage/combinat/posets/posets.py applying trac_11292-inputs-lattice-meet-join.patch patching file sage/combinat/posets/lattices.py sage/combinat/posets/lattices.py applying trac_11290-nilCoxeter-cb.patch patching file doc/en/reference/algebras.rst patching file doc/en/reference/combinat/algebra.rst patching file sage/algebras/affine_nil_temperley_lieb.py patching file sage/algebras/all.py patching file sage/algebras/iwahori_hecke_algebra.py patching file sage/algebras/nil_coxeter_algebra.py adding sage
[sage-combinat-devel] Re: combinat queue issue?
Ok, indeed it was an issue with the guards. I ran: sage -hg qselect 4_7 4_7_1 5_0 with the 4.6.2 install, and then pushed all patches and it worked. The funny part is that 'sage -combinat update' is clearing out all of my guards, so I have to pull changes, manually set the guards, and then manually push all of the patches. I'm not sure what's going on there... Best, -tom On May 9, 5:32 am, "Nicolas M. Thiery" wrote: > On Sun, May 08, 2011 at 08:38:22PM -0700, Anne Schilling wrote: > > It seems to me that for some reason (probably wrong guard selection) > > the patch > > trac_9065-facade_parents-nt.patch > > is not applied for you. facade_sets.py is introduced there. > > > Can you pop all patches, run the qselect again, and push? > > Or alternatively do a `sage -combinat update` which will do the above > for you. > > Cheers, > Nicolas > -- > Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: combinat queue issue?
Hmm... Just tried that; the 4.7.rc2 install has no guards applied (perhaps to be expected). I found this line in both the 4.7.rc2 and the 4.6.2 output when I tried to update: patching file sage/categories/examples/posets.py unable to find 'sage/categories/facade_sets.py' for patching patching file sage/categories/facade_sets.py 2 out of 2 hunks FAILED -- saving rejects to file sage/categories/ facade_sets.py.rej Any idea what facade_sets.py is, and why it wouldn't exist in 4.6.1, 4.6.2, or 4.7.rc2? Best, -tom -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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] combinat queue issue?
Hey, all; I've been having trouble updating/installing combinat this last week. I was hoping to (finally) finish up the stembridge patch, but updating combinat has been uniformly failing. Anne said it was working fine during Sage Days, so I'm rather confused. I have two different machine, both of which have had failures. EEE PC running Ubuntu and Sage 4.6.1 Desktop running Ubuntu and Sage 4.6.2. I also just tried Sage 4.7.rc2, built from source, both of which die with this message: "errors during apply, please fix and refresh trac_10998-categories- posets-nt.patch "Abort" normally, I'd just wait for the patch queue to get patched up, but it's been a week and it seems like I'm alone in having trouble... Best, -tom -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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: Patch queue woes: iet/iet.py not found
Indeed, all is well now. Many thanks! On Mar 23, 1:09 am, "Nicolas M. Thiery" wrote: > Hi! > > > > > > On Tue, Mar 23, 2010 at 08:34:13AM +0100, Florent hivert wrote: > > > I just finished upgrading my Sage, and now Combinat cannot update... > > > Here's the output: > > > > Skip backward compatibility patches for sage 4.3.4 > > > Keep backward compatibility patches for sage 4.3.4.1 > > > Keep backward compatibility patches for sage 5.0.0 > > > Updating guards > > > /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qselect > > > -q -n > > > /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qselect > > > 4_3_4_1 > > > 5 > > > _0_0 > > > number of unguarded, unapplied patches has changed from 107 to 109 > > > /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qpush > > > trac_8429_s > > > plit_word-sl.patch > > > applying sage-5.0.0.patch > > > patch sage-5.0.0.patch is empty > > > No username found, using 'kaibu...@gnosis' instead > > > applying trac_8429_split_word-sl.patch > > > unable to find 'sage/combinat/iet/iet.py' for patching > > > This is rather strange. File 'sage/combinat/iet/iet.py' was created by > > ticket > > #7145 merged in sage-4.3.1.rc0. It seems that something went wrong during > > your > > upgrade. > > Yup, that was it: the sage-combinat dir had not been updated since the > upgrade. The installation is working now. Sorry for the noise! > > Cheers, > Nicolas > -- > Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@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] Patch queue woes: iet/iet.py not found
'Allo! I just finished upgrading my Sage, and now Combinat cannot update... Here's the output: Skip backward compatibility patches for sage 4.3.4 Keep backward compatibility patches for sage 4.3.4.1 Keep backward compatibility patches for sage 5.0.0 Updating guards /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qselect -q -n /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qselect 4_3_4_1 5 _0_0 number of unguarded, unapplied patches has changed from 107 to 109 /home/kaibutsu/sage/sage -hg --config 'extensions.hgext.mq=' qpush trac_8429_s plit_word-sl.patch applying sage-5.0.0.patch patch sage-5.0.0.patch is empty No username found, using 'kaibu...@gnosis' instead applying trac_8429_split_word-sl.patch unable to find 'sage/combinat/iet/iet.py' for patching 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/iet/ iet.py.rej patching file sage/combinat/words/suffix_trees.py Hunk #1 FAILED at 12 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/words/ suffix_tre es.py.rej patching file sage/combinat/words/word.py Hunk #3 FAILED at 21 Hunk #4 FAILED at 229 2 out of 5 hunks FAILED -- saving rejects to file sage/combinat/words/ word.py.re j patching file sage/combinat/words/word_generators.py Hunk #1 succeeded at 40 with fuzz 2 (offset -1 lines). patching file sage/combinat/words/words.py Hunk #1 FAILED at 469 Hunk #2 FAILED at 486 2 out of 5 hunks FAILED -- saving rejects to file sage/combinat/words/ words.py.r ej patch failed, unable to continue (try -v) sage/combinat/iet/iet.py: No such file or directory No username found, using 'kaibu...@gnosis' instead patch failed, rejects left in working dir errors during apply, please fix and refresh trac_8429_split_word- sl.patch Abort Best, -tom -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@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.
