Opened 11 years ago

Closed 2 years ago

# principal and exponential specializations for symmetric functions

Reported by: Owned by: mantepse mantepse minor sage-9.2 combinatorics principal specialization, exponential specialization, symmetric functions jbandlow, zabrocki, tscrim, darij Martin Rubey Darij Grinberg, Mike Zabrocki N/A cf9e0f2 cf9e0f2802032941595f0b25b9d090da04939bfa

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.

### Changed 11 years ago by mantepse

patch for principal and exponential specialization

### comment:1 Changed 11 years ago by mantepse

• Owner changed from tbd to mantepse

### comment:2 Changed 11 years ago by mantepse

• Component changed from PLEASE CHANGE to combinatorics
• Priority changed from major to minor

### comment:3 Changed 11 years ago by mantepse

• Description modified (diff)

### comment:4 Changed 11 years ago by jbandlow

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 immature--in 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 mantepse

Hi Jason!

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/site-packages/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/site-packages/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 mantepse

I fixed indenting, bugs and added documentation and tests. Feedback welcome!

### comment:7 follow-up: ↓ 8 Changed 11 years ago by jbandlow

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 sage-combinat 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 ; follow-up: ↓ 9 Changed 11 years ago by mantepse

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 jbandlow

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 jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

### comment:11 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:12 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:13 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4

### comment:14 Changed 3 years ago by mantepse

• Branch set to u/mantepse/specializations_for_symmetric_functions

### comment:15 Changed 3 years ago by mantepse

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

• Commit changed from 366774b1099cb93ef6c168d66605af20daff32eb to 1784ac6b8908d23bcaead9498a566fbde4eb1ed6

Branch pushed to git repo; I updated commit sha1. New commits:

 ​1784ac6 fix doctests

### comment:18 Changed 3 years ago by zabrocki

• 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 q-exponential_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 git

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

Thank you, that was an oversight. I hope it is better now!

### comment:21 Changed 3 years ago by mantepse

• Milestone changed from sage-6.4 to sage-8.8
• Status changed from needs_work to needs_review

### comment:23 Changed 3 years ago by embray

• Milestone changed from sage-8.8 to sage-8.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).

ping?

### comment:25 Changed 2 years ago by zabrocki

I think that this needs to be more compatible with Hall-Littlewood 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/(1-q)).coefficient([])
True
sage: f.principal_specialization(n=4,q=q)==f(one*(1-q^4)/(1-q)).coefficient([])
True


### comment:26 Changed 2 years ago by tscrim

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 finite-type 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 zabrocki

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 tscrim

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 zabrocki

From my understanding what you are saying you are recommending behavior like:

sage: SymmetricFunctions(QQ).s()[1].principal_specialization()
1/(1-q)
sage: SymmetricFunctions(SR).s()[1].principal_specialization()
1/(1-z)


### comment:30 Changed 2 years ago by mantepse

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 tscrim

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 mantepse

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 follow-up: ↓ 34 Changed 2 years ago by 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.

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 ; follow-up: ↓ 36 Changed 2 years ago by mantepse

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

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 git

• 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 ; follow-up: ↓ 37 Changed 2 years ago by mantepse

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.

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 tscrim

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 git

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

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 tscrim

This is acceptable to me. Mike?

### comment:41 Changed 2 years ago by zabrocki

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 git

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

Thanks for spotting the misspelling! I created ticket #28843 for the other occurrences of "explicitely" :-)

Last edited 2 years ago by mantepse (previous) (diff)

### comment:44 Changed 2 years ago by mantepse

The startup modules plugin says:

========== startup_modules ==========
git checkout patchbot/ticket_merged
/local/sage-patchbot/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 tscrim

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 git

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

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{1-q^k}{1-t^k} \cdot p_k
for all positive integers k.

In general, this is well-defined 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

Last edited 2 years ago by mantepse (previous) (diff)

### comment:48 follow-up: ↓ 49 Changed 2 years ago by zabrocki

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 mantepse

