[sage-combinat-devel] Sage-Combinat queue on Sage 5.1 / 5.2
Dear all, I am in the process of rebasing the queue so that it works both in 5.2 and 5.1. No promise when I'll be finished, but hopefully tonight or tomorrow (depends if I find a power plug in the train). So far I had to touch the following patches; a few more are to come: trac_11187-finite_reflection_groups-cs.patch trac_11305-rigged_configurations-ts.patch trac_12774-coxeter-ms.patch trac_13072-tuples-of-partitions_am.patch trac_13074-tuples-of-tableaux-am.patch If you can avoid big movements until then, so much the better! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] The deprecation change
Dear Volker, On Mon, Jul 16, 2012 at 10:33:34AM -0700, Volker Braun wrote: I've rebased http://trac.sagemath.org/5457 on top of the deprecation change and it was a very easy change. Sure a very easy change. But this is to be multiplied by the number of patches. I for myself wasted five straight hours on this. Others (Anne, Andrew, ...) did spend quite some time too. Plus all the communication involved because patches in the queue belong to 30+ people. Plus having the queue partially broken for two weeks which certainly put off many newcomers from the Sage days. All this energy would have been better off invested in getting sage-combinat patches finished and merged. Yes, I take my share of responsibility: quite some of that would have been saved if I could have put those 5 hours straight away; but I also have the right to take vacations. Yes the fact that it takes soo much time is also due to our workflow stretching the limits of mercurial queues. But at this point none of the alternative workflows that have been proposed do satisfy our constraints (see http://wiki.sagemath.org/combinat/CodeSharingWorkflow). All in all, in the future, I *will* put a negative review to similar non essential global changes that impact much of our code (stuff in combinat, ...). Unless the author volunteers to handle all the rebasing work in the Sage-Combinat queue, together with the associated communication. Best regards, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] Hopf algebra methods
On Wed, Jul 25, 2012 at 06:39:57PM -0400, Franco Saliola wrote: You can also define this using module_morphism on the basis elements, as follows. sage: Sym = SymmetricFunctions(QQ) sage: s = Sym.schur() sage: t = s.tensor_square() sage: mu = t.module_morphism(on_basis=lambda (a,b) : s[a]*s[b], codomain=s) I really would like to write as: sage: mu = t.module_morphism(on_basis = s.product.on_basis) This will eventually be possible when s.product will know that it is a bilinear morphism, and know its codomain. In any cases, this feature should be right away available as s.mu, implemented in HopfAlgebrasWithBasis.ParentMethods. Continuing from above, we construct the endomorphism of the identity tensor the antipode as a module morphism: sage: id_tensor_antipode = t.module_morphism(on_basis=lambda (a,b) : tensor([s[a], s[b].antipode()]), codomain=t) Then we can compose this with the multiplication map defined above: sage: mu_a = mu * id_tensor_antipode sage: mu_a(f) 0 Here is what we could do in MuPAD: idTensorAntipode := operators::tensorProductOfMaps( [id, s::antipode], s::tensorSquare, s::tensorSquare): es := NCSF::mu @ idTensorAntipode @ NCSF::coproduct es(s([2, 1])); 0 es(s([])); s([]) Is there a volunteer to implement tensor products of morphisms in Sage? The construction itself should be straightforward: to be put in ModulesWithBasis.TensorProducts.ParentMethods.tensor_product_of_morphisms in waiting for some better spot when morphisms will be better supported in Sage. Bonus: make ``tensor_product([phi,psi])`` call it appropriately. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] Re: rebasing your patches
On Fri, Jul 27, 2012 at 05:35:41PM -0400, Franco Saliola wrote: I've just pushed a change that hopefully fixes this. Thanks Franco! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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: Sage-Combinat queue on Sage 5.1 / 5.2
On Wed, Aug 01, 2012 at 12:34:07PM +0200, Nicolas M. Thiery wrote: I am in the process of rebasing the queue so that it works both in 5.2 and 5.1. No promise when I'll be finished, but hopefully tonight or tomorrow (depends if I find a power plug in the train). Ok, I am hopefully done with the rebase: as soon as I'll have a network available to push, the Sage-Combinat queue should apply smoothly on both Sage 5.1 and 5.2. Please report any problem! Here are the patches that I had to rebase for 5.2: - concrete_combinatorial_statistics_and_maps-cs.patch (dropped spacing change that don't belong to that patch and make it prone to bitrotting) - tableaux-combinatorics-am.patch - trac_11187-finite_reflection_groups-cs.patch - trac_11305-rigged_configurations-ts.patch - trac_12774-coxeter-ms.patch - trac_13072-tuples-of-partitions_am.patch - trac_13074-tuples-of-tableaux-am.patch - trac_X-Kleshchev-partitions-am.patch - alphabet-vd.patch Remains - Rebasing 12380_move_nfactors_methods-sl.patch To the authors of the above: in case you had changes on those patches that were not pushed to the patch server, the best is probably to simply overwrite my version with yours, and replay the rebase; most of the time it was straightforward. Cheers, Nicolas For the record: all the mess was caused by tickets #13109 and (to a much lesser extend) #13073 which did mostly irrelevant non local changes. Typical situation: changing a deprecation call that was just about to be removed by one of our upcoming patches. -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] Re: Trac 9265: Remove `CombinatorialClass` from sage.combinat.tableau
On Mon, Jul 30, 2012 at 09:04:44PM -0700, Anne Schilling wrote: Since there were some nonlocal changes in sage-5.1, I think it would be best if all developers now switch to sage-5.2 and we focus our efforts on rebasing all patches to this new version of sage (instead of trying to keep backwards compatibilty for much longer). For the record (see other thread): I have finished rebasing the patches for 5.2. Luckily enough it was not too hard to backport some pieces of the bad patches, so that those patches also apply on 5.1 as well. To be pushed as soon as I have network access. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] Hopf algebra methods
On Fri, Jul 27, 2012 at 09:01:46PM +0200, Martin Rubey wrote: Maybe f.parent()._sets is what you want? Speaking of which: we probably should expose that using some method foo, so that if F is the tensor/cartesian/... product of A, B, C we would get: sage: F.foo() (A, B, C) Any suggestion for a good name for this method? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] Newbie review question
On Sun, Jul 29, 2012 at 08:08:45PM -0700, Andrew Mathas wrote: A side issue here is that currently sage and sage-combinat seem to be out of sync in that I think that sage-combinat is working off 5.2-rc0 whereas sage is using 5.2-rc1. As the patchbot is using 5.2-rc1 this implies that it will fail many of the sage-combinat patches. Is this an issue? 5.2 rc0 and rc1 were minimally different; so in that case you could have used either of them. Worst comes to worst, the patchbot is here to catch mishaps. Well, of course now 5.2 is out and sage-combinat applies on it, it's best to use it. Btw: I confirm Simon's saying: a ticket can receive a positive review even if it still depends on another ticket that is not yet positive reviewed (with the caveats he mentioned). At least that's really how things should be. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] tensor products and rings, was: several alphabets for symmetric functions
On Sun, Jul 29, 2012 at 08:58:18AM +0200, Martin Rubey wrote: why does the is_field method exist at all? In other words, why wouldn't one rather test if R in Fields: ??? The intention is that: sage: R in Fields() or equivalently sage: R in Fields returns whether R is known by Sage to be a field. In other words, R.category() returns a subcategory of Fields(). On the other hand: sage: R.is_field() will *compute* whether R is a field (or raise a NotImplementedError). Of course the is_... methods are cached; but still this might be expensive to decide (e.g. testing whether n is prime for IntegerModRing(n)). If not plain undecidable. If the answer is yes, ``R.is_field()`` updates the category of R to a subcategory of Fields(). The above should apply to any category, except that updating the category on the fly is not yet super robust, so not all is_... method do it. Now, to finish explaining the strange results you mentioned in your follow up e-mail, I should say that, for backward compatibility reasons (not all parents in Sage use categories yet), there is a special case for `R in Fields()` and a few others that currently call their is_...() counterparts. A consequence of the above is that a piece of code that takes a decision upon the properties of a parent should use the `R in Fields` or `R in Fields()` idiom, unless there is a very good reason not to. There are lots of places in Sage that should be updated w.r.t. the above. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net 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.
Re: [sage-combinat-devel] The deprecation change
On Wednesday, August 1, 2012 1:35:02 PM UTC-7, Nicolas M. Thiery wrote: All in all, in the future, I *will* put a negative review to similar non essential global changes that impact much of our code (stuff in combinat, ...). Unless the author volunteers to handle all the rebasing work in the Sage-Combinat queue, together with the associated communication. See http://trac.sagemath.org/sage_trac/ticket/13255. There may be other similar tickets by the same author. -- John -- 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/-/iDH9j3Xenl4J. 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] The deprecation change
On Wednesday, August 1, 2012 6:05:44 PM UTC-7, Volker Braun wrote: On Wednesday, August 1, 2012 8:47:37 PM UTC-4, John H Palmieri wrote: See http://trac.sagemath.org/sage_trac/ticket/13255. There may be other similar tickets by the same author. At least that ticket only touches stuff in sage/misc and only replaces them by equivalent python 3. So it shouldn't conflict with the combinat queue at all. Well, according to grep, 39 patches in the combinat queue touch files in sage/misc. I didn't test if any of them conflicted with the patch at #13255. -- John -- 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/-/fGXB14ydfOcJ. 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] Hopf algebra methods
On 8/1/12 12:23 PM, Nicolas M. Thiery wrote: On Fri, Jul 27, 2012 at 09:01:46PM +0200, Martin Rubey wrote: Maybe f.parent()._sets is what you want? Speaking of which: we probably should expose that using some method foo, so that if F is the tensor/cartesian/... product of A, B, C we would get: sage: F.foo() (A, B, C) Any suggestion for a good name for this method? How about tensor_factors? Best, Anne -- 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.
