Re: [sage-combinat-devel] Re: Category Questions
On Thu, Jan 14, 2010 at 04:04:59PM -0500, Jason Bandlow wrote: > Well, it seems sage-devel approves, so term = coeff * monomial it is. Adjugé, vendu! Thanks for handling this. > I've spent today preparing a patch to do this, and I think I've done it. > I have to run now, but tomorrow I'll put up a trac ticket for you to > look at it. If you want a quick look tonight, it's on the combinat > server. I had a quick look, and this looks good. The next step is to update the patches in the Sage-Combinat queue that are not yet in Sage and use term/monomial. Luckily, there are only a couple of them. For the ncsf one, you can go ahead, and do it in place. For the others, you can either ask permission to the patch author, or do a follow up patch to be folded in later. The last step will be for everyone to update his/her private code if needed. We should advertise this change! > I'll also need to make a good explanation of what I've done to > this list--I'll do that tomorrow too. Thanks! 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] Categories for extensions types
Hi, Given the recent discussion on adding generic group features, it was way time for someone to go one step further: to enable extension types to inherit code from categories, so that we could at last start to systematically put generic code in the categories instead of the "old" abstract class hierarchy (or at least the non time-critical code). You'll find an attempt on #7921! Well, so far, most categories that are not relevant to combinatorics are fairly empty. So for the moment, the main improvement this brings to Sage is the availability of generic tests: sage: ZZ.category() # Finally Category of euclidean domains sage: TestSuite(ZZ).run(verbose = True) running ._test_additive_associativity() . . . pass running ._test_an_element() . . . pass running ._test_associativity() . . . pass running ._test_element_pickling() . . . pass running ._test_not_implemented_methods() . . . pass running ._test_one() . . . pass running ._test_pickling() . . . pass running ._test_prod() . . . pass running ._test_some_elements() . . . pass running ._test_zero() . . . pass So far, TestSuite is not used much; yet, just doing this change already revealed a couple pickling issues (#7922, #7929). The next step will be to systematically replace all loads/dumps tests with TestSuite. It would be best for this step to be done by the authors of the various Sage modules. I do expect that this will reveal much more issues. Especially when others will start adding more generic tests to the categories (it's easy! go ahead! I'll make a point at reviewing it!) The patch in #7921 goes with the getattr approach with its caveats. Yet all test pass on my machine. And hopefully some day extension types will have native support for multiple inheritance from abstract classes as we discussed with Robert. The getattr code itself small. On the other hand, I had to make little fixes in many places, including some where I am completely ignorant (schemes, Cython arcanes, ...). Along the way the patch cleans up a couple things in the way categories are declared here and there. Altogether the patch is 2000 lines long and touches 46 files. This should be a fairly quick review, but it needs to be done with care. I uploaded a (final?) version on trac. Early feedback before starting the full review most welcome. This patch is susceptible to rot away very quickly, and I won't have much time to keep it alive. So, I would love if it was possible to have it applied very early in the 4.3.2 release cycle. Robert M/B, David Roe, Craig, or someone else: any chances for you to review it shortly? Thanks much in advance! 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] Re: Category Questions
Hi Nicolas, Nicolas M. Thiery wrote: > For the record: I added in PS a discussion with the MuPAD team in > 1998 ..., about the same issue :-) I would love to see it resolved > once for all. Please make a call on sage-devel, and if there is a > consensus for standardizing for term = coeff * monomial, go ahead with > the change! > > I'd suggest a first patch/ticket doing the change, and then your > triangularity patch on top of it. I am happy to review all of this > promptly. It would be good to have all of this in Sage before Sage > days 20 at the end of February. Well, it seems sage-devel approves, so term = coeff * monomial it is. I've spent today preparing a patch to do this, and I think I've done it. I have to run now, but tomorrow I'll put up a trac ticket for you to look at it. If you want a quick look tonight, it's on the combinat server. I'll also need to make a good explanation of what I've done to this list--I'll do that tomorrow too. Cheers, Jason -- 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.
Re: [sage-combinat-devel] conflicts with triangular-morphisms-jb.patch
On Thu, Jan 14, 2010 at 05:08:13PM +0100, Sébastien Labbé wrote: > I am currently experiencing a small conflict in the sage-combinat > tree. See below for the content of the reject file. Please try again after a sage -combinat qselect. The iwahori hecke patch and a couple others are already guarded for 4.3.1, and interfers with Jason's patch. Cheers, > > Sébastien > > > sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qpop -a > aucun patch appliqué > sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qselect > no active guards > sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qpush -a > application de trac_7776-inject_variable-nt.patch > application de trac__symmetric_functions-inject_shorthands-nt.patch > skipping trac_7921-categories_for_extension_types-nt.patch - guarded > by ['+category'] > application de trac_7145-iet-final.patch > application de trac_7543_s_adic_final.patch > application de trac_7520_words_construction_improvements-sl.patch > application de trac_7619_pickle_for_FiniteWord_iter_callable-sl.patch > skipping words_ng-cpp_basic_string.patch - guarded by ['+words_ng_fixme'] > application de classcall_metaclass-nt.patch > application de element_wrapper-improvement-nt.patch > patching file sage/categories/examples/finite_semigroups.py > Hunk #1 succeeded at 171 with fuzz 2 (offset 57 lines). > application de crystal_cleanup-as.patch > patching file sage/combinat/crystals/letters.py > Hunk #11 succeeded at 1309 with fuzz 2 (offset 0 lines). > application de crystal_cleanup-nt.patch > application de trac_7538_poset_equal_fix-fh.patch > application de trac_6641-poset_antichains_backtracker.patch > application de trac_6641-poset_antichains_backtracker-part2.patch > application de combinat-quickref-jb.patch > application de trac_6655_partition_newfeature-ny.patch > patching file sage/combinat/partition.py > Hunk #1 succeeded at 834 with fuzz 2 (offset -13 lines). > application de triangular-morphisms-jb.patch > patching file sage/categories/modules_with_basis.py > Hunk #3 FAILED at 240 > Hunk #4 succeeded at 245 with fuzz 2 (offset -28 lines). > 1 out of 8 hunks FAILED -- saving rejects to file > sage/categories/modules_with_basis.py.rej > l'application du patch a échoué, impossible de continuer (essayez avec -v) > patch failed, rejects left in working dir > des erreurs se sont produites durant l'application, veuillez corriger > puis rafraîchir triangular-morphisms-jb.patch > > > Here is the reject : > > > sla...@pol:~/sage-4.3/devel/sage-combinat$ cat > sage/categories/modules_with_basis.py.rej > --- modules_with_basis.py > +++ modules_with_basis.py > @@ -239,6 +241,16 @@ class ModulesWithBasis(Category_over_bas > > # TODO: find something better to get this inheritance from > CategoryWithTensorProduct.Element > class ElementMethods(CategoryWithTensorProduct.ElementMethods, > CategoryWithCartesianProduct.ElementMethods): > +# TODO: Define the appropriate element methods here (instead of in > +# subclasses). These methods should be consistent with those on > +# polynomials. > + > +# def _neg_(self): > +# """ > +# Default implementation of negation by trying to multiply by -1. > +# TODO: doctest > +# """ > +# return self._lmul_(-self.parent().base_ring().one(), self) > > def support_of_monomial(self): > """ > -- > 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. > > 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] conflicts with triangular-morphisms-jb.patch
Dear Jason, Dear Nicolas, I am currently experiencing a small conflict in the sage-combinat tree. See below for the content of the reject file. Sébastien sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qpop -a aucun patch appliqué sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qselect no active guards sla...@pol:~/sage-4.3/devel/sage-combinat$ hg qpush -a application de trac_7776-inject_variable-nt.patch application de trac__symmetric_functions-inject_shorthands-nt.patch skipping trac_7921-categories_for_extension_types-nt.patch - guarded by ['+category'] application de trac_7145-iet-final.patch application de trac_7543_s_adic_final.patch application de trac_7520_words_construction_improvements-sl.patch application de trac_7619_pickle_for_FiniteWord_iter_callable-sl.patch skipping words_ng-cpp_basic_string.patch - guarded by ['+words_ng_fixme'] application de classcall_metaclass-nt.patch application de element_wrapper-improvement-nt.patch patching file sage/categories/examples/finite_semigroups.py Hunk #1 succeeded at 171 with fuzz 2 (offset 57 lines). application de crystal_cleanup-as.patch patching file sage/combinat/crystals/letters.py Hunk #11 succeeded at 1309 with fuzz 2 (offset 0 lines). application de crystal_cleanup-nt.patch application de trac_7538_poset_equal_fix-fh.patch application de trac_6641-poset_antichains_backtracker.patch application de trac_6641-poset_antichains_backtracker-part2.patch application de combinat-quickref-jb.patch application de trac_6655_partition_newfeature-ny.patch patching file sage/combinat/partition.py Hunk #1 succeeded at 834 with fuzz 2 (offset -13 lines). application de triangular-morphisms-jb.patch patching file sage/categories/modules_with_basis.py Hunk #3 FAILED at 240 Hunk #4 succeeded at 245 with fuzz 2 (offset -28 lines). 1 out of 8 hunks FAILED -- saving rejects to file sage/categories/modules_with_basis.py.rej l'application du patch a échoué, impossible de continuer (essayez avec -v) patch failed, rejects left in working dir des erreurs se sont produites durant l'application, veuillez corriger puis rafraîchir triangular-morphisms-jb.patch Here is the reject : sla...@pol:~/sage-4.3/devel/sage-combinat$ cat sage/categories/modules_with_basis.py.rej --- modules_with_basis.py +++ modules_with_basis.py @@ -239,6 +241,16 @@ class ModulesWithBasis(Category_over_bas # TODO: find something better to get this inheritance from CategoryWithTensorProduct.Element class ElementMethods(CategoryWithTensorProduct.ElementMethods, CategoryWithCartesianProduct.ElementMethods): +# TODO: Define the appropriate element methods here (instead of in +# subclasses). These methods should be consistent with those on +# polynomials. + +# def _neg_(self): +# """ +# Default implementation of negation by trying to multiply by -1. +# TODO: doctest +# """ +# return self._lmul_(-self.parent().base_ring().one(), self) def support_of_monomial(self): """ -- 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.
Re: [sage-combinat-devel] Re: Iwahori Hecke algebra and Kazhdan-Lusztig patches
Hi Anne,
On Wed, Jan 13, 2010 at 11:49:38PM -0800, Anne Schilling wrote:
> I recently asked Nicolas whether it is easy to amend the Iwahori Hecke
> algebra code to mod out by further relations? For example to impose
> T_i T_{i+1} T_i = 0 or something like this. He suggested to discuss this
> on the mailing list since others might be interested:
>
> > The code reduces everything to the multiplication of a basis element
> > T_w by a generator T_i (product_by_generator_on_basis). If you have a
> > way to detect when the relation applies (here if ws_i as both i and
> > i+1 as descents?), then you can adapt this method to return 0. You
> > should also adapt the basis indices appropriately.
>
> If I only amend product_by_generator_on_basis some non-allowed terms
> in my calculations actually survive. So do I need to add checks in
>
> product_on_basis
>
> and
>
> product_by_generator
>
> to see wheter w1 (resp. x) is allowed?
In principle, product_by_generator_on_basis is the only place where
new basis elements are created during arithmetic. So you should just
make sure that you never create bad elements there.
Of course, if you create explicitly elements, say by doing H.term(w),
you should make sure w is appropriate. Which leads to the second
point:
> Or is there a more global way of adapting the basis indices?
See __init__.py:
CombinatorialFreeModule.__init__(self, base_ring, W, category =
category)
W should be replaced by whatever is appropriate. Do you have a way of
testing if a given w does not contain any T_i T_{i+1} T_i? If yes,
here is a shameless plug:
def predicate(w):
...
W.weak_order_ideal(predicate)
I pushed this feature yesterday in the 6588 patch :-)
You could try to use as predicate:
def has_not_consecutive_descents(w):
...
However, this is a bit of an abuse, and might not work mathematically
speaking (it just guarantees that there is one prefix of w of each
length that does not end with any T_i T_{i+1} T_i).
Note: setting the indices appropriately is not going to magically kill
undesired elements. It might (actually should) trigger errors when
such elements are created.
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.