No it can't be. For theta_qt the q and the t must be in the base_ring.

You are right, I am sorry.

### comment:50 follow-up: ↓ 52 Changed 2 years ago by zabrocki

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 non-stable are demonstrated to be plethysm in that example (n=infinity is "stable", right?)

### comment:51 Changed 2 years ago by git

• 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 ; follow-up: ↓ 54 Changed 2 years ago by mantepse

Dear Mike!

thank you for looking into this, and thank you for your comments. I did the easy ones.

Also in exponential_specialization, I think you should mention "where n is the homogeneous degree of f."

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

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

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 or principal_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 mantepse

I just learnt that there is also a formula for the stable principal specialisation of P-Schur functions, but I'd prefer to keep this for a later ticket.

### comment:54 in reply to: ↑ 52 Changed 2 years ago by zabrocki

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 in t and rational in q.

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 git

• Commit changed from 95de7cf67e3a46ee7b46cb8ebb9b9eebb9634609 to 091010e4266c22147ae63314096d67f6cb22a129

Branch pushed to git repo; I updated commit sha1. New commits:

 ​8bc02d8 documentation improvements ​091010e homogeneous is faster than powersum for schur

### comment:56 Changed 2 years ago by git

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

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 mantepse

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 zabrocki

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

• Milestone changed from sage-8.9 to sage-9.1

Ticket retargeted after milestone closed

### comment:61 Changed 2 years ago by git

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 mantepse

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

I am again needing this for my research. I'd be extremely grateful for a review!

### comment:64 Changed 2 years ago by git

• Commit changed from c53809b3c3ef4fa1e38f72488038bc2f22ad30b9 to 73bced1fc671b6f9c52392dc2673d623ba3ba592

Branch pushed to git repo; I updated commit sha1. New commits:

 ​885eab5 Merge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into principal_specialization ​f3984a9 improvements to doc ​73bced1 redirect through monomial, not powersum

### comment:65 Changed 2 years ago by gh-darijgr

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 (1-q**(n*part))/(1-q**part), which are undefined in general since the denominator can be non-invertible. 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 git

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

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

Hi Darij!

• concerning get_variable, I see it in monomial.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 non-problems:
• 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 follow-up: ↓ 74 Changed 2 years ago by gh-darijgr

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 force-pushed an updated commit where it was not undone. Or is it still?

### comment:70 Changed 2 years ago by git

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

• 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 gh-darijgr

The issues from #69 are still open; I'm worried it might even silently produce wrong results if the / operator gives a non-unique quotient in some non-integral domain.

### comment:73 Changed 2 years ago by mkoeppe

• Milestone changed from sage-9.1 to sage-9.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 mantepse

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 force-pushed 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 gh-darijgr

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 git

• 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:78 Changed 2 years ago by git

• Commit changed from 203b42cce50648cac8cdbdc572a6908a0f0ff780 to 63ee2ec239b479c80eca5a59ce85e41eaff8abfb

Branch pushed to git repo; I updated commit sha1. New commits:

 ​fd59f1f Merge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into princ ​ab1c36b review the doc ​63ee2ec use h, not p, as the base ring might not have 1/n

### comment:79 follow-up: ↓ 81 Changed 2 years ago by gh-darijgr

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

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?

Last edited 2 years ago by gh-darijgr (previous) (diff)

### comment:81 in reply to: ↑ 79 Changed 2 years ago by mantepse

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 git

• 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 gh-darijgr

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 q-binomials are computed in the "wrong" ring.

Last edited 2 years ago by gh-darijgr (previous) (diff)

### comment:84 Changed 2 years ago by mantepse

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

OK, but are the results correct? Do they throw errors?

### comment:86 Changed 2 years ago by git

• Commit changed from 83cc0f36bfb5c82755cb1a5a7fce2a9d1ab577bd to b1434cae7e4e51308e9aeca86a1cc78737540800

