Opened 11 years ago
Closed 2 years ago
#10930 closed enhancement (fixed)
principal and exponential specializations for symmetric functions
Reported by:  mantepse  Owned by:  mantepse 

Priority:  minor  Milestone:  sage9.2 
Component:  combinatorics  Keywords:  principal specialization, exponential specialization, symmetric functions 
Cc:  jbandlow, zabrocki, tscrim, darij  Merged in:  
Authors:  Martin Rubey  Reviewers:  Darij Grinberg, Mike Zabrocki 
Report Upstream:  N/A  Work issues:  
Branch:  cf9e0f2 (Commits, GitHub, GitLab)  Commit:  cf9e0f2802032941595f0b25b9d090da04939bfa 
Dependencies:  Stopgaps: 
Description (last modified by )
With this patch, you can now do:
sage: s = SymmetricFunctions(QQ).s() sage: x = s[2,2,1] sage: x.principal_specialization() q^4/(q^11  2*q^10 + q^8 + 2*q^6  2*q^5  q^3 + 2*q  1) sage: x.principal_specialization(n=4) q^11 + 2*q^10 + 3*q^9 + 4*q^8 + 4*q^7 + 3*q^6 + 2*q^5 + q^4 sage: x.exponential_specialization() 1/24*t^5 sage: x.exponential_specialization(q=QQ["q"].gen()) (q^4/(q^6 + 3*q^5 + 5*q^4 + 6*q^3 + 5*q^2 + 3*q + 1))*t^5
Implement the principal and exponential specializations for symmetric functions as given in Stanley, Enumerative Combinatorics, Section 7.8.
Attachments (1)
Change History (146)
Changed 11 years ago by
comment:1 Changed 11 years ago by
 Owner changed from tbd to mantepse
comment:2 Changed 11 years ago by
 Component changed from PLEASE CHANGE to combinatorics
 Priority changed from major to minor
comment:3 Changed 11 years ago by
 Description modified (diff)
comment:4 Changed 11 years ago by
Hi Martin,
Thanks submitting this! A quick response to your points above. I'm not sure what you mean by point (1)... can you elaborate?
For point (2), you can use None as the default value, and then do
if q is None: q = self.parent().base_ring().one()
as the first line of your code.
For point (3), quasisymmetric functions are still somewhat immaturein particular they are not in Sage proper. So this is not too big of a concern.
For point (4), yes, there should be more doc and tests. In particular, I find tests like
all( e[mu].principal_specialization(4) == e[mu].expand(4)(1,q,q^2,q^3) for mu in Partitions(4) )
particularly convincing.
comment:5 Changed 11 years ago by
Hi Jason!
Many thanks for your quick comments.
1) Using trace I find
sage: S = SymmetricFunctions(QQ); s=S.s(); f = s[2,1] sage: trace("f.principal_specialization()") > <string>(1)<module>() ipdb> s Call > /home/martin/SAGE/local/lib/python2.6/sitepackages/sage/combinat/sf/sfa.py(1653)principal_specialization() 1652 > 1653 def principal_specialization(self, n=infinity, q=var('q')): 1654 r""" ipdb> s > /home/martin/SAGE/local/lib/python2.6/sitepackages/sage/combinat/sf/sfa.py(1681)principal_specialization() 1680 """ > 1681 from sage.combinat.sf.sf import SymmetricFunctions 1682 p = SymmetricFunctions(self.parent().base_ring()).p() ipdb>
but I was hoping that the principal specialisation from schur.py would be called.
2) Well, currently the actual value of 1 is not used at all (I test q==1 and call principal_specialization without passing q). So my question really is: some day somebody might implement something where the q is actually used. Is it better then if the default is None and the doc says, None should always mean one?
Thanks again!
comment:6 Changed 11 years ago by
I fixed indenting, bugs and added documentation and tests. Feedback welcome!
comment:7 followup: ↓ 8 Changed 11 years ago by
Hi Martin, a few more points:
1) If I'm not mistaken, the function f in the exponential_specialization code for Schur functions is returning the product of the hooks of partition. This can also be done with Partition(partition).hook_product(1)
2) You do not give the result of the test in line 275 of the Schur function code.
3) See this and make sure that your patch satisfies these criteria. Please ask the sagecombinat list if you have any questions about these.
4) Once you have completed all of this, mark the patch as 'Needs Review' (by clicking the button at the bottom of the page). Then the 'Patchbot' will automatically apply and test your code.
Again, many thanks for your good work!
comment:8 in reply to: ↑ 7 ; followup: ↓ 9 Changed 11 years ago by
Replying to jbandlow:
Jason, might it be that you were looking on a different version of the patch? There is no exponential_specialization for Schur functions (I use the generic version) and there is no test in line 275...
On the other hand, I just noticed several other problems with the code. Eg., s[1].exponential_specialization()
doesn't work right now. I also should include tests for calling without any arguments...
comment:9 in reply to: ↑ 8 Changed 11 years ago by
Replying to mantepse:
Hi Martin,
Sorry for the delay. Yes I was looking at the wrong version of the patch last time. Everything on the combinat queue now looks good to me. I think that all that is left is for you to prepare the patch for sage as mentioned in my point (3) above.
comment:10 Changed 9 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:11 Changed 8 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:12 Changed 8 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:13 Changed 8 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:14 Changed 3 years ago by
 Branch set to u/mantepse/specializations_for_symmetric_functions
comment:15 Changed 3 years ago by
 Commit set to 366774b1099cb93ef6c168d66605af20daff32eb
 Description modified (diff)
 Status changed from new to needs_review
New commits:
366774b  rebase and correct

comment:16 Changed 3 years ago by
 Commit changed from 366774b1099cb93ef6c168d66605af20daff32eb to 1784ac6b8908d23bcaead9498a566fbde4eb1ed6
Branch pushed to git repo; I updated commit sha1. New commits:
1784ac6  fix doctests

comment:17 Changed 3 years ago by
 Cc zabrocki added
comment:18 Changed 3 years ago by
 Status changed from needs_review to needs_work
Your description of the definition of principle_specialization
is clear, but all of your exponential_specialization
functions need a description.
The one place that you have a description, it doesn't make sense to me because you seem to explain qexponential_specialization, but not exponential_specialization and they don't clearly seem to be compatible by setting q=1. It wouldn't hurt to add a reference to the definition in the documentation either.
comment:19 Changed 3 years ago by
 Commit changed from 1784ac6b8908d23bcaead9498a566fbde4eb1ed6 to 309e5da091cfc4e31ed7b9e207d1c8971ef1a98a
Branch pushed to git repo; I updated commit sha1. New commits:
309e5da  add documentation

