Opened 8 years ago
Closed 8 years ago
#13404 closed enhancement (fixed)
Improved printing for symmetric function bases and misc refactoring
Reported by: | nthiery | Owned by: | sage-combinat |
---|---|---|---|
Priority: | major | Milestone: | sage-5.4 |
Component: | combinatorics | Keywords: | symmetric functions |
Cc: | zabrocki, aschilling, saliola | Merged in: | sage-5.4.beta1 |
Authors: | Nicolas M. Thiéry, Mike Zabrocki | Reviewers: | Anne Schilling |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #5457, #8899 | Stopgaps: |
Description (last modified by )
Due to accumulating history, the names of the various bases of Symmetric functions and variants are not very consistent:
sage: Sym = SymmetricFunctions(FractionField(QQ['q,t'])); Sym Symmetric Functions over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field sage: Sym.s() Symmetric Function Algebra over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field, Schur symmetric functions as basis sage: Sym.macdonald().P() Macdonald polynomials in the P basis over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field sage: Sym.hall_littlewood().P() Hall-Littlewood polynomials in the P basis over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field
This is not consistent either with NCSF/Qsym:
sage: NCSF = NonCommutativeSymmetricFunctions(QQ) sage: NCSF.Psi() Non-Commutative Symmetric Functions over the Rational Field in the Psi basis
Besides, it is verbose and does not support renaming Sym to get shorter names:
sage: Sym.rename("Sym") sage: Sym.s() Symmetric Function Algebra over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field, Schur symmetric functions as basis
I am in the process of refactoring the _repr_ code to improve this:
sage: Sym = SymmetricFunctions(FractionField(QQ['q,t'])); Sym Symmetric Functions over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field sage: Sym.p() Symmetric Functions over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field on the powersum basis
In the following examples, we rename Sym
for brevity:
sage: Sym.rename("Sym"); Sym Sym
Classical bases:
sage: Sym.p() Sym in the powersum basis sage: Sym.m() Sym in the monomial basis sage: Sym.e() Sym in the elementary basis sage: Sym.h() Sym in the homogeneous basis sage: Sym.s() # Mind the capital here Sym in the Schur basis sage: Sym.f() Sym in the forgotten basis
Macdonald polynomials:
sage: Sym.macdonald().P() Sym in the Macdonald P basis sage: Sym.macdonald().Ht() Sym in the Macdonald Ht basis
Macdonald polynomials, with specialized parameters:
sage: Sym.macdonald(q=1).S() Sym in the Macdonald S with q=1 basis sage: Sym.macdonald(q=1,t=3).P() Sym in the Macdonald P with q=1 and t=3 basis
Hall-Littlewood polynomials:
sage: Sym.hall_littlewood().P() Sym in the Hall-Littlewood P basis sage: Sym.hall_littlewood().Qp() Sym in the Hall-Littlewood Qp basis
Hall-Littlewood polynomials, with specialized parameter:
sage: Sym.hall_littlewood(t=1).P() Sym in the Hall-Littlewood P with t=1 basis
Jack polynomials::
sage: Sym.jack().J() Sym in the Jack J basis sage: Sym.jack().P() Sym in the Jack P basis sage: Sym.jack().Q() Sym in the Jack Q basis sage: Sym.jack().Qp() Sym in the Jack Qp basis
Jack polynomials, with specialized parameter::
sage: Sym.jack(t=1).J() Sym in the Jack J with t=1 basis
Zonal polynomials::
sage: Sym.zonal() Sym in the zonal basis
LLT polynomials:
sage: Sym.llt(3).hspin() Sym in the level 3 LLT spin basis sage: Sym.llt(3).hcospin() Sym in the level 3 LLT cospin basis
sage: Sym.kBoundedSubspace(3,1) 3-bounded Symmetric Functions over Rational Field with t=1 sage: SymmetricFunctions(QQ['t']).kBoundedSubspace(3) 3-bounded Symmetric Functions over Univariate Polynomial Ring in t over Rational Field sage: Sym.kschur(3,1) 3-bounded Symmetric Functions over Rational Field with t=1 in the 3-Schur basis also with t=1 sage: Sym.khomogeneous(3) 3-bounded Symmetric Functions over Rational Field with t=1 in the 3-bounded homogeneous basis sage: SymmetricFunctions(QQ['t']).kschur(3) 3-bounded Symmetric Functions over Univariate Polynomial Ring in t over Rational Field in the 3-Schur basis
Apply:
Attachments (1)
Change History (41)
comment:1 Changed 8 years ago by
- Cc schilling added
- Dependencies set to #13399
- Description modified (diff)
comment:2 Changed 8 years ago by
comment:3 Changed 8 years ago by
- Cc saliola added
comment:4 follow-up: ↓ 7 Changed 8 years ago by
I agree with Hugh regarding "homogeneous". I prefer "complete" or "complete homogeneous".
comment:5 Changed 8 years ago by
- Description modified (diff)
comment:6 Changed 8 years ago by
- Cc aschilling added; schilling removed
comment:7 in reply to: ↑ 4 Changed 8 years ago by
Replying to saliola:
I agree with Hugh regarding "homogeneous". I prefer "complete" or "complete homogeneous".
I definitely disagree. Most author abbreviate to "homogeneous". Why is this symbol for this "h" and not "c"? You can change it to "complete homogeneous" if you care about this. But I think just "complete" is a confusing convention.
comment:8 Changed 8 years ago by
I'm not super keen on just the name 'complete,' at least not as an 'only' option. To go with what the textbooks say (since they set they tend to motivate the notation in other references) : to describe the generators h_n, Macdonald uses "complete symmetric function" (but then uses the word 'complete' only rarely elsewhere in the book), Sagan and Stanley uses "complete homogeneous symmetric functions". When I write and I shorten 'complete homogeneous' I go with 'homogeneous' and I can provide lots of references that uses this name. The short name 'h' to me is short for 'homogeneous.' While I don't mind using both names, I would vote against restricting to the name 'complete' only.
comment:9 Changed 8 years ago by
- Description modified (diff)
- Keywords removed
- Status changed from new to needs_review
- Summary changed from Improve _repr_ for macdonald symmetric functions and friends and further cleanup to Improved printing for symmetric function bases and misc refactoring
comment:10 Changed 8 years ago by
Oops: the updated patch fixes two remaining fixing doctests and an indirect doctest.
comment:11 follow-up: ↓ 12 Changed 8 years ago by
Green light; all tested passed as well 5.3.rc0 on sage.math.u-psud.fr.
comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 8 years ago by
I looked over the patch and overall it looks very good to me. Thanks, Nicolas, for making these changes! Just a quick questions: so this is now consistent with NSym and QSym, right?
Here is one question:
sage: SymmetricFunctions(FractionField(QQ['q','t'])).macdonald().P() Macdonald polynomials in the P basis over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field 1017 sage: SymmetricFunctions(FractionField(QQ['q','t'])).macdonald(t=2).P() 1018 Macdonald polynomials in the P basis with t=2 over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field 1019 sage: SymmetricFunctions(FractionField(QQ['q','t'])).macdonald(q=2).P() 1020 Macdonald polynomials in the P basis with q=2 over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field 1021 sage: SymmetricFunctions(FractionField(QQ['q','t'])).macdonald(q=2, t=2).P() 1022 Macdonald polynomials in the P basis with q=2 and t=2 over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field 1023 sage: Sym = SymmetricFunctions(FractionField(QQ['t'])).macdonald() 1024 Traceback (most recent call last): 1025 ... 1026 ValueError: parameter q must be in the base ring 1019 sage: Sym = SymmetricFunctions(FractionField(QQ['q,t'])); Sym.rename("Sym"); Sym 1020 Sym 1021 sage: Sym.macdonald().P() 1022 Sym in the Macdonald P basis 1023 sage: Sym.macdonald(t=2).P() 1024 Sym in the Macdonald P with t=2 basis 1025 sage: Sym.rename() 1026 1027 TESTS:: 1028 1029 sage: Sym.macdonald().P()._prefix 1030 'McdP' 1031 sage: Sym.macdonald().Ht()._prefix 1032 'McdHt'
Don't you want to keep some tests when q is set to a value or both parameters are set to a value?
Also, where is zee specified in this code?
1519 def _dual_basis_default(self): 1520 """ 1521 Returns the default value for ``self.dual_basis()`` 1522 1523 .. SEEALSO:: :meth:`dual_basis` 1524 1525 EXAMPLES: 1526 1527 This default implementation constructs the dual basis using 1528 the standard (Hall) scalar product:: 1529 1530 sage: Sym = SymmetricFunctions(QQ) 1531 sage: Sym.p()._dual_basis_default() 1532 Dual basis to Symmetric Functions over Rational Field in the powersum basis with respect to the Hall scalar product 1533 1534 This is meant to be overiden by subclasses for which an 1535 explicit dual basis is known:: 1536 1537 sage: Sym.s()._dual_basis_default() 1538 Symmetric Functions over Rational Field in the Schur basis 1539 sage: Sym.h()._dual_basis_default() 1540 Symmetric Functions over Rational Field in the monomial basis 1541 sage: Sym.m()._dual_basis_default() 1542 Symmetric Functions over Rational Field in the homogeneous basis 1543 sage: Sym.f()._dual_basis_default() 1544 Symmetric Functions over Rational Field in the elementary basis 1545 sage: Sym.e()._dual_basis_default() 1546 Symmetric Functions over Rational Field in the forgotten basis 1547 """ 1548 return self.dual_basis(scalar=zee, scalar_name = "Hall scalar product")
Other than these questions I am happy to set a positive review!
Anne
comment:13 in reply to: ↑ 12 Changed 8 years ago by
Hi Anne,
Replying to aschilling:
I looked over the patch and overall it looks very good to me. Thanks, Nicolas, for making these changes!
You are welcome!
Just a quick questions: so this is now consistent with NSym and QSym, right?
Yes! Well, almost: there remains the on->in change for NSym and Qsym (and in general "with realizations"), but that's for another patch.
Don't you want to keep some tests when q is set to a value or both parameters are set to a value?
That would have been better indeed. That being said, the doctests of SymmetricFunctionsBases?.ParentMethods?._repr_ includes an example with two parameters, and the failure when q is wrong is tested in Macdonald.init; so if you don't mind I'll be lazy and leave things as is.
Also, where is zee specified in this code?
1519 def _dual_basis_default(self): 1520 ... 1548 return self.dual_basis(scalar=zee, scalar_name = "Hall scalar product") ^^^ Here ?
Other than these questions I am happy to set a positive review!
Thanks!
Cheers,
Nicolas
comment:14 follow-up: ↓ 15 Changed 8 years ago by
zee is defined as a function around the top of sfa.py.
Cheers,
Nicolas
comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 8 years ago by
Could you please also comment on this line in the commit message:
"- Updated to doctests in jack.py: the new outputs are equal but
not identical to the previous ones. Why did it change?"
Could you please be more specific what previous means and what precisely is equal, but not identical?
Anne
comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 8 years ago by
Replying to aschilling:
Could you please be more specific what previous means and what precisely is equal, but not identical?
It's about this hunk:
@@ -363,21 +361,18 @@ class Jack(UniqueRepresentation): sage: Sym = SymmetricFunctions(FractionField(QQ['t'])) sage: JP = Sym.jack().P() sage: JQp = Sym.jack().Qp(); JQp - Jack polynomials in the Qp basis over Fraction Field of Univariate Polynomial Ring in t over Rational Field + Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field in the Jack Qp basis sage: a = JQp([2]) sage: a.scalar(JP([2])) 1 sage: a.scalar(JP([1,1])) 0 sage: JP(JQp([2])) # todo: missing auto normalization - ((-t+1)/(-t-1))*JackP[1, 1] + JackP[2] + ((2*t-2)/(2*t+2))*JackP[1, 1] + JackP[2] sage: JP._normalize(JP(JQp([2]))) - ((-t+1)/(-t-1))*JackP[1, 1] + JackP[2] + ((t-1)/(t+1))*JackP[1, 1] + JackP[2] """
comment:17 in reply to: ↑ 16 Changed 8 years ago by
Yes, this is weird, but I think it is related to the comment "missing auto normalization". Mike and I ran into a similar issue win 5457.
Patch looks good otherwise!
Anne
comment:18 follow-up: ↓ 19 Changed 8 years ago by
- Reviewers set to Anne Schilling
- Status changed from needs_review to positive_review
comment:19 in reply to: ↑ 18 ; follow-up: ↓ 21 Changed 8 years ago by
There is one more thing that Mike pointed out to me. Currently we have
sage: Sym = SymmetricFunctions(FractionField(QQ['t'])) sage: ks = Sym.kschur(4) sage: ks 4-Schur functions with t=t sage: s = Sym.schur() sage: s Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field in the Schur basis
Should ks be changed to
4-Bounded Subspace of Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field in the 4-Schur basis
Thanks,
Anne
comment:20 Changed 8 years ago by
- Status changed from positive_review to needs_info
comment:21 in reply to: ↑ 19 Changed 8 years ago by
Replying to aschilling:
There is one more thing that Mike pointed out to me. Currently we have
sage: Sym = SymmetricFunctions(FractionField(QQ['t'])) sage: ks = Sym.kschur(4) sage: ks 4-Schur functions with t=t sage: s = Sym.schur() sage: s Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field in the Schur basisShould ks be changed to
4-Bounded Subspace of Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field in the 4-Schur basis
Good question. It's a bit long, but has some desirable features besides consistency with realizations/bases:
- The ground field is specified
- It refers to Sym, in such a way that if Sym is renamed to something short, this gets shorter as well
Btw 1: it would be good to have t specified in the name of the kBoundedSubspace.
sage: Sym.kBoundedSubspace(3) 3-bounded Subspace of Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field sage: Sym.kBoundedSubspace(3,1) 3-bounded Subspace of Symmetric Functions over Fraction Field of Univariate Polynomial Ring in t over Rational Field with t = 1
Btw 2: in the docstrings of new_kschur, wouldn't we want to change
sage: KBoundedSubspace(Sym,3,1)
to
sage: Sym.kBoundedSubspace(3,1)
(except probably once in the init, for testing purposes)?
I am not sure I'll have the time to implement that before Tuesday, so feel free to beat me to it.
Cheers,
Nicolas
comment:22 Changed 8 years ago by
- Description modified (diff)
I made the changes to the k-Schur functions and k-bounded subspace names. Both the space and the basis depend on the value of t and the naming follows this dependency. I did not yet change the "Btw 2" that Nicolas mentions so I will not set to "needs review" yet, but let me know if you are satisfied with the naming conventions.
Also I rebased Nicolas' patch to reflect changes in dependencies and changes to #5457 and #13399.
comment:23 follow-up: ↓ 24 Changed 8 years ago by
- Status changed from needs_info to needs_review
Latest patch modifies the doc-tests in new_kschur.py to reflect Nicolas' note "Btw 2". If you are happy with the names, this is ready for review.
comment:24 in reply to: ↑ 23 ; follow-up: ↓ 25 Changed 8 years ago by
Replying to zabrocki:
Latest patch modifies the doc-tests in new_kschur.py to reflect Nicolas' note "Btw 2". If you are happy with the names, this is ready for review.
Hi Mike, the changes look good to me with one exception. Nicolas mentioned in his Btw 2: "(except probably once in the init, for testing purposes)". Could you please leave one of the original kBoundedSubspace tests in the _init_ ?
Other than that, all tests pass for me on sage-5.3.rc0 + 2 5457 patches + 13399 patch.
Anne
comment:25 in reply to: ↑ 24 ; follow-ups: ↓ 26 ↓ 28 Changed 8 years ago by
Hi Mike, the changes look good to me with one exception. Nicolas mentioned in his Btw 2: "(except probably once in the init, for testing purposes)". Could you please leave one of the original kBoundedSubspace tests in the _init_ ?
Thanks for catching that. I had that change but didn't qrefresh before I attached the patch.
Ignore/delete the patch trac_13404_kschur_rename-mz.2.patch ... it was an accident
comment:26 in reply to: ↑ 25 Changed 8 years ago by
Replying to zabrocki:
Hi Mike, the changes look good to me with one exception. Nicolas mentioned in his Btw 2: "(except probably once in the init, for testing purposes)". Could you please leave one of the original kBoundedSubspace tests in the _init_ ?
Thanks for catching that. I had that change but didn't qrefresh before I attached the patch.
Ignore/delete the patch trac_13404_kschur_rename-mz.2.patch ... it was an accident
Ok, looks good and tests pass!
Anne
comment:27 Changed 8 years ago by
- Status changed from needs_review to positive_review
comment:28 in reply to: ↑ 25 Changed 8 years ago by
Replying to zabrocki:
Ignore/delete the patch trac_13404_kschur_rename-mz.2.patch ... it was an accident
Deleted.
Thanks for finalizing this patch!
comment:29 Changed 8 years ago by
comment:30 Changed 8 years ago by
And thanks Anne for the review!
comment:31 Changed 8 years ago by
- Milestone changed from sage-5.4 to sage-pending
comment:32 follow-up: ↓ 33 Changed 8 years ago by
- Dependencies changed from #13399 to #5457
- Description modified (diff)
comment:33 in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 8 years ago by
Hi Nicolas and Mike,
I fodled your two patches together and commuted it past 13399, so that it now only depends on #5457. I did not change any content.
Please and set a positive review if happy!
Anne
comment:34 in reply to: ↑ 33 Changed 8 years ago by
Apply: trac_13404-sf-nt.3.patch
comment:35 Changed 8 years ago by
I've tested and looked it over and I am happy with it. Thanks Anne for doing all the work to get these cleaned up. 12140-comment! It has a positive review already so I'm not changing anything but I am satisfied it seems to apply cleanly and runs as before.
comment:36 follow-up: ↓ 37 Changed 8 years ago by
- Milestone changed from sage-pending to sage-5.4
comment:37 in reply to: ↑ 36 Changed 8 years ago by
The new uploaded patch fixes a doc test failure in relation with #8899.
Anne
comment:38 Changed 8 years ago by
- Dependencies changed from #5457 to #5457, #8899
Changed 8 years ago by
comment:39 Changed 8 years ago by
I double checked the change and confirm the positive review. Thanks Anne!
comment:40 Changed 8 years ago by
- Merged in set to sage-5.4.beta1
- Resolution set to fixed
- Status changed from positive_review to closed
Salut Nicolas--
My 2c:
"in the ... basis", not "on the ... basis".
And for me, I don't think of the h basis as "homogeneous", but rather as "complete". The bases are all homogeneous, after all! I guess some people say "complete homogeneous", and maybe that's best -- it gives the word "complete" more meaning (i.e., the h_i are complete subject to being homogeneous). But maybe I was brought up wrong...
cheers,
Hugh