Branch pushed to git repo; I updated commit sha1. New commits:

 ​4fb5819 a bit more doc on q-factorials and ex ​b1434ca further corrections

### comment:87 Changed 2 years ago by gh-darijgr

The math is all correct. Now we need to (1) add doctests showing that no bad things happen coercion- and singularity-wise (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 yak-shaving 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 git

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

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

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

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 follow-up: ↓ 94 Changed 2 years ago by gh-darijgr

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

Also, thanks for fixing my doctests (yes, for some reason I thought (x+y)2 = x2 + y2 over GF(3)). Will finish the review tomorrow.

### comment:94 in reply to: ↑ 92 Changed 2 years ago by mantepse

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 git

• Commit changed from 6e4006dace369d2af262b358606af0d7e3561b87 to 7d45a6ce1e91c2964cafa21b6652811fca8e0698

Branch pushed to git repo; I updated commit sha1. New commits:

 ​28b1e2b this way? ​7d45a6c Merge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into princ

### comment:96 Changed 2 years ago by git

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

• 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 gh-darijgr

Do the last two commits look good to you, Martin?

### comment:99 Changed 2 years ago by mantepse

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 follow-up: ↓ 101 Changed 2 years ago by gh-darijgr

But powersum is broken for the reasons I claimed. Which is why I'm for adding all those weird-ring tests.

Are my changes so far OK? I'd then add the tests.

### comment:101 in reply to: ↑ 100 Changed 2 years ago by mantepse

But powersum is broken for the reasons I claimed. Which is why I'm for adding all those weird-ring tests.

I don't completely understand. Am I wrong in assuming that passing from monomial to powersum will not introduce singularities?

### comment:102 follow-up: ↓ 103 Changed 2 years ago by gh-darijgr

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 mantepse

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 git

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

I fixed the doctest and added a comment why we don't use the powersum basis as fallback. Doctests pass on my computer.

### comment:107 Changed 2 years ago by git

• 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 gh-darijgr

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 mantepse

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

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 git

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

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

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

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

• 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 gh-darijgr

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

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 mantepse

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}
**********************************************************************
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 gh-darijgr

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 git

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

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

Ouch. Yes, we can do sorted(str(...) for ...).

### comment:123 Changed 2 years ago by mantepse

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}
**********************************************************************
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 gh-darijgr

Sage is right on all four counts here. Sorry again.

### comment:125 Changed 2 years ago by git

• Commit changed from ccd6902363e5d682913b523d2b353b5352d234ed to bb5d51dea6a6f2c62fe295957bbadccd28f4c5e6

Branch pushed to git repo; I updated commit sha1. New commits:

 ​deaf172 fix doctests ​bb5d51d follow Travis's suggestion about set output

### comment:126 Changed 2 years ago by git

• 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 gh-darijgr

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 git

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

• 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 gh-darijgr

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 git

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

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

Looks good to me!

### comment:134 Changed 2 years ago by gh-darijgr

• Status changed from needs_review to positive_review

Thanks for the merge! Positive review then.

### comment:135 Changed 2 years ago by mantepse

Incredible! 03/14/11 - 04/26/20

### comment:136 Changed 2 years ago by fbissey

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

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

• Status changed from needs_work to positive_review

### comment:139 Changed 2 years ago by gh-darijgr

Thanks, Francois and Matthias!

### comment:140 Changed 2 years ago by vbraun

• Status changed from positive_review to needs_work

PDF docs don't build

### comment:141 Changed 2 years ago by gh-darijgr

Log? I can't run make on cygwin right now.

### comment:142 Changed 2 years ago by git

• 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 gh-darijgr

Found it! Am pushing with force since I've once again rebased the entire branch (with my new commit as second-to-last 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 gh-darijgr

• Status changed from needs_work to positive_review

### comment:145 Changed 2 years ago by vbraun

• Branch changed from public/sf/principal_specialization to cf9e0f2802032941595f0b25b9d090da04939bfa
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.