comment:20 Changed 3 years ago by
Thank you, that was an oversight. I hope it is better now!
comment:21 Changed 3 years ago by
 Milestone changed from sage6.4 to sage8.8
 Status changed from needs_work to needs_review
comment:22 Changed 3 years ago by
 Cc tscrim darij added
comment:23 Changed 3 years ago by
 Milestone changed from sage8.8 to sage8.9
Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).
comment:24 Changed 2 years ago by
ping?
comment:25 Changed 2 years ago by
I think that this needs to be more compatible with HallLittlewood and Macdonald symmetric functions because this seems to be one place that they might be used. If the base ring already has a q in it, this creates an expression with two q's.
sage: Ht = SymmetricFunctions(QQ['q,t'].fraction_field()).macdonald().Ht() sage: Ht[2].principal_specialization() (q*q + 1)/(q^3  q^2  q + 1) sage: _.parent() Fraction Field of Univariate Polynomial Ring in q over Fraction Field of Multivariate Polynomial Ring in q, t over Rational Field
and I think that is wrong. What about:
try: q = self.base_ring()('q') except: q = self.base_ring()["q"].fraction_field().gen()
Currently in 'powersum.py' you have just the last line.
Also maybe should have doc tests comparing the principal specialization to plethysm.
sage: one=f.parent().one() sage: f.principal_specialization(q=q)==f(one/(1q)).coefficient([]) True sage: f.principal_specialization(n=4,q=q)==f(one*(1q^4)/(1q)).coefficient([]) True
comment:26 Changed 2 years ago by
I am not sure I agree with you Mike that the q
for the principle specialization should be the same q
as for the Macdonald. For example, at t=0
, the Macdonald q
counts the affine grading whereas the principle specialization q
counts the principle grading after restricting to a finitetype representation. Because of this, I feel they should be different variables (and I would try to have a different name, perhaps q1
, if 'q' in self.base_ring().variable_names_recursive()
). Could you explain more why do you think they should be the same q
?
comment:27 Changed 2 years ago by
I was thinking of applications like The Delta Conjecture (e.g. see Theorem 5.1). My comment is not specific to Macdonald polynomials though, it was just an example. Whatever variable you use, if it is in your base ring it seems that you should be using that letter and not adding another copy of it by default. If you want to use another variable in your specialization you can always add one.
comment:28 Changed 2 years ago by
I see. I think that violates the principle of least surprise: someone trying this method changes the variable in their base ring and suddenly the polynomial behaves differently. If you really wanted that base ring variable, then I think you should pass it as a parameter. So if you want a different variable name, then we should change the default name if q is already on the base ring.
comment:29 Changed 2 years ago by
From my understanding what you are saying you are recommending behavior like:
sage: SymmetricFunctions(QQ).s()[1].principal_specialization() 1/(1q) sage: SymmetricFunctions(SR).s()[1].principal_specialization() 1/(1z)
comment:30 Changed 2 years ago by
I think it is in the long run more user friendly, if the rule that determines which name is used for a variable, or whether a symbol is actually reused, is as simple and predictable as possible. Therefore I would be rather against a "renaming" rule.
comment:31 Changed 2 years ago by
So you would rather it be a part of the base ring then Martin? Or same name (with possibly repeated variable name)?
comment:32 Changed 2 years ago by
I don't mind either way. I guess that having two q's which are different in one expression is more likely to be overlooked, so I guess that checking whether q is there is less bad. I would think that even the casual user might be aware that the base ring contains a q.
Is this OK for you?
A question: it turns out that the explicit fraction_field()
in
try: q = self.base_ring()('q') except: q = self.base_ring()["q"].fraction_field().gen()
is unnecessary. Should I keep it anyway?
comment:33 followup: ↓ 34 Changed 2 years ago by
If you are visually looking at output, then I agree, but if you are programming something, then it will break if you are doing something assuming that the output is a univariate polynomial ring. It is also much easier for the user to pass in the q
of the base ring than to create a new polynomial ring with the variable.
Perhaps as a compromise, we raise an error if there is no q
given but q
is a variable name in the base ring? This is clearly the safest option, and it requires the user to know exactly what they are doing.
Also, I agree with removing the fraction_field
since it is unnecessary.
comment:34 in reply to: ↑ 33 ; followup: ↓ 36 Changed 2 years ago by
Replying to tscrim:
If you are visually looking at output, then I agree, but if you are programming something, then it will break if you are doing something assuming that the output is a univariate polynomial ring. It is also much easier for the user to pass in the
q
of the base ring than to create a new polynomial ring with the variable.
I agree!
Perhaps as a compromise, we raise an error if there is no
q
given butq
is a variable name in the base ring? This is clearly the safest option, and it requires the user to know exactly what they are doing.
I think that is an excellent idea!
Also, I agree with removing the
fraction_field
since it is unnecessary.
will do.
comment:35 Changed 2 years ago by
 Commit changed from 309e5da091cfc4e31ed7b9e207d1c8971ef1a98a to 393447511fb7bcd1ffcd35b65e6b113d5e1f14d7
Branch pushed to git repo; I updated commit sha1. New commits:
3934475  Merge branch 'develop' of git://trac.sagemath.org/sage into t/10930/specializations_for_symmetric_functions

comment:36 in reply to: ↑ 34 ; followup: ↓ 37 Changed 2 years ago by
Perhaps as a compromise, we raise an error if there is no
q
given butq
is a variable name in the base ring? This is clearly the safest option, and it requires the user to know exactly what they
are doing.
I think that is an excellent idea!
Unfortunately, it doesn't work. The base ring could be the symbolic ring.
comment:37 in reply to: ↑ 36 Changed 2 years ago by
Replying to mantepse:
Unfortunately, it doesn't work. The base ring could be the symbolic ring.
We can treat the symbolic ring as special. What I was think was doing
try: if 'q' in self.base_ring().variable_names_recursive(): raise ValueError("q is already a variable name, so you must give the parameter q") else: q = self.base_ring()['q'].gen() except AttributeError: q = self.base_ring()['q'].gen()
For this, they symbolic ring would be treated the same as QQ
, and we would get a univariate polynomial ring over SR
. The other option is just explicitly test for self.base_ring() is SR
and just let q = SR.var('q')
.
comment:38 Changed 2 years ago by
 Commit changed from 393447511fb7bcd1ffcd35b65e6b113d5e1f14d7 to c5f5b6152de83a6485b2da73a3524f4f1444d669
Branch pushed to git repo; I updated commit sha1. New commits:
c5f5b61  raise error if q is in the base ring, add comment about plethysm

