#5457 closed enhancement (fixed)
Refactor symmetric functions and k-bounded subspace
Reported by: | nthiery | Owned by: | mhansen |
---|---|---|---|
Priority: | major | Milestone: | sage-5.4 |
Component: | combinatorics | Keywords: | symmetric functions, days38, sd40 |
Cc: | sage-combinat, saliola, bump, chrisjamesberg, zabrocki, SimonKing | Merged in: | sage-5.4.beta0 |
Authors: | Mike Zabrocki, Anne Schilling, Jason Bandlow | Reviewers: | Dan Bump, Nicolas M. Thiéry, Jeroen Demeyer |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #11563, #13109, #12969 | Stopgaps: |
Description (last modified by aschilling)
This patch restructures the implementation of symmetric functions in sage
The new implementation makes use of multiple realizations and the category framework. The new access to symmetric functions is via
sage: Sym = SymmetricFunctions(QQ)
Further new features that are implemented:
- The ring of symmetric functions is now endowed with a Hopf algebra structure. The coproduct and antipode are implemented (which were missing before).
- A tutorial on how to use symmetric functions in sage is included at the beginning of sf.py which is also accessible via
sage: SymmetricFunctions??
- Symmetric functions should now work a lot better with respect to specializing parameters like q and t for Hall-Littlewood, Jack and Macdonald symmetric functions. Certain functionalities before this change were broken or not possible.
- Documentation was added to LLT polynomials (which had very sparse documentation previously).
- The k-bounded subspace of the ring of symmetric function was implemented. The k-Schur functions now live in the k-bounded subspace rather than in the ring of symmetric functions as before.
This patch gained tremendously by the tutorial on symmetric functions written by Jason Bandlow, a draft on the k-bounded subspace by Jason Bandlow, and code multiple realizations written by Franco Saliola.
See also http://groups.google.com/group/sage-devel/msg/a49f3288fca1b75c
Apply
Attachments (5)
Change History (109)
comment:1 Changed 7 years ago by nthiery
- Description modified (diff)
comment:2 Changed 7 years ago by nthiery
- Cc sage-combinat added
comment:3 Changed 4 years ago by aschilling
- Dependencies set to 13109
- Report Upstream set to N/A
comment:4 Changed 4 years ago by aschilling
- Dependencies 13109 deleted
comment:5 Changed 4 years ago by aschilling
- Description modified (diff)
- Keywords symmetric functions sd38 sd40 added
- Reviewers set to Dan Bump, Franco Saliola
- Summary changed from Refactor symmetric functions to Refactor symmetric functions and k-bounded subspace
comment:6 Changed 4 years ago by aschilling
- Cc saliola bump chrisjamesberg added
comment:7 Changed 4 years ago by aschilling
- Cc zabrocki added
comment:8 Changed 4 years ago by aschilling
- Status changed from new to needs_review
comment:9 Changed 4 years ago by aschilling
- Status changed from needs_review to needs_work
comment:10 Changed 4 years ago by aschilling
comment:11 Changed 4 years ago by aschilling
comment:12 Changed 4 years ago by vbraun
- Dependencies set to #11563
comment:13 Changed 4 years ago by vbraun
- Dependencies changed from #11563 to #11563, #13109
comment:14 follow-up: ↓ 15 Changed 4 years ago by aschilling
- Description modified (diff)
comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 4 years ago by aschilling
Hi Mike,
I completed the doctests for sfa.py and also rebased everything on top of 13109. Please put your changes to
- hall_littlewood.py
- jack.py
- llt.py
- macdonald.py
on top of the current patch trac_5457-symmetric_functions-mz.patch. Unfortunately we need to abandon the sage-combinat queue for the moment since it would be very cumbersome to keep it backward compatible with 13109. I will send you a separate e-mail on how to proceed.
Cheers,
Anne
comment:16 in reply to: ↑ 15 Changed 4 years ago by aschilling
Ok, patch is ready for review! It should apply and run cleanly on sage.5.2.rc0!
Anne
comment:17 Changed 4 years ago by aschilling
- Status changed from needs_work to needs_review
comment:18 Changed 4 years ago by aschilling
comment:19 Changed 4 years ago by SimonKing
- Cc SimonKing added
comment:20 follow-up: ↓ 21 Changed 4 years ago by aschilling
Hi Dan!
Thank you very much for your comments on the failing doctests in
- devel/sage/sage/algebras/nil_coxeter_algebra.py
- devel/sage/sage/categories/realizations.py
They are fixed in the updated version of the patch. I do not get failures for
- devel/sage/sage/sandpiles/sandpile.py
on my machine.
lolita-4:sandpiles anne$ sage -t sandpile.py
sage -t "devel/sage-sf/sage/sandpiles/sandpile.py"
[19.0 s]
All tests passed!
Total time for all tests: 19.0 seconds
Anne
comment:21 in reply to: ↑ 20 Changed 4 years ago by bump
Replying to aschilling:
Hi Dan!
Thank you very much for your comments on the failing doctests in
- devel/sage/sage/algebras/nil_coxeter_algebra.py
- devel/sage/sage/categories/realizations.py
They are fixed in the updated version of the patch. I do not get failures for
- devel/sage/sage/sandpiles/sandpile.py
on my machine.
I also get a doctest failure in sandpile.py with unpatched sage-5.2.rc0 so this failure is not caused by the patch.
comment:22 Changed 4 years ago by bump
Applies cleanly to sage-5.2 and passes all tests.
comment:23 follow-up: ↓ 24 Changed 4 years ago by aschilling
- Description modified (diff)
comment:24 in reply to: ↑ 23 Changed 4 years ago by aschilling
The attached review patch trac_5457-review-as.patch incorporates most of the comments that Dan Bump raised in e-mail conversations.
Anne
comment:25 follow-up: ↓ 26 Changed 4 years ago by bump
- Description modified (diff)
- Status changed from needs_review to positive_review
This patch is a huge step forward for symmetric functions.
In addition to normal testing I spent quite a bit of time and privately sent comments (mainly on documentation) that have been taken into account in trac_5457-review-as.patch. I'm changing the status to positive review.
comment:26 in reply to: ↑ 25 Changed 4 years ago by aschilling
Replying to bump:
This patch is a huge step forward for symmetric functions.
In addition to normal testing I spent quite a bit of time and privately sent comments (mainly on documentation) that have been taken into account in trac_5457-review-as.patch. I'm changing the status to positive review.
Dear Dan, Thank you so much for your thorough and quick review of this huge patch! Mike and I just finished the review patch. Tests pass on both of our machines.
Anne
comment:27 follow-up: ↓ 28 Changed 4 years ago by bump
I have reviewed the latest version of the patch and it still has positive review.
comment:28 in reply to: ↑ 27 Changed 4 years ago by aschilling
Since http://trac.sagemath.org/sage_trac/ticket/12969 just got merged into sage-5.3.beta0, please also apply the attachment trac12969_rel_5457.patch on the ticket 12969 to this patch. Otherwise there will be doctest failures.
Thanks,
Anne
comment:29 Changed 4 years ago by aschilling
- Dependencies changed from #11563, #13109 to #11563, #13109, #12969
comment:30 Changed 4 years ago by aschilling
- Description modified (diff)
comment:31 Changed 4 years ago by jdemeyer
This needs to be rebased to sage-5.3.beta0 (not yet released):
patching file sage/categories/realizations.py Hunk #1 FAILED at 74 1 out of 1 hunks FAILED -- saving rejects to file sage/categories/realizations.py.rej patching file sage/combinat/sf/classical.py Hunk #3 FAILED at 88 1 out of 9 hunks FAILED -- saving rejects to file sage/combinat/sf/classical.py.rej patching file sage/combinat/sf/sfa.py Hunk #61 FAILED at 2589 1 out of 63 hunks FAILED -- saving rejects to file sage/combinat/sf/sfa.py.rej abort: patch failed to apply
comment:32 Changed 4 years ago by jdemeyer
- Status changed from positive_review to needs_work
comment:33 follow-up: ↓ 34 Changed 4 years ago by aschilling
- Description modified (diff)
comment:34 in reply to: ↑ 33 Changed 4 years ago by aschilling
I rebased and folded the three patches with respect to sage-5.3.beta0 from yesterday.
It should apply cleanly now.
Mike and I are still going to fix one math bug that someone at FPSAC found.
Anne
comment:35 Changed 4 years ago by aschilling
Hi Dan,
Our new rebased patch is attached. You only need to apply trac_5457-symmetric_functions-mz.patch. Note that we did not fix apply_linear_morphism in /category/module_with_basis.py yet since Nicolas seems to have a review patch for this, but unfortunately his tests did not pass. Either he needs to fix his review patch or we will add your suggestion from the e-mail.
Anne
comment:36 Changed 4 years ago by aschilling
- Status changed from needs_work to needs_review
comment:37 follow-up: ↓ 38 Changed 4 years ago by nthiery
Note: I inserted in the queue the latest patch rebased for 5.3 beta0 from here. My review patch is also there, ready to be folded if you are happy with it.
comment:38 in reply to: ↑ 37 Changed 4 years ago by aschilling
Dear Dan and Nicolas,
Thank you so much for your reviews and work on this patch! I incorporated the changes that Dan suggested by e-mail and folded Nicolas' review patch. In addition, Mike had some minor improvements in the documentation of llt.py which are incorporated.
The new patch should apply cleanly on sage-5.3.beta0.
Anne
comment:39 Changed 4 years ago by aschilling
- Reviewers changed from Dan Bump, Franco Saliola to Dan Bump, Nicolas M. Thiery
comment:40 Changed 4 years ago by bump
All tests pass with sage-5.3.beta0. The changes discussed over the last few days have all been incorporated. I think this is ready to go.
comment:41 Changed 4 years ago by bump
- Status changed from needs_review to positive_review
comment:42 Changed 4 years ago by nthiery
- Description modified (diff)
comment:43 Changed 4 years ago by jdemeyer
- Status changed from positive_review to needs_work
This fails on arando (32-bit i386 Linux):
sage -t --long "devel/sage/sage/combinat/sf/llt.py" ********************************************************************** File "/var/lib/buildbot/build/sage/arando-1/arando_full/build/sage-5.3.beta1/devel/sage/sage/combinat/sf/llt.py", line 329: sage: cmp(L3Q, L3Z) Expected: -1 Got: 1 **********************************************************************
comment:44 follow-up: ↓ 45 Changed 4 years ago by aschilling
- Description modified (diff)
- Status changed from needs_work to needs_review
comment:45 in reply to: ↑ 44 Changed 4 years ago by aschilling
Hi Jeroen,
Hmm, this is hard for us to check since we are not running our code on that operating system. We attached a patch which will hopefully fix the problem
Apply
Thanks,
Anne
comment:46 Changed 4 years ago by aschilling
- Status changed from needs_review to positive_review
comment:47 Changed 4 years ago by jdemeyer
- Reviewers changed from Dan Bump, Nicolas M. Thiery to Dan Bump, Nicolas M. Thiéry
- Status changed from positive_review to needs_work
comment:48 Changed 4 years ago by jdemeyer
- Status changed from needs_work to needs_review
I think one of the original reviewers should review this additional patch.
comment:49 Changed 4 years ago by bump
- Status changed from needs_review to positive_review
I think one of the original reviewers should review this additional patch.
This adds a cmp method for SymmetricFunctions?, which was missing, and that
was uncovered by the test in llt.py. Two SymmetricFunctions? instances are
compared equal if and only if they have the same base ring, which is as it
should be.
Unless I'm missing something the patch is obviously correct. I ran --testall --long
in the sf directory and all tests passed.
comment:50 Changed 4 years ago by nthiery
There is no compelling reason to have a cmp function for symmetric functions (nor its bases). The order has no meaning, and equality testing should be taken care of by UniqueRepresentation?.
So altogether, I'd rather not add a cmp function, and instead would rather replace the failing test by:
sage: cmp(L3Q, L3Z) != 0
which is platform independent, and is all we care about. We could even just discard this test.
Now, I don't want to slow down the integration of this patch, so I am happy leaving this issue for a latter ticket, at the author's choice.
Cheers,
Nicolas
comment:51 Changed 4 years ago by zabrocki
- Status changed from positive_review to needs_work
As per Nicolas' suggestion, we are deleting the cmp function from llt and moving and modifying the doctests elsewhere in the llt.py file.
comment:52 follow-up: ↓ 53 Changed 4 years ago by zabrocki
- Description modified (diff)
- Status changed from needs_work to needs_review
This new patch deletes the function cmp from llt.py and inserts doctests into init in llt.py
comment:53 in reply to: ↑ 52 Changed 4 years ago by aschilling
sage -testall passes on both mine and Mike's machine (both MacOS) with trac_5457-symmetric_functions-mz.patch and trac_5457_docfix2-mz.patch applied.
Dan and/or Nicolas, please set a positive review if you are happy with the changes.
Thanks!
Anne
comment:54 Changed 4 years ago by bump
- Status changed from needs_review to positive_review
Nicolas argued that there is no real reason for Sym to have a __cmp__
method and there is no reason for the test to be deterministic. We don't
care if two rings or ring elements are > or < than each other, just whether they are distinct.
Therefore the test that failed can be rewritten and the __cmp___ method
is not needed.
This patch removes the __cmp__ method from llt polynomials instead
of adding one for sf. In fact, SymmetricFunctions should not have had a
__cmp__ method because it already inherits one from UniqueRepresentation.
(Tested!) On the other hand, there is no reason for the test as previously written
to be deterministic. So this is the correct approach.
comment:55 Changed 4 years ago by bump
- Status changed from positive_review to needs_work
comment:56 follow-up: ↓ 57 Changed 4 years ago by bump
- Status changed from needs_work to positive_review
comment:57 in reply to: ↑ 56 Changed 4 years ago by aschilling
Thank you Dan for the review!
Anne
comment:58 follow-up: ↓ 59 Changed 4 years ago by aschilling
- Description modified (diff)
comment:59 in reply to: ↑ 58 Changed 4 years ago by aschilling
Folded patches.
comment:60 follow-up: ↓ 61 Changed 4 years ago by jdemeyer
- Merged in set to sage-5.3.beta2
- Resolution set to fixed
- Status changed from positive_review to closed
comment:61 in reply to: ↑ 60 ; follow-up: ↓ 62 Changed 4 years ago by aschilling
comment:62 in reply to: ↑ 61 Changed 4 years ago by nthiery
Replying to aschilling:
Wow, unbelievable!! Thank you everyone for your work on this!
Congratulations!
And thanks on behalf of all symmetric function users!
Nicolas
comment:63 Changed 4 years ago by nthiery
- Keywords days38 added; sd38 removed
comment:64 Changed 4 years ago by jdemeyer
- Description modified (diff)
Additional patch 5457_long_time.patch needs review.
comment:65 Changed 4 years ago by jdemeyer
- Priority changed from major to blocker
Additional patch is a blocker, please review.
comment:66 Changed 4 years ago by zabrocki
the patch looks good and works properly. I tested it on sage-5.3.rc0 using both --long and not --long and all tests pass. I give it a positive review.
comment:67 Changed 4 years ago by jdemeyer
- Merged in sage-5.3.beta2 deleted
- Milestone changed from sage-5.3 to sage-5.4
- Priority changed from blocker to major
- Resolution fixed deleted
- Status changed from closed to new
I hate to be the bringer of bad news, but after playing a bit with this patch, I think I found an actual bug:
sage: HS3t2 = SymmetricFunctions(QQ).llt(3,t=2).hspin() sage: TestSuite(HS3t2).run() Failure in _test_associativity: Traceback (most recent call last): File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/misc/sage_unittest.py", line 275, in run test_method(tester = tester) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/categories/semigroups.py", line 120, in _test_associativity tester.assert_((x * y) * z == x * (y * z)) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/categories/algebras.py", line 202, in __mul__ return self._mul_(right) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/categories/magmas.py", line 361, in _mul_parent return self.parent().product(self, other) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/categories/algebras_with_basis.py", line 351, in _product_from_combinatorial_algebra_multiply m = self._multiply(left, right) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/combinat/sf/llt.py", line 683, in _multiply return self( self._m(left) * self._m(right) ) File "parent.pyx", line 804, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:7228) File "morphism.pyx", line 243, in sage.categories.morphism.SetMorphism._call_ (sage/categories/morphism.c:4412) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/combinat/sf/llt.py", line 617, in _self_to_m return self._m._from_cache(x, self._m_cache, self._self_to_m_cache, t = self.t) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/combinat/sf/sfa.py", line 857, in _from_cache cache_function(sum(part)) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/combinat/sf/llt.py", line 714, in _m_cache self._m_to_self_cache, to_other_function = self._to_m) File "/release/sage-5.3.rc1/local/lib/python2.7/site-packages/sage/combinat/sf/sfa.py", line 1057, in _invert_morphism known_matrix_n[i,j] = value File "matrix0.pyx", line 1415, in sage.matrix.matrix0.Matrix.__setitem__ (sage/matrix/matrix0.c:6745) File "matrix0.pyx", line 1520, in sage.matrix.matrix0.Matrix._coerce_element (sage/matrix/matrix0.c:7937) File "parent.pyx", line 804, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:7228) File "coerce_maps.pyx", line 82, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3547) File "coerce_maps.pyx", line 77, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3449) File "rational.pyx", line 371, in sage.rings.rational.Rational.__init__ (sage/rings/rational.c:6534) File "rational.pyx", line 484, in sage.rings.rational.Rational.__set_value (sage/rings/rational.c:7337) File "fraction_field_element.pyx", line 736, in sage.rings.fraction_field_element.FractionFieldElement._rational_ (sage/rings/fraction_field_element.c:7197) File "parent.pyx", line 804, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:7228) File "polynomial_element.pyx", line 6521, in sage.rings.polynomial.polynomial_element.ConstantPolynomialSection._call_ (sage/rings/polynomial/polynomial_element.c:46753) TypeError: not a constant polynomial ------------------------------------------------------------ Failure in _test_distributivity: [...] TypeError: not a constant polynomial ------------------------------------------------------------ Failure in _test_one: [...] TypeError: not a constant polynomial ------------------------------------------------------------ Failure in _test_prod: [...] TypeError: not a constant polynomial ------------------------------------------------------------ The following tests failed: _test_associativity, _test_distributivity, _test_one, _test_prod
comment:68 Changed 4 years ago by jdemeyer
- Status changed from new to needs_review
comment:69 Changed 4 years ago by jdemeyer
- Status changed from needs_review to needs_work
comment:70 follow-up: ↓ 73 Changed 4 years ago by zabrocki
Just an FYI, this does not seem to be a new bug introduced by this patch. Doc tests currently do not seem to test extensively enough to catch this (but once I knew the bug existed I was able to trigger it in all kinds of ways). I think that I've tracked down the problem. Here is a one line fix (class LLT_generic, method _m_cache):
- self._invert_morphism(n, self.base_ring(), self._self_to_m_cache, \
+ self._invert_morphism(n, QQt, self._self_to_m_cache, \
I will post a patch later today when I am confident that this actually fixes the problem and that there aren't similar bugs in jack/hall_littlewood/macdonald.
comment:71 Changed 4 years ago by zabrocki
I also found that the tests that are currently in llt.py will fail if they are run separately.
sage: HSp3 = SymmetricFunctions(FractionField(QQ['t'])).llt(3).hspin() sage: TestSuite(HSp3).run(skip = ["_test_associativity", "_test_distributivity", "_test_prod"]) sage: HS3t2 = SymmetricFunctions(QQ).llt(3,t=2).hspin() sage: TestSuite(HS3t2).run(skip = ["_test_associativity", "_test_distributivity", "_test_prod"])
Executes without errors (even without the 'skip's). However, if you delete the first two lines then these tests fail. I will fix this by putting these tests in their own block.
comment:72 Changed 4 years ago by zabrocki
- Description modified (diff)
- Status changed from needs_work to needs_review
The new attachment fixes the bug and makes the document changes that will test for the bug. I removed the skip commands from two of the TestSuite commands since they weren't particularly long executions before, but they should have been the very tests which caught this bug.
comment:73 in reply to: ↑ 70 ; follow-up: ↓ 75 Changed 4 years ago by jdemeyer
Replying to zabrocki:
Just an FYI, this does not seem to be a new bug introduced by this patch.
What do you mean? The doctest is testing code which did not exist before. So I would say the bug was introduced by this patch.
Changed 4 years ago by jdemeyer
comment:74 Changed 4 years ago by jdemeyer
I rebased the three patches (there was some fuzz) and made some additional changes to 5457_long_time.patch (so that patch needs review again).
comment:75 in reply to: ↑ 73 ; follow-up: ↓ 76 Changed 4 years ago by aschilling
Replying to jdemeyer:
Replying to zabrocki:
Just an FYI, this does not seem to be a new bug introduced by this patch.
What do you mean? The doctest is testing code which did not exist before. So I would say the bug was introduced by this patch.
The failures are related to failures that already existed before this patch.
On sage 5.0.1 (plain) one obtains
sage: LLTHSpin(QQ,3,t=2) LLT polynomials in the HSp basis at level 3 with t=2 over Rational Field sage: H = LLTHSpin(QQ,3,t=2) sage: s = SFASchur(QQ) sage: s(H([2,1])) ERROR: An unexpected error occurred while tokenizing input The following traceback may be corrupted or invalid The error message is: ('EOF in multi-line statement', (1760, 0))
Anne
comment:76 in reply to: ↑ 75 ; follow-up: ↓ 78 Changed 4 years ago by aschilling
I reviewed and tested both patches (by applying 5457_long_time.patch and then trac_5457_llt_doc_and_bug_fix-mz.patch in this order). Tests pass and the bug seems to be fix (if I only apply 5457_long_time.patch tests do not pass, so the patches should be applied together).
Jeroen, I have a question. trac_5457-symmetric_functions-mz.patch was already merged into sage-5.2.beta2. Why did you rebase that patch again? Will it be merged again in a different version of sage? I am asking since in the sage-combinat queue it is currently guarded by sage-5.3.beta2.
Thanks,
Anne
comment:77 Changed 4 years ago by aschilling
- Status changed from needs_review to positive_review
comment:78 in reply to: ↑ 76 ; follow-up: ↓ 79 Changed 4 years ago by jdemeyer
Replying to aschilling:
Will it be merged again in a different version of sage?
Yes, I don't want to merge any more new patches in sage-5.3 so it will be removed from sage-5.3 and then merged again in sage-5.4 such that it can be tested better. Does this cause trouble?
comment:79 in reply to: ↑ 78 ; follow-up: ↓ 80 Changed 4 years ago by aschilling
Replying to jdemeyer:
Replying to aschilling:
Will it be merged again in a different version of sage?
Yes, I don't want to merge any more new patches in sage-5.3 so it will be removed from sage-5.3 and then merged again in sage-5.4 such that it can be tested better. Does this cause trouble?
Mike's patch fixes a bug that is actually in the current version of Sage (as I outlined above). Wouldn't it be better to merge the two extra patches into sage-5.3 instead? Quite a lot of other patches depend on this patch (plus an upcoming book).
Thanks,
Anne
comment:80 in reply to: ↑ 79 Changed 4 years ago by jdemeyer
Replying to aschilling:
Mike's patch fixes a bug that is actually in the current version of Sage (as I outlined above). Wouldn't it be better to merge the two extra patches into sage-5.3 instead? Quite a lot of other patches depend on this patch (plus an upcoming book).
I believe everything you say in this paragraph, but I see no arguments to merge it in sage-5.3.
You have to convince me that this patch will absolutely not break anything on any system, nor cause doctest timeouts.
comment:81 follow-ups: ↓ 82 ↓ 90 Changed 4 years ago by nthiery
Ah shoot, my comment did not get through yesterday; well, it's a bit outaded, but here it is anyway ...
Replying to jdemeyer:
Replying to aschilling:
Will it be merged again in a different version of sage?
Yes, I don't want to merge any more new patches in sage-5.3 so it will be removed from sage-5.3 and then merged again in sage-5.4 such that it can be tested better. Does this cause trouble?
Technically, the Sage-Combinat queue can't handle patches that are merged and then unmerged. Now, this just means that we will have to everyone using a 5.3 beta to switch to 5.3 final; not a big deal.
Anne, Mike: are there specific deadlines (e.g. the book or meetings) for which waiting for 5.4 could be a bother?
Other than that, it's quite a big patch, on a very central feature for people in algebraic combinatorics; and the authors (Mike and Anne mostly) did put quite a lot of work and energy into it. So it will be quite frustrating for theim to not be able to cross it out of their TODO list while the semester starts. But that's life ...
Cheers,
Nicolas
comment:82 in reply to: ↑ 81 Changed 4 years ago by jdemeyer
Replying to nthiery:
So it will be quite frustrating for theim to not be able to cross it out of their TODO list while the semester starts.
But if the patch has positive review, then it is effectively off the TODO list, right? Personally, I don't think it makes a big difference for a patch Author whether a patch gets merged in sage-5.3 or sage-5.4.
comment:83 Changed 4 years ago by zabrocki
My only worry is that several patches with positive reviews (#8899, #13399, #13404) were all reviewed on versions of sage where #5457 was already integrated. Until last night #8899 and #13399 didn't have #5457 as a dependency (but should have) and #13404 depends on #13399. I hope that there aren't other patches that are not similarly needed to be pushed forward that I am unaware of.
comment:84 Changed 4 years ago by jdemeyer
- Status changed from positive_review to needs_work
A small detail: the last patch needs a proper commit message.
comment:85 follow-up: ↓ 86 Changed 4 years ago by zabrocki
I'm not sure what you want in the commit message and I don't have permission to replace the previous version. If you are satisfied with that change then please adjust the "apply" list so that the second version is the one that is used.
comment:86 in reply to: ↑ 85 Changed 4 years ago by jdemeyer
- Description modified (diff)
Replying to zabrocki:
I'm not sure what you want in the commit message
Well, I don't want anything refering to [mq] or the patch name. So if you delete the second line of the commit message in your patch, that will be fine.
comment:87 follow-up: ↓ 89 Changed 4 years ago by zabrocki
I think that does it. Sorry I don't know what the [mq] is or how it got there.
comment:88 Changed 4 years ago by jdemeyer
- Status changed from needs_work to positive_review
comment:89 in reply to: ↑ 87 Changed 4 years ago by saliola
Replying to zabrocki:
Sorry I don't know what the [mq] is or how it got there.
The [mq] is short for mercurial queue; it is automatically placed there by hg.
comment:90 in reply to: ↑ 81 Changed 4 years ago by aschilling
Hi Nicolas,
Technically, the Sage-Combinat queue can't handle patches that are merged and then unmerged. Now, this just means that we will have to everyone using a 5.3 beta to switch to 5.3 final; not a big deal.
I have no idea how to handle the sage-combinat queue now. Do nothing until sage-5.3 comes out and then force everyone to move to sage-5.3?
Anne, Mike: are there specific deadlines (e.g. the book or meetings) for which waiting for 5.4 could be a bother?
Beginning for the quarter for the book since my students are supposed to use it and sage!
Cheers,
Anne
comment:91 Changed 4 years ago by aschilling
comment:92 Changed 4 years ago by chapoton
Apply trac_5457-symmetric_functions-mz.patch, 5457_long_time.patch, trac_5457_llt_doc_and_bug_fix-mz.2.patch
comment:93 Changed 4 years ago by aschilling
- Reviewers changed from Dan Bump, Nicolas M. Thiéry to Dan Bump, Nicolas M. Thiéry, Jeroen Demeyer
comment:94 Changed 4 years ago by jdemeyer
- Merged in set to sage-5.4.beta0
- Resolution set to fixed
- Status changed from positive_review to closed
comment:95 follow-up: ↓ 96 Changed 4 years ago by jdemeyer
- Description modified (diff)
My second additional patch 5457_long_time_2.patch needs review (just mention the review in the comments, don't change the status).
comment:96 in reply to: ↑ 95 Changed 4 years ago by nthiery
Replying to jdemeyer:
My second additional patch 5457_long_time_2.patch needs review (just mention the review in the comments, don't change the status).
Positive review! Thanks!
comment:97 follow-ups: ↓ 98 ↓ 99 Changed 4 years ago by jdemeyer
This patch abuses assert and AssertionError. assert should not be used for control flow. An assert checks something which should always be true, a failed assertion is always a bug in the program.
For example:
sage: f.skew_by([1]) Traceback (most recent call last): ... AssertionError: x needs to be a symmetric function
This is a simple user mistake, for which assert is not right.
I think this must be fixed.
comment:98 in reply to: ↑ 97 Changed 4 years ago by nthiery
Hi Jeroen,
Replying to jdemeyer:
This patch abuses assert and AssertionError. assert should not be used for control flow. An assert checks something which should always be true, a failed assertion is always a bug in the program.
For example:
sage: f.skew_by([1]) Traceback (most recent call last): ... AssertionError: x needs to be a symmetric functionThis is a simple user mistake, for which assert is not right.
I think this must be fixed
Given the discussion on sage-devel, do we agree that there is no control flow involved and it's a not so common function, so it's ok to use assert?
Cheers,
Nicolas
comment:99 in reply to: ↑ 97 ; follow-up: ↓ 100 Changed 4 years ago by aschilling
Replying to jdemeyer:
This patch abuses assert and AssertionError. assert should not be used for control flow. An assert checks something which should always be true, a failed assertion is always a bug in the program.
For example:
sage: f.skew_by([1]) Traceback (most recent call last): ... AssertionError: x needs to be a symmetric functionThis is a simple user mistake, for which assert is not right.
I think this must be fixed.
We had a user who used this method wrongly at FPSAC (he used a partition instead of a symmetric function). That's why we added this (since this can potentially be a common user mistake). If this should be done differently, feel free to change it!
Anne
comment:100 in reply to: ↑ 99 Changed 4 years ago by jdemeyer
Replying to aschilling:
That's why we added this (since this can potentially be a common user mistake). If this should be done differently, feel free to change it!
Yes, it should be done differently. The correct way would be:
if not needed_condition: raise ValueError("Error message")
As I said: assert is only meant to catch bugs, not user errors. Although, as Nicolas Thiéry argued, something assert is acceptible. See also the sage-devel thread.
Changed 4 years ago by aschilling
comment:101 follow-up: ↓ 102 Changed 4 years ago by aschilling
- Description modified (diff)
comment:102 in reply to: ↑ 101 Changed 4 years ago by aschilling
I folded the patches and made the required change.
Apply: trac_5457-symmetric_functions-mz.2.patch
Anne
comment:103 Changed 4 years ago by nthiery
Hi Jeroen,
I am confused: was your intention to request that this change be made for this ticket?
(meaning that you'd have to unmerge / remerge it)
comment:104 Changed 4 years ago by jdemeyer
Short story: for me it was far more important that the problem got
fixed, not how it got fixed.
A situation where a ticket is merged but then problems are discovered is
a difficult situation to handle. In the past, I would have re-opened
the ticket and set it to needs_work but that seems to upset people (they
think it will postpone the merging of their patch). So this time, I
decided not to reopen the ticket but my intention was indeed for the
chances to be made on the same ticket. However, ideally it would have
been done in a separate additional patch, leaving the original
already-merged patch alone. But I certainly would have been happy also
with a new ticket.
I have no idea how any of this affect sage-combinat.
Jeroen.
Hi Mike,
I finished the doctests for the following files:
In particular, at the beginning of sf.py I incorporated the tutorial that Jason and Nicolas
wrote (which was further down the queue) and updated it. I marked them there as coauthors in
that file.
This leaves the doctests for
which I suppose you will do in the next couple of days?
In particular, in the sfa.py the deprecation warnings need to be activated which I have
not yet done.
Best,
Anne