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 aschilling)

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)

trac_13404-sf-nt.3.patch (111.0 KB) - added by aschilling 8 years ago.

Download all attachments as: .zip

Change History (41)

comment:1 Changed 8 years ago by nthiery

  • Cc schilling added
  • Dependencies set to #13399
  • Description modified (diff)

comment:2 Changed 8 years ago by hthomas

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

comment:3 Changed 8 years ago by saliola

  • Cc saliola added

comment:4 follow-up: Changed 8 years ago by saliola

I agree with Hugh regarding "homogeneous". I prefer "complete" or "complete homogeneous".

comment:5 Changed 8 years ago by nthiery

  • Description modified (diff)

comment:6 Changed 8 years ago by aschilling

  • Cc aschilling added; schilling removed

comment:7 in reply to: ↑ 4 Changed 8 years ago by aschilling

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 zabrocki

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 nthiery

  • 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 nthiery

Oops: the updated patch fixes two remaining fixing doctests and an indirect doctest.

comment:11 follow-up: Changed 8 years ago by nthiery

Green light; all tested passed as well 5.3.rc0 on sage.math.u-psud.fr.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 8 years ago by aschilling

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 nthiery

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: Changed 8 years ago by nthiery

zee is defined as a function around the top of sfa.py.

Cheers,

Nicolas

comment:15 in reply to: ↑ 14 ; follow-up: Changed 8 years ago by aschilling

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: Changed 8 years ago by nthiery

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 aschilling

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: Changed 8 years ago by aschilling

  • Reviewers set to Anne Schilling
  • Status changed from needs_review to positive_review

comment:19 in reply to: ↑ 18 ; follow-up: Changed 8 years ago by 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 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 aschilling

  • Status changed from positive_review to needs_info

comment:21 in reply to: ↑ 19 Changed 8 years ago by nthiery

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 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

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 zabrocki

  • 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: Changed 8 years ago by zabrocki

  • 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: Changed 8 years ago by aschilling

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: Changed 8 years ago by 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

comment:26 in reply to: ↑ 25 Changed 8 years ago by aschilling

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 aschilling

  • Status changed from needs_review to positive_review

comment:28 in reply to: ↑ 25 Changed 8 years ago by nthiery

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 nthiery

  • Authors changed from Nicolas M. Thiéry to Nicolas M. Thiéry, Mike Zabrocki

comment:30 Changed 8 years ago by nthiery

And thanks Anne for the review!

comment:31 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.4 to sage-pending

comment:32 follow-up: Changed 8 years ago by aschilling

  • Dependencies changed from #13399 to #5457
  • Description modified (diff)

comment:33 in reply to: ↑ 32 ; follow-up: Changed 8 years ago by aschilling

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 aschilling

Apply: trac_13404-sf-nt.3.patch

comment:35 Changed 8 years ago by zabrocki

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: Changed 8 years ago by aschilling

  • Milestone changed from sage-pending to sage-5.4

comment:37 in reply to: ↑ 36 Changed 8 years ago by aschilling

The new uploaded patch fixes a doc test failure in relation with #8899.

Anne

comment:38 Changed 8 years ago by aschilling

  • Dependencies changed from #5457 to #5457, #8899

Changed 8 years ago by aschilling

comment:39 Changed 8 years ago by nthiery

I double checked the change and confirm the positive review. Thanks Anne!

comment:40 Changed 8 years ago by jdemeyer

  • Merged in set to sage-5.4.beta1
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.