comment:39 Changed 2 years ago by
emails crossed :)
I think it's OK to require q to be passed explicitely for the symbolic ring. I would rather not test explicitely for SR
, because it is quite possible to have, for example and some time in future, a polynomial ring which contains all variables.
Since not all rings have variable_names_recursive
, I simply try to convert "q" to a ring element, as Mike proposed.
Are you OK with this version?
comment:40 Changed 2 years ago by
This is acceptable to me. Mike?
comment:41 Changed 2 years ago by
I'll need a little time to try it out. "explicitely" is spelled wrong and I want to check that all coercions are correct.
As long as there is an option to use one of the variables in the ring in case that is what is desired that should be ok.
comment:42 Changed 2 years ago by
 Commit changed from c5f5b6152de83a6485b2da73a3524f4f1444d669 to cff572bcf2428d3f267a9c9272107bca7205d34e
Branch pushed to git repo; I updated commit sha1. New commits:
cff572b  explicitely > explicitly

comment:43 Changed 2 years ago by
Thanks for spotting the misspelling! I created ticket #28843 for the other occurrences of "explicitely" :)
comment:44 Changed 2 years ago by
The startup modules plugin says:
========== startup_modules ========== git checkout patchbot/ticket_merged /local/sagepatchbot/sage/sage c '' Total count: 1687 New: sage.combinat.q_analogues ====================
I am guessing that this happens because I import q_binomial
and q_factorial
in elementary.py
and homogeneous.py
. Should I rather import them locally?
comment:45 Changed 2 years ago by
I think it is better to do them locally as I don't see the extra import making a timing difference.
comment:46 Changed 2 years ago by
 Commit changed from cff572bcf2428d3f267a9c9272107bca7205d34e to a19c6f588381f6e21a58e1684799e65ee0fa4d56
Branch pushed to git repo; I updated commit sha1. New commits:
a19c6f5  fix default values for eponential specialisation, import q_analogues locally

comment:47 Changed 2 years ago by
I just noticed that I overlooked the default values for the exponential specialisation.
I factored out the following little helper function, but I do not know where to put it:
def get_variable(ring, name): try: ring(name) except TypeError: return ring[name].gen() else: raise ValueError("the variable %s is in the base ring, pass it explicitly" % name)
This could also be used in theta_qt
:
def theta_qt(self, q=None, t=None): r""" Return the image of ``self`` under the `q,t`deformed theta endomorphism which sends `p_k` to `\frac{1q^k}{1t^k} \cdot p_k` for all positive integers `k`. In general, this is welldefined outside of the powersum basis only if the base ring is a `\QQ`algebra. INPUT:  ``q``, ``t``  parameters (default: ``None``, in which case 'q' and 't' are used) ... """ parent = self.parent() BR = parent.base_ring() p = parent.realization_of().power() p_self = p(self) if t is None: if hasattr(parent,"t"): t = parent.t else: t = BR(QQ['t'].gen()) if q is None: if hasattr(parent,"q"): q = parent.q else: q = BR(QQ['q'].gen())
same in omega_qt
, nabla
, scalar_qt
, scalar_jack
comment:48 followup: ↓ 49 Changed 2 years ago by
No it can't be. For theta_qt
the q
and the t
must be in the base_ring
.
comment:49 in reply to: ↑ 48 Changed 2 years ago by
Replying to zabrocki:
No it can't be. For
theta_qt
theq
and thet
must be in thebase_ring
.
You are right, I am sorry.
comment:50 followup: ↓ 52 Changed 2 years ago by
I'm still testing this out but here are some initial comments:
"specialisation" > "specialization"
Also in exponential_specialization
, I think you should mention "where n
is the homogeneous degree of f
."
Are you sure that you intended the behavior with t=None
and q=None
? You get expressions where the q
and the t
don't mix well. This is not what I was expecting (maybe this is what you intended, but I'm asking for clarification).
sage: h = SymmetricFunctions(QQ).h() sage: h[3].exponential_specialization(t=None,q=None) ((q^2  2*q + 1)/(q^2 + q + 1))*t^3 sage: _.parent() Univariate Polynomial Ring in t over Fraction Field of Univariate Polynomial Ring in q over Rational Field
This is not what is documented under the INPUT section because it says that
"the default is to create the fraction field of polynomials in t
over the coefficient ring."
Are you sure you don't want to be using self.base_ring()['q,t'].fraction_field()
self.base_ring()['t']['q'].fraction_field()
or more simply SR
for these expressions? When do you anticipate users wanting to calculate the principal or exponential specialization and what will be done with the expressions afterwards?
The calculation for elementary, power sum, monomial and Schur are all handled differently and the documentation for the exponential_specialization
or principal_specialization
is the same. I think that the mathematical formulas used in those methods should be documented.
"Note that the stable principal specialization can be obtained as a plethysm" delete the word "stable" since both the stable and nonstable are demonstrated to be plethysm in that example (n=infinity is "stable", right?)
comment:51 Changed 2 years ago by
 Commit changed from a19c6f588381f6e21a58e1684799e65ee0fa4d56 to 95de7cf67e3a46ee7b46cb8ebb9b9eebb9634609
Branch pushed to git repo; I updated commit sha1. New commits:
95de7cf  specialisation > specialization, remove erroneous "stable"

