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: sage-9.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:

Status badges

Description (last modified by zabrocki)

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)

sf_principal_specialization-mr.patch (21.0 KB) - added by mantepse 11 years ago.
patch for principal and exponential specialization

Download all attachments as: .zip

Change History (146)

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!

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/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: 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: Changed 11 years ago by mantepse

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 jbandlow

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

366774brebase 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:

1784ac6fix doctests

comment:17 Changed 3 years ago by mantepse

  • Cc zabrocki added

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:

309e5daadd 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:22 Changed 3 years ago by tscrim

  • Cc tscrim darij added

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

comment:24 Changed 2 years ago by mantepse

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

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

3934475Merge branch 'develop' of git://trac.sagemath.org/sage into t/10930/specializations_for_symmetric_functions

comment:36 in reply to: ↑ 34 ; follow-up: 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

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 git

  • Commit changed from 393447511fb7bcd1ffcd35b65e6b113d5e1f14d7 to c5f5b6152de83a6485b2da73a3524f4f1444d669

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

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

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

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

Replying to zabrocki:

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

95de7cfspecialisation -> specialization, remove erroneous "stable"

comment:52 in reply to: ↑ 50 ; follow-up: 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.

Replying to zabrocki:

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:

8bc02d8documentation improvements
091010ehomogeneous 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:

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

c5f5b61raise error if q is in the base ring, add comment about plethysm
cff572bexplicitely -> explicitly
a19c6f5fix default values for eponential specialisation, import q_analogues locally
94bcb52Merge branch 'u/mantepse/specializations_for_symmetric_functions' of trac.sagemath.org:sage into specialization
95de7cfspecialisation -> specialization, remove erroneous "stable"
8bc02d8documentation improvements
091010ehomogeneous is faster than powersum for schur
bf4e262formulas in documentation, special case exponential specialization for Schur
878257aMerge branch 'u/mantepse/specializations_for_symmetric_functions' of trac.sagemath.org:sage into specialization
6b03addminor 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

  • Commit changed from 6b03adda160e696f261688bbaacef5859abf9b31 to c53809b3c3ef4fa1e38f72488038bc2f22ad30b9

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

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

885eab5Merge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into principal_specialization
f3984a9improvements to doc
73bced1redirect 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:

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

09cdbd4more 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: 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:

e57d1bdcorrect 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

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

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:

203b42cbetter behaviour with respect to removable singularities

comment:77 Changed 2 years ago by mantepse

Please review :-)

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:

fd59f1fMerge branch 'public/sf/principal_specialization' of git://trac.sagemath.org/sage into princ
ab1c36breview the doc
63ee2ecuse h, not p, as the base ring might not have 1/n

comment:79 follow-up: 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

Replying to 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).

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:

83cc0f3some 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:

4fb5819a bit more doc on q-factorials and ex
b1434cafurther 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:

a93ebd4oops, 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:

59a0885update 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:

6e4006dfix 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: 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

Replying to 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).

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:

28b1e2bthis way?
7d45a6cMerge 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:

1c48b47replacing 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:

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

Replying to gh-darijgr:

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

Replying to 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.)

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:

155e0eafix 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:106 Changed 2 years ago by mantepse

(So, please go ahead!)

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:

12e4437test 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:

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

1680397fix 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:

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

96efc4fadd 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:

f0f31e6attempt 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}                                                                                             
**********************************************************************                                                                                
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 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:

ccd6902fix 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}                                                              
**********************************************************************                                                                                
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 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:

deaf172fix doctests
bb5d51dfollow 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:

cad4c9afix doctest, fix comments
326ad0ctest battery for principal_specialization
88030f5attempt at fixing schur principal_spec
9a63445fix quotients
e0a7742similar changes to powersum
08acbefadd doctests for powersums
ed11078attempt at a test battery for exponential specialization
dcae3ddfix doctests
d3ed94ffix doctests
dcded65follow 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:

9e0ce98Revert "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:

cc7462fRevert "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:

b19c0f4replacing ring[name]
155e0eafix doctest, fix comments
12e4437test battery for principal_specialization
d4d652battempt at fixing schur principal_spec
1680397fix quotients
db009efsimilar changes to powersum
96efc4fadd doctests for powersums
f0f31e6attempt at a test battery for exponential specialization
ccd6902fix doctests
679dc74Merge 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:

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

a7a602bsrc/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:

1ab1097attempt at fixing schur principal_spec
d67daddfix quotients
b283d23similar changes to powersum
0e2f95cadd doctests for powersums
e16d524attempt at a test battery for exponential specialization
9777740fix doctests
ab684e7fix doctests
db17045follow Travis's suggestion about set output
f55e4d9oops
cf9e0f2src/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:

1ab1097attempt at fixing schur principal_spec
d67daddfix quotients
b283d23similar changes to powersum
0e2f95cadd doctests for powersums
e16d524attempt at a test battery for exponential specialization
9777740fix doctests
ab684e7fix doctests
db17045follow Travis's suggestion about set output
f55e4d9oops
cf9e0f2src/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.