comment:52 in reply to: ↑ 50 ; followup: ↓ 54 Changed 2 years ago by
Dear Mike!
thank you for looking into this, and thank you for your comments. I did the easy ones.
Replying to zabrocki:
Also in
exponential_specialization
, I think you should mention "wheren
is the homogeneous degree off
."
Could you say precisely where? Currently, it is written, for example in sfa.py
, on line 5543:
By analogy `q`exponential specialization is a ring homomorphism defined on homogeneous symmetric functions `f` of degree `n` as
Or am I misunderstanding you?
Are you sure that you intended the behavior with
t=None
andq=None
? You get expressions where theq
and thet
don't mix well. This is not what I was expecting (maybe this is what you intended, but I'm asking for clarification).sage: h = SymmetricFunctions(QQ).h() sage: h[3].exponential_specialization(t=None,q=None) ((q^2  2*q + 1)/(q^2 + q + 1))*t^3 sage: _.parent() Univariate Polynomial Ring in t over Fraction Field of Univariate Polynomial Ring in q over Rational FieldThis is not what is documented under the INPUT section because it says that "the default is to create the fraction field of polynomials in
t
over the coefficient ring."
Yes, the documentation is inaccurate, because since a few commits ago it returns a polynomial.
Are you sure you don't want to be using
self.base_ring()['q,t'].fraction_field()
self.base_ring()['t']['q'].fraction_field()
or more simplySR
for these expressions? When do you anticipate users wanting to calculate the principal or exponential specialization and what will be done with the expressions afterwards?
I don't think it is wise to use SR
by default, because we always get something polynomial in t
and rational in q
.
What I would do with the result afterwards might be factorisation, evaluation at roots of unity, expanding into Taylor series. In brief: it depends.
What would you expect / like? I admit I don't understand what you mean with "not mixing well".
The calculation for elementary, power sum, monomial and Schur are all handled differently and the documentation for the
exponential_specialization
orprincipal_specialization
is the same. I think that the mathematical formulas used in those methods should be documented.
I agree that this makes sense. It is a lot of work, but I'll do it. It's a shame that I cannot easily inherit the "generic" documentation and append the special stuff.
Thanks again!
comment:53 Changed 2 years ago by
I just learnt that there is also a formula for the stable principal specialisation of PSchur functions, but I'd prefer to keep this for a later ticket.
comment:54 in reply to: ↑ 52 Changed 2 years ago by
Could you say precisely where? Currently, it is written, for example in
sfa.py
, on line 5543:By analogy `q`exponential specialization is a ring homomorphism defined on homogeneous symmetric functions `f` of degree `n` as
I missed that f
was above because it wasn't mentioned in the formula for ex_q(h_n)
. I would suggest moving the "f
of degree n
" down a bit since the formula that immediately follows does not refer to f
, but the one after that does.
I don't think it is wise to use
SR
by default, because we always get something polynomial int
and rational inq
.
Maybe not in SR
, but what about the other rings?
What I would do with the result afterwards might be factorisation, evaluation at roots of unity, expanding into Taylor series. In brief: it depends.
The reason I ask is exactly because of the applications you want because evaluation at roots of unity and Taylor series are pretty tough when you have the ring as Univariate Polynomial Ring in t over Fraction Field of Univariate Polynomial Ring in q over Rational Field
.
What would you expect / like? I admit I don't understand what you mean with "not mixing well".
By "not mixing well" I meant that the expression was a polynomial in t
with coefficients which are rational functions in q
and you can't easily access the two generators at the same time and manipulate those sorts of expressions:
sage: a=h[3].exponential_specialization(t=None,q=None) sage: (t,q)=(a.parent().gen(), a.parent().base_ring().gen())
Even once you do that, I wasn't able to get a Taylor series or evaluate at roots of unity easily. I'm guessing that if you know your application, then this would determine what base ring you would be using and the user would put in specific values for q
and t
.
I agree that this makes sense. It is a lot of work, but I'll do it. It's a shame that I cannot easily inherit the "generic" documentation and append the special stuff.
Maybe the generic implementation and for either power sum or complete symmetric functions is sufficient? There will be significant speedup at q=1 for the Schur basis, but I just checked:
%time h(s[6,6,4,4,3,3,3,2,2,1]).exponential_specialization(t=None,q=None)
runs about twice as fast as
%time s[6,6,4,4,3,3,3,2,2,1].exponential_specialization(t=None,q=None)
on my computer. I would coerce to the complete symmetric functions instead of the power sum.
comment:55 Changed 2 years ago by
 Commit changed from 95de7cf67e3a46ee7b46cb8ebb9b9eebb9634609 to 091010e4266c22147ae63314096d67f6cb22a129
comment:56 Changed 2 years ago by
 Commit changed from 091010e4266c22147ae63314096d67f6cb22a129 to bf4e2629a9ffc5fe0ec9430bfba82a948d47d9a6
Branch pushed to git repo; I updated commit sha1. New commits:
bf4e262  formulas in documentation, special case exponential specialization for Schur

comment:57 Changed 2 years ago by
Since it was easy to do, I implemented the formula for the exponential specialization of Schur functions, which makes a factor of about 5000 in your example.
I also added math to the documentation.
comment:58 Changed 2 years ago by
Dear Mike,
should I switch to rational functions in q
and t
as default for the exponential specialization?
comment:59 Changed 2 years ago by
 Branch changed from u/mantepse/specializations_for_symmetric_functions to public/sf/principal_specialization
 Commit changed from bf4e2629a9ffc5fe0ec9430bfba82a948d47d9a6 to 6b03adda160e696f261688bbaacef5859abf9b31
 Status changed from needs_review to needs_work
I made some changes to the documentation, but there was one comment that I have that I have not yet changed.
In the documentation for the exponential specialization it reads "Note that setting q = 1
in the stable principal specialization is an invalid operation." This should be documented in principal specialization and this should be followed. For instance
sage: e=SymmetricFunctions(QQ).e() sage: e[2].principal_specialization(q=1) +Infinity sage: (e[2]e[1,1]).principal_specialization(q=1) SignError Traceback (most recent call last) ...
That is, I think that you should raise an error in this case. You can remove the comment from exponential specialization and just put it in principal specialization.
Last 10 new commits:
c5f5b61  raise error if q is in the base ring, add comment about plethysm

cff572b  explicitely > explicitly

a19c6f5  fix default values for eponential specialisation, import q_analogues locally

94bcb52  Merge branch 'u/mantepse/specializations_for_symmetric_functions' of trac.sagemath.org:sage into specialization

95de7cf  specialisation > specialization, remove erroneous "stable"

8bc02d8  documentation improvements

091010e  homogeneous is faster than powersum for schur

bf4e262  formulas in documentation, special case exponential specialization for Schur

878257a  Merge branch 'u/mantepse/specializations_for_symmetric_functions' of trac.sagemath.org:sage into specialization

6b03add  minor changes to documentation, mainly punctuation

comment:60 Changed 2 years ago by
 Milestone changed from sage8.9 to sage9.1
Ticket retargeted after milestone closed
comment:61 Changed 2 years ago by
 Commit changed from 6b03adda160e696f261688bbaacef5859abf9b31 to c53809b3c3ef4fa1e38f72488038bc2f22ad30b9
Branch pushed to git repo; I updated commit sha1. New commits:
c53809b  move q=1, stable comment from exponential specialization to principal specialization and raise appropriate error

comment:62 Changed 2 years ago by
 Status changed from needs_work to needs_review
Done, ready for review again  and thank you for the useful comment!
comment:63 Changed 2 years ago by
I am again needing this for my research. I'd be extremely grateful for a review!
comment:64 Changed 2 years ago by
 Commit changed from c53809b3c3ef4fa1e38f72488038bc2f22ad30b9 to 73bced1fc671b6f9c52392dc2673d623ba3ba592
comment:65 Changed 2 years ago by
Before I move on with the review, can you please comment on the following:
 In powersum.py, you have a get_variable function that deals with unspecified q. In monomial.py, you don't. Is it actually unneeded in monomial.py, or have you forgotten to include it?
 In powersum.py, you use fractions like
(1q**(n*part))/(1q**part)
, which are undefined in general since the denominator can be noninvertible. This is probably fine for n == infinity, since the specialization is only defined in limited situations in that case, but for finite n the method should work in full generality. I suggest replacing this fraction by a sum.
comment:66 Changed 2 years ago by
 Commit changed from 73bced1fc671b6f9c52392dc2673d623ba3ba592 to e0b3aa5f7e253a916345733031275511416bef0b
Branch pushed to git repo; I updated commit sha1. New commits:
e0b3aa5  more doc

comment:67 Changed 2 years ago by
 Commit changed from e0b3aa5f7e253a916345733031275511416bef0b to 09cdbd487381741c3efa7508b02601e1a9404e49
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
09cdbd4  more doc

comment:68 Changed 2 years ago by
Hi Darij!
 concerning
get_variable
, I see it inmonomial.py
also, line 427. Or did I misunderstand?
 concerning division by zero: this problem actually affects all bases. The workaround
would be to have q symbolic and then take the limit. I can think of a few problems,
let's first check that they are nonproblems:
 speed for large n and weird coefficient rings
 less nice output when q is symbolic
 Heuristically, redirecting via the monomial basis seems faster in real life examples than via the powersum basis. Did you undo this on purpose?
@@ 5549,8 +5551,8 @@ class SymmetricFunctionAlgebra_generic_Element(CombinatorialFreeModule.Element): {'the stable principal specialization at q=1 is not defined'} """  m = self.parent().realization_of().monomial()  return m(self).principal_specialization(n, q=q) + p = self.parent().realization_of().powersum() + return p(self).principal_specialization(n, q=q)
comment:69 followup: ↓ 74 Changed 2 years ago by
Hi Martin!
 I see
get_variable
defined only 9 times, but there are 6 files and 2 functions in each, so there are probably 3 missing. Sorry if it isn't monomial.py.
 Division by 0 shouldn't affect any basis (in principal_specialization) when n is finite! The definition works just fine, so I think the method should work as well  which I think it doesn't.
 I undid my p>m change by accident (having a file open in two different editors); this is why I then forcepushed an updated commit where it was not undone. Or is it still?
comment:70 Changed 2 years ago by
 Commit changed from 09cdbd487381741c3efa7508b02601e1a9404e49 to e57d1bd5603d795a44e7bec0c40bd887e88cd7e2
Branch pushed to git repo; I updated commit sha1. New commits:
e57d1bd  correct use of n in exponential_specialization documentation in schur.py

comment:71 Changed 2 years ago by
 Description modified (diff)
 Reviewers set to Darij Grinberg, Mike Zabrocki
 Summary changed from specializations for symmetric functions to principal and exponential specializations for symmetric functions
I'm ok with the current implementation and I checked that all tests pass. Darij, do you have any additional comments or changes?
comment:72 Changed 2 years ago by
The issues from #69 are still open; I'm worried it might even silently produce wrong results if the / operator gives a nonunique quotient in some nonintegral domain.
comment:73 Changed 2 years ago by
 Milestone changed from sage9.1 to sage9.2
Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.
comment:74 in reply to: ↑ 69 Changed 2 years ago by
Replying to ghdarijgr:
Hi Martin!
 I see
get_variable
defined only 9 times, but there are 6 files and 2 functions in each, so there are probably 3 missing. Sorry if it isn't monomial.py.
I just checked. No there are none missing. get_variable
is not used in principal_specialization
of monomial.py
and not used at all in sfa.py
.
 Division by 0 shouldn't affect any basis (in principal_specialization) when n is finite! The definition works just fine, so I think the method should work as well  which I think it doesn't.
This is correct, but, for example in schur.py
I don't see a better way than actually computing with indeterminate q
and substituting the value afterwards. Do you think this is worth it?
 I undid my p>m change by accident (having a file open in two different editors); this is why I then forcepushed an updated commit where it was not undone. Or is it still?
Actually, there is some nonsense going on right now, because for q other than 1, the monomial basis redirects to the powersum basis. In any case, I'll add a comment.
comment:75 Changed 2 years ago by
I just checked. No there are none missing. get_variable is not used in principal_specialization of monomial.py and not used at all in sfa.py.
Oh, I see  you're right! The q just gets passed.
This is correct, but, for example in schur.py I don't see a better way than actually computing with indeterminate q and substituting the value afterwards. Do you think this is worth it?
That's what I would do.
comment:76 Changed 2 years ago by
 Commit changed from e57d1bd5603d795a44e7bec0c40bd887e88cd7e2 to 203b42cce50648cac8cdbdc572a6908a0f0ff780
Branch pushed to git repo; I updated commit sha1. New commits:
203b42c  better behaviour with respect to removable singularities

comment:77 Changed 2 years ago by
Please review :)
comment:78 Changed 2 years ago by
 Commit changed from 203b42cce50648cac8cdbdc572a6908a0f0ff780 to 63ee2ec239b479c80eca5a59ce85e41eaff8abfb
comment:79 followup: ↓ 81 Changed 2 years ago by
I've reviewed the docstrings, except for the fact that I'd like to see more doctests for bad cases (such as q = 1).
Will come back to the methods later tonight.
comment:80 Changed 2 years ago by
The get_variable
method uses ring[name]
to adjoin a variable called name
to ring
. I'm not sure how universal this syntax is; if ring
is, say, a realization of the symmetric functions, then this will try (and fail) to pick a basis element. Isn't there a better way?
comment:81 in reply to: ↑ 79 Changed 2 years ago by
Replying to ghdarijgr:
I've reviewed the docstrings, except for the fact that I'd like to see more doctests for bad cases (such as q = 1).
I'll incorporate all doctests you (explicitly!) suggest, OK?
comment:82 Changed 2 years ago by
 Commit changed from 63ee2ec239b479c80eca5a59ce85e41eaff8abfb to 83cc0f36bfb5c82755cb1a5a7fce2a9d1ab577bd
Branch pushed to git repo; I updated commit sha1. New commits:
83cc0f3  some doctests for a start

comment:83 Changed 2 years ago by
I've pushed a few doctests into the principal specialization in elementary.py. This is roughly the kind of stuff I want to test. If you can check that they work (errors can lie both in the tests and the code; I can't run sage on my machine), I'll add similar tests in all other functions.
One other cluster of possible issues I'd like to test is whether _apply_module_morphism
does the necessary coercions for coefficients, seeing that (e.g.) the qbinomials are computed in the "wrong" ring.
comment:84 Changed 2 years ago by
I think it would be better to put these tests into sfa.py
and test all implemened bases at once.
comment:85 Changed 2 years ago by
OK, but are the results correct? Do they throw errors?
comment:86 Changed 2 years ago by
 Commit changed from 83cc0f36bfb5c82755cb1a5a7fce2a9d1ab577bd to b1434cae7e4e51308e9aeca86a1cc78737540800
comment:87 Changed 2 years ago by
The math is all correct. Now we need to (1) add doctests showing that no bad things happen coercion and singularitywise (ideally with some really nasty cases like q=2 in Zmod(4)) and (2) using something better than ring[name]
in the get_variable
methods. Then I'll take one more look at the yakshaving part of the implementations and someone will have to run the doctests as I cannot. Sorry for how long this has been taking; the code is more complicated than it may look at a first sight.
comment:88 Changed 2 years ago by
 Commit changed from b1434cae7e4e51308e9aeca86a1cc78737540800 to a93ebd484f91e3d47513bcb2f6a45087235aee7f
Branch pushed to git repo; I updated commit sha1. New commits:
a93ebd4  oops, there is no is_invertible in general rings

comment:89 Changed 2 years ago by
 Commit changed from a93ebd484f91e3d47513bcb2f6a45087235aee7f to 59a0885dfef955a64459a3dd0da08fdf7930d8aa
Branch pushed to git repo; I updated commit sha1. New commits:
59a0885  update references to Grinberg/Reiner (v6 is out)

comment:90 Changed 2 years ago by
 Commit changed from 59a0885dfef955a64459a3dd0da08fdf7930d8aa to 6e4006dace369d2af262b358606af0d7e3561b87
Branch pushed to git repo; I updated commit sha1. New commits:
6e4006d  fix two doctests

comment:91 Changed 2 years ago by
Redirecting to homogeneous instead of powersum in monomial.py has an interesting side effect:
x.principal_specialization(3, q=var("q")) Expected: 5*(q^6  1)/(q^2  1) + 3*(q^3  1)/(q  1) + 1 Got: 5*(q^3  1)^2/(q  1)^2 + 3*(q^3  1)/(q  1) + 10*(q^4  1)*(q^3  1)/((q^2  1)*(q  1)) + 1
Do we still want this? (I am well aware that this is most likely completely arbitrary.) For the record, redirecting to elementary would give
x.principal_specialization(3, q=var("q")) Expected: 5*(q^6  1)/(q^2  1) + 3*(q^3  1)/(q  1) + 1 Got: 10*(q^3  1)*q/(q  1) + 5*(q^3  1)^2/(q  1)^2 + 3*(q^3  1)/(q  1) + 1
comment:92 followup: ↓ 94 Changed 2 years ago by
Maybe we should use elementary instead of homogeneous then. Either way, we shouldn't use powersum, as it introduces a dependency on 1/n's. I view finite fields as more important than the symbolic ring (which can't ever be assumed completely bulletproof anyway).
comment:93 Changed 2 years ago by
Also, thanks for fixing my doctests (yes, for some reason I thought (x+y)^{2 = x}2 + y^{2 over GF(3)). Will finish the review tomorrow. }
comment:94 in reply to: ↑ 92 Changed 2 years ago by
Replying to ghdarijgr:
Maybe we should use elementary instead of homogeneous then. Either way, we shouldn't use powersum, as it introduces a dependency on 1/n's. I view finite fields as more important than the symbolic ring (which can't ever be assumed completely bulletproof anyway).
I agree, that's an excellent point! Let's always redirect to elementary then, and write this in a comment (that elementary behaves well with respect to introducing singularities and seems fastest).
comment:95 Changed 2 years ago by
 Commit changed from 6e4006dace369d2af262b358606af0d7e3561b87 to 7d45a6ce1e91c2964cafa21b6652811fca8e0698
comment:96 Changed 2 years ago by
 Commit changed from 7d45a6ce1e91c2964cafa21b6652811fca8e0698 to 1c48b472d4e8386a323f975fa2d881a086963707
Branch pushed to git repo; I updated commit sha1. New commits:
1c48b47  replacing ring[name]

comment:97 Changed 2 years ago by
 Commit changed from 1c48b472d4e8386a323f975fa2d881a086963707 to b19c0f436ebdf75eb607dbe6f1f3768e9e95a714
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
b19c0f4  replacing ring[name]

comment:98 Changed 2 years ago by
Do the last two commits look good to you, Martin?
comment:99 Changed 2 years ago by
Actually, I now think that for monomial we should convert to powersum, not to elementary.
If something is nice in the monomial basis, it will also be nice in the powersum basis but not necessarily in the elementary basis, don't you think?
sage: p(m[7,4,2]) p[7, 4, 2]  p[7, 6]  p[9, 4]  p[11, 2] + 2*p[13]
comment:100 followup: ↓ 101 Changed 2 years ago by
But powersum is broken for the reasons I claimed. Which is why I'm for adding all those weirdring tests.
Are my changes so far OK? I'd then add the tests.
comment:101 in reply to: ↑ 100 Changed 2 years ago by
Replying to ghdarijgr:
But powersum is broken for the reasons I claimed. Which is why I'm for adding all those weirdring tests.
I don't completely understand. Am I wrong in assuming that passing from monomial to powersum will not introduce singularities?
comment:102 followup: ↓ 103 Changed 2 years ago by
It will introduce singularities, since the powersum basis isn't a basis unless the base ring contains the rationals. (Of course, if you're doing the exponential specialization at q=1, you need the rationals anyway, but in all the other cases you don't.)
comment:103 in reply to: ↑ 102 Changed 2 years ago by
Replying to ghdarijgr:
It will introduce singularities, since the powersum basis isn't a basis unless the base ring contains the rationals. (Of course, if you're doing the exponential specialization at q=1, you need the rationals anyway, but in all the other cases you don't.)
Oops, sorry, I made a very fundamental mistake, you are right of course (witnessed by p(m[1,1])
.
comment:104 Changed 2 years ago by
 Commit changed from b19c0f436ebdf75eb607dbe6f1f3768e9e95a714 to 155e0ea6ae8d49654989f37b5effb5ac80ebe765
Branch pushed to git repo; I updated commit sha1. New commits:
155e0ea  fix doctest, fix comments

comment:105 Changed 2 years ago by
I fixed the doctest and added a comment why we don't use the powersum basis as fallback. Doctests pass on my computer.
comment:106 Changed 2 years ago by
(So, please go ahead!)
comment:107 Changed 2 years ago by
 Commit changed from 155e0ea6ae8d49654989f37b5effb5ac80ebe765 to 12e4437fdd0defddbda2e349f1bff1400a0c89a4
Branch pushed to git repo; I updated commit sha1. New commits:
12e4437  test battery for principal_specialization

comment:108 Changed 2 years ago by
OK, here are tests for principal_specialization. Can you check that they work before I adapt them for exponential_specialization too?
comment:109 Changed 2 years ago by
There are actually several failures. The first one that fails is
sage: S = SymmetricFunctions(Zmod(4)) sage: B = [S.m(), S.e(), S.h(), S.s(), S.f()] sage: m = S.m(); x = m[3,2,1] sage: set([b(x).principal_specialization(n=4, q=Zmod(4)(2)) for b in B]) ... ZeroDivisionError: inverse of Mod(2, 4) does not exist During handling of the above exception, another exception occurred: ... TypeError: self must be an integral domain.
(It fails for the Schur basis.)
comment:110 Changed 2 years ago by
Can we zoom? Assuming you can easily doctest the file, as we'd probably have to go through this a few times.
comment:111 Changed 2 years ago by
 Commit changed from 12e4437fdd0defddbda2e349f1bff1400a0c89a4 to d4d652b162166f76dddcf5cb394837534effd210
Branch pushed to git repo; I updated commit sha1. New commits:
d4d652b  attempt at fixing schur principal_spec

comment:112 Changed 2 years ago by
 Commit changed from d4d652b162166f76dddcf5cb394837534effd210 to 1680397bd0993fd1ae3351ee888fba2c29103501
Branch pushed to git repo; I updated commit sha1. New commits:
1680397  fix quotients

comment:113 Changed 2 years ago by
 Commit changed from 1680397bd0993fd1ae3351ee888fba2c29103501 to db009ef22d0a31312db15adf199c718e23d2891a
Branch pushed to git repo; I updated commit sha1. New commits:
db009ef  similar changes to powersum

comment:114 Changed 2 years ago by
 Commit changed from db009ef22d0a31312db15adf199c718e23d2891a to 96efc4fc13fdd56976e54120a983b7af0112ef0a
Branch pushed to git repo; I updated commit sha1. New commits:
96efc4f  add doctests for powersums

comment:115 Changed 2 years ago by
 Commit changed from 96efc4fc13fdd56976e54120a983b7af0112ef0a to f0f31e6d8c15695665849ab9fed8687ef74879df
Branch pushed to git repo; I updated commit sha1. New commits:
f0f31e6  attempt at a test battery for exponential specialization

comment:116 Changed 2 years ago by
I've added tests for exponential_specialization; I'm curious to hear what Sage thinks of them.
I haven't tested for removable singularities this time, since there aren't any (all denominators are unavoidable, although there is some occasional cancellation).
comment:117 Changed 2 years ago by
PS. I have no idea why the trac merge is failing. Should we hit it with the rebase hammer?
comment:118 Changed 2 years ago by
There are a few failing tests. I cannot correct them now, so I just paste them here:
File "src/sage/combinat/sf/sfa.py", line 5739, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: (m[2,1]+m[1,1]).exponential_specialization(q=None) Expected: t**2 * (1  q)/(1 + q) Got: ((2*q^3 + q^2 + q)/(q^3 + 2*q^2 + 2*q + 1))*t^3 + (q/(q + 1))*t^2 ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5742, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: (m[2,1]+m[1,1]).exponential_specialization(q=q) Expected: t**2 * (1  q)/(1 + q) Got: ((2*q^3 + q^2 + q)/(q^3 + 2*q^2 + 2*q + 1))*t^3 + (q/(q + 1))*t^2 ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5745, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: (m[2,1]+m[1,1]).exponential_specialization(t=t) Expected: t**2 * (1  q)/(1 + q) Got: 1/2*t^2 ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5748, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: (m[2,1]+m[1,1]).exponential_specialization(q=q, t=t) Expected: t**2 * (1  q)/(1 + q) Got: (2*q^3*t^3 + q^3*t^2 + q^2*t^3 + q^2*t^2 + q*t^3 + q*t^2)/(q^3 + 2*q^2 + 2*q + 1) ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5787, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: set(b[lam].exponential_specialization(q=None).parent() for b in B for lam in lams) Expected: {Fraction Field of Univariate Polynomial Ring in t over Univariate Polynomial Ring in q over Finite Field of size 3, Univariate Polynomial Ring in t over Univariate Polynomial Ring in q over Finite Field of size 3} Got: {Univariate Polynomial Ring in t over Fraction Field of Univariate Polynomial Ring in q over Finite Field of size 3, Univariate Polynomial Ring in t over Univariate Polynomial Ring in q over Finite Field of size 3} ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5819, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: set(b[lam].exponential_specialization(q=q).parent() for b in B for lam in lams) Expected: {Univariate Polynomial Ring in t over Univariate Polynomial Ring in q over Rational Field} Got: {Univariate Polynomial Ring in t over Fraction Field of Univariate Polynomial Ring in q over Rational Field, Univariate Polynomial Ring in t over Univariate Polynomial Ring in q over Rational Field} ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5822, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: set(b[lam].exponential_specialization(q=q, t=1).parent() for b in B for lam in lams) Expected: {Univariate Polynomial Ring in q over Integer Ring} Got: {Fraction Field of Univariate Polynomial Ring in q over Rational Field, Univariate Polynomial Ring in q over Rational Field} ********************************************************************** 1 item had failures: 7 of 46 in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization [1155 tests, 7 failures, 4.81 s]
comment:119 Changed 2 years ago by
Oops  all of these are my careless errors in the doctests. Can you try again after the next commit I'll push in a few seconds? Note that some results may be equivalent but in a different form.
comment:120 Changed 2 years ago by
 Commit changed from f0f31e6d8c15695665849ab9fed8687ef74879df to ccd6902363e5d682913b523d2b353b5352d234ed
Branch pushed to git repo; I updated commit sha1. New commits:
ccd6902  fix doctests

comment:121 Changed 2 years ago by
Can we avoid the doctests outputting a set either by sorting or checking some other condition? Such tests have had a history of being fickle.
comment:122 Changed 2 years ago by
Ouch. Yes, we can do sorted(str(...) for ...).
comment:123 Changed 2 years ago by
sage t src/sage/combinat/sf/sfa.py ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5739, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: m[1,1].exponential_specialization(q=None) Expected: 1/2*t^2 Got: (q/(q + 1))*t^2 ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5742, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: m[1,1].exponential_specialization(q=q) Expected: t^2 * (1  q)/(1 + q) Got: (q/(q + 1))*t^2 ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5748, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: m[1,1].exponential_specialization(q=q, t=t) Expected: t^2 * (1  q)/(1 + q) Got: q*t^2/(q + 1) ********************************************************************** File "src/sage/combinat/sf/sfa.py", line 5794, in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization Failed example: set(b[lam].exponential_specialization(q=q2, t=t2).parent() for b in B for lam in lams) Expected: {Fraction Field of Multivariate Polynomial Ring in q, t over Finite Field of size 3, Multivariate Polynomial Ring in q, t over Finite Field of size 3} Got: {Multivariate Polynomial Ring in q, t over Finite Field of size 3, Fraction Field of Multivariate Polynomial Ring in q, t over Finite Field of size 3} ********************************************************************** 1 item had failures: 4 of 46 in sage.combinat.sf.sfa.SymmetricFunctionAlgebra_generic_Element.exponential_specialization [1155 tests, 4 failures, 4.96 s]  sage t src/sage/combinat/sf/sfa.py # 4 doctests failed 
comment:124 Changed 2 years ago by
Sage is right on all four counts here. Sorry again.
comment:125 Changed 2 years ago by
 Commit changed from ccd6902363e5d682913b523d2b353b5352d234ed to bb5d51dea6a6f2c62fe295957bbadccd28f4c5e6
comment:126 Changed 2 years ago by
 Commit changed from bb5d51dea6a6f2c62fe295957bbadccd28f4c5e6 to dcded652f27390f2e7328379b7135ac1656409e7
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
cad4c9a  fix doctest, fix comments

326ad0c  test battery for principal_specialization

88030f5  attempt at fixing schur principal_spec

9a63445  fix quotients

e0a7742  similar changes to powersum

08acbef  add doctests for powersums

ed11078  attempt at a test battery for exponential specialization

dcae3dd  fix doctests

d3ed94f  fix doctests

dcded65  follow Travis's suggestion about set output

comment:127 Changed 2 years ago by
I've fixed what I believe to be all issues, and rebased the entire branch on the newest develop. And yet the merge is still failing :( Any ideas?
comment:128 Changed 2 years ago by
 Commit changed from dcded652f27390f2e7328379b7135ac1656409e7 to 9e0ce98b30dbd778c45bfa8c4f3956df0c23e2db
Branch pushed to git repo; I updated commit sha1. New commits:
9e0ce98  Revert "update

comment:129 Changed 2 years ago by
 Commit changed from 9e0ce98b30dbd778c45bfa8c4f3956df0c23e2db to cc7462f99ac35e7b703277a1a07a47e27329eb19
Branch pushed to git repo; I updated commit sha1. New commits:
cc7462f  Revert "Revert "update"

comment:130 Changed 2 years ago by
Ignore the last two commits; I thought they'd fix the merge issue, but they didn't.
Any news on the new doctests? If they work right, I'd declare positive review and let it sort itself out once rc2 is out.
comment:131 Changed 2 years ago by
 Commit changed from cc7462f99ac35e7b703277a1a07a47e27329eb19 to 679dc74c1fc114460989d2f805b5a5141911ee97
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
b19c0f4  replacing ring[name]

155e0ea  fix doctest, fix comments

12e4437  test battery for principal_specialization

d4d652b  attempt at fixing schur principal_spec

1680397  fix quotients

db009ef  similar changes to powersum

96efc4f  add doctests for powersums

f0f31e6  attempt at a test battery for exponential specialization

ccd6902  fix doctests

679dc74  Merge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into t/10930/public/sf/principal_specialization

comment:132 Changed 2 years ago by
 Commit changed from 679dc74c1fc114460989d2f805b5a5141911ee97 to ede20159c2be62cb9bebe0d02ddd2e0bea5a4b5a
Branch pushed to git repo; I updated commit sha1. New commits:
ede2015  Merge branch 'develop' into t/10930/public/sf/principal_specialization

comment:133 Changed 2 years ago by
Looks good to me!
comment:134 Changed 2 years ago by
 Status changed from needs_review to positive_review
Thanks for the merge! Positive review then.
comment:135 Changed 2 years ago by
Incredible! 03/14/11  04/26/20
comment:136 Changed 2 years ago by
 Status changed from positive_review to needs_work
Documentation doesn't build because in sage/combinat/sfa.py
you have [GriRei18_]
instead of [GriRei18]_
.
comment:137 Changed 2 years ago by
 Commit changed from ede20159c2be62cb9bebe0d02ddd2e0bea5a4b5a to a7a602b28dc48d88012f261c7e4137ac046877e7
Branch pushed to git repo; I updated commit sha1. New commits:
a7a602b  src/sage/combinat/sf/sfa.py: Fixup markup in docstring

comment:138 Changed 2 years ago by
 Status changed from needs_work to positive_review
comment:139 Changed 2 years ago by
Thanks, Francois and Matthias!
comment:140 Changed 2 years ago by
 Status changed from positive_review to needs_work
PDF docs don't build
comment:141 Changed 2 years ago by
Log? I can't run make on cygwin right now.
comment:142 Changed 2 years ago by
 Commit changed from a7a602b28dc48d88012f261c7e4137ac046877e7 to cf9e0f2802032941595f0b25b9d090da04939bfa
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
1ab1097  attempt at fixing schur principal_spec

d67dadd  fix quotients

b283d23  similar changes to powersum

0e2f95c  add doctests for powersums

e16d524  attempt at a test battery for exponential specialization

9777740  fix doctests

ab684e7  fix doctests

db17045  follow Travis's suggestion about set output

f55e4d9  oops

cf9e0f2  src/sage/combinat/sf/sfa.py: Fixup markup in docstring

comment:143 Changed 2 years ago by
Found it! Am pushing with force since I've once again rebased the entire branch (with my new commit as secondtolast and Matthias's as last).
Last 10 new commits:
1ab1097  attempt at fixing schur principal_spec

d67dadd  fix quotients

b283d23  similar changes to powersum

0e2f95c  add doctests for powersums

e16d524  attempt at a test battery for exponential specialization

9777740  fix doctests

ab684e7  fix doctests

db17045  follow Travis's suggestion about set output

f55e4d9  oops

cf9e0f2  src/sage/combinat/sf/sfa.py: Fixup markup in docstring

comment:144 Changed 2 years ago by
 Status changed from needs_work to positive_review
comment:145 Changed 2 years ago by
 Branch changed from public/sf/principal_specialization to cf9e0f2802032941595f0b25b9d090da04939bfa
 Resolution set to fixed
 Status changed from positive_review to closed
patch for principal and exponential specialization