Re: [sage-combinat-devel] Re: testing new symmetric function functionality
> > > Great, I'll look at this. Apart from that, should we rename the name of > the parameter p in q_analogues to q -- and (in a separate patch) also > make q and t named parameters in qt_catalan_number? > I think that qt_catalan should have named parameters (there are none now while all the other q_analogues do have these parameters). BTW, Christian...you deprecated a_statistic and b_statistic in your patch. I think that you should also change those in the q_analogues.py file. I don't see any objection to renaming the parameter in q_analogues.py to q rather than p. -Mike -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/8AmEC5OgWTcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Mike Zabrocki writes: > Hi Martin, > Maybe you should take a look at scalar_qt in sfa.py > since it is similar to the effect you want to have with > principle specialization. > That function > (a) has parameters which are called q and t > (b) outputs something that uses the variables q and t > even if the symmetric function base_ring does not have q and > t. So I think it should be similar to what you do for the > principle specialization. Great, I'll look at this. Apart from that, should we rename the name of the parameter p in q_analogues to q -- and (in a separate patch) also make q and t named parameters in qt_catalan_number? > So I've been thinking more about why we don't choose > 'always insert.' This option seems to be more along > the lines of 'there is no fixed base_ring.' > For instance if I take > sage: s = SymmetricFunctions(QQ).schur() > sage: Ht = SymmetricFunctions(QQ['q','t'].fraction_field()).macdonald().Ht() > sage: s(Ht[2,1]) that's a very convincing example :-) Thank you, Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Hi Martin, Maybe you should take a look at scalar_qt in sfa.py since it is similar to the effect you want to have with principle specialization. That function (a) has parameters which are called q and t (b) outputs something that uses the variables q and t even if the symmetric function base_ring does not have q and t. So I think it should be similar to what you do for the principle specialization. So I've been thinking more about why we don't choose 'always insert.' This option seems to be more along the lines of 'there is no fixed base_ring.' For instance if I take sage: s = SymmetricFunctions(QQ).schur() sage: Ht = SymmetricFunctions(QQ['q','t'].fraction_field()).macdonald().Ht() sage: s(Ht[2,1]) Then what should be the behavior? option 1: (I've taken this extreme): error! option 2: there is the middle of the road: Ht.q and Ht.t exist and they are not in the base ring for s, so lets insert them option 3: forget what the base ring of s is now, make it the base ring of Ht A new option is to follow the commands: sage: Ht = SymmetricFunctions(FractionField(QQ['q','t'])).macdonald().Ht() sage: s = Ht.parent().parent().schur() sage: s(Ht[2,1]) -Mike On Saturday, 9 June 2012 03:06:13 UTC-4, Martin wrote: > > Mike Zabrocki writes: > > > Hi Martin > > > > I find this slightly confusing... > > > > I think that p is there to differentiate the variable name (which is p > > probably short for 'parameter') from the variable value (which is by > > default q). > > Sorry, I wasn't clear enough: what I find confusing is that in the q_* > case the name of the argument is "p", while in the symmetric function > world it is "q". Maybe, to make it clearer: at some point we might > want to have q,t analogues, too - actually, we do have > qt_catalan_number. Should we then have > > qt_catalan_number(n, p="q", s="t") > > ? I'd really prefer to change them all to "q" and "t"! > > > You don't actually need to have the "p=" in your > > command for it to work, > > Ah, yes, this is since the named parameters are filled by position if no > name is given, right? > > >> Is there a (short) summary why Macdonald polynomials should not add q > >> and t to the ring if necessary? > > Let me try. OK...this is not short, but since it is a choice, it means > > to argue this that I have to outline all possibilities and try to > > explain why there is a preference for one over another. > > > Given the way the setup is now however, we have the possible sequence > > of commands: > > sage: Sym = SymmetricFunctions(QQ) > > sage: s = Sym.schur() > > sage: MHt = Sym.macdonald().Ht() > > sage: s(Ht[3,2]) > > What should be the behavior ? Maybe the user just failed to specify the > parameters. > > alternative 1: raise an error at "MHt = ..." because q,t are not in the > base ring > > alternative 2: q and t are inserted in the base ring for MHt, but > s(MHt[3,2]) > > raises an error because q,t are not in the base ring for s > > alternative 3: insert q and t in the base ring for Sym and s and MHt > > > > It seems like alternative 3 is taking too many liberties, and we decided > > from the discussion to choose 1 instead of 2 (although, it isn't that > hard > > to make alternative 2 the convention). > > > > As it is, it is a choice to add or not add the parameter to > > the base ring and in this case it is mostly for consistency and to > > force the user to think about having the parameters which are > > being used in the base ring. > > OK, many thanks! (I would have chosen "always insert", but I can > understand the choice). However, since it is "not insert" this really > raises the (not extremely important) question for me in which rings the > various specialisations should live. For example, we currently have > > sage: SF = SymmetricFunctions(QQ) > sage: s = SF.schur() > sage: x = s[2,1] > sage: y = x.principal_specialization(); y > -q/((q - 1)^2*(q^3 - 1)) > sage: y.parent() > Symbolic Ring > > I guess Symbolic Ring is about the worst choice I could make (I didn't > know how to make it anything else), but according to the philosophy "not > insert", it should simply raise an error, right? > > How would I do that? (I.e., which error should I trap?) > > (in fact, it should only work with QQ replaced by a rational function > field containing q, right?) > > Martin > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/dOq-yoY1SXcJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Mike Zabrocki writes: > Hi Martin > > I find this slightly confusing... > > I think that p is there to differentiate the variable name (which is p > probably short for 'parameter') from the variable value (which is by > default q). Sorry, I wasn't clear enough: what I find confusing is that in the q_* case the name of the argument is "p", while in the symmetric function world it is "q". Maybe, to make it clearer: at some point we might want to have q,t analogues, too - actually, we do have qt_catalan_number. Should we then have qt_catalan_number(n, p="q", s="t") ? I'd really prefer to change them all to "q" and "t"! > You don't actually need to have the "p=" in your > command for it to work, Ah, yes, this is since the named parameters are filled by position if no name is given, right? >> Is there a (short) summary why Macdonald polynomials should not add q >> and t to the ring if necessary? > Let me try. OK...this is not short, but since it is a choice, it means > to argue this that I have to outline all possibilities and try to > explain why there is a preference for one over another. > Given the way the setup is now however, we have the possible sequence > of commands: > sage: Sym = SymmetricFunctions(QQ) > sage: s = Sym.schur() > sage: MHt = Sym.macdonald().Ht() > sage: s(Ht[3,2]) > What should be the behavior ? Maybe the user just failed to specify the > parameters. > alternative 1: raise an error at "MHt = ..." because q,t are not in the base > ring > alternative 2: q and t are inserted in the base ring for MHt, but s(MHt[3,2]) > raises an error because q,t are not in the base ring for s > alternative 3: insert q and t in the base ring for Sym and s and MHt > > It seems like alternative 3 is taking too many liberties, and we decided > from the discussion to choose 1 instead of 2 (although, it isn't that hard > to make alternative 2 the convention). > > As it is, it is a choice to add or not add the parameter to > the base ring and in this case it is mostly for consistency and to > force the user to think about having the parameters which are > being used in the base ring. OK, many thanks! (I would have chosen "always insert", but I can understand the choice). However, since it is "not insert" this really raises the (not extremely important) question for me in which rings the various specialisations should live. For example, we currently have sage: SF = SymmetricFunctions(QQ) sage: s = SF.schur() sage: x = s[2,1] sage: y = x.principal_specialization(); y -q/((q - 1)^2*(q^3 - 1)) sage: y.parent() Symbolic Ring I guess Symbolic Ring is about the worst choice I could make (I didn't know how to make it anything else), but according to the philosophy "not insert", it should simply raise an error, right? How would I do that? (I.e., which error should I trap?) (in fact, it should only work with QQ replaced by a rational function field containing q, right?) Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Hi Martin I find this slightly confusing... > I think that p is there to differentiate the variable name (which is p probably short for 'parameter') from the variable value (which is by default q). You don't actually need to have the "p=" in your command for it to work, sage: from sage.combinat.q_analogues import q_int sage: t = QQ['t'].gen() sage: q_int(3,t) t^2 + t + 1 sage: q_int(3) q^2 + q + 1 sage: q_int(3,3) 13 > Is there a (short) summary why Macdonald polynomials should not add q > and t to the ring if necessary? Let me try. OK...this is not short, but since it is a choice, it means to argue this that I have to outline all possibilities and try to explain why there is a preference for one over another. In some ways I like the idea of inserting the q,t in the base ring to make sage more user friendly, but it doesn't work if then they try to change to a classical basis that does not have these parameters and you want the user to be conscientious of what parameters are or are not in the base ring. In other words, it is helpful to add the q,t into the Macdonald basis if all you are going to do is multiply in that basis or change to other Macdonald bases, but it is not helpful if you you change to a classical basis, because then you have to make sure that those parameters are in the base ring of your classical basis anyway. Here you are asking sage to anticipate what the user wants and does not want. When the user types Sym.macdonald() you assume that they want Sym.macdonald(q,t) instead of specializing the parameters in the ring. Given the way the setup is now however, we have the possible sequence of commands: sage: Sym = SymmetricFunctions(QQ) sage: s = Sym.schur() sage: MHt = Sym.macdonald().Ht() sage: s(Ht[3,2]) What should be the behavior ? Maybe the user just failed to specify the parameters. alternative 1: raise an error at "MHt = ..." because q,t are not in the base ring alternative 2: q and t are inserted in the base ring for MHt, but s(MHt[3,2]) raises an error because q,t are not in the base ring for s alternative 3: insert q and t in the base ring for Sym and s and MHt It seems like alternative 3 is taking too many liberties, and we decided from the discussion to choose 1 instead of 2 (although, it isn't that hard to make alternative 2 the convention). As it is, it is a choice to add or not add the parameter to the base ring and in this case it is mostly for consistency and to force the user to think about having the parameters which are being used in the base ring. -Mike -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/FLYzvHoJ7SMJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Mike Zabrocki writes: > Hi Franco, > > I will add the Error message improvement to my list of > things to fix (Anne has also identified a number of issues that > I need to address yet). One tiny, possibly unrelated question: I noticed that q_int, q_binomial, q_factorial take "p" as optional named parameter. On the other hand, the principal and the exponential specialization take "q" as optional named parameter, and I think the Macdonald polynomials, too. I.e. sage: R. = PolynomialRing(QQ) sage: q_int(3, p=t) t^2 + t + 1 I find this slightly confusing... Another, possibly related thing: once the question of base ring is settled, I think it would be good to also rethink the default choice for the specialisations, too. Of course, it's a slightly different story, because they don't return symmetric functions... Is there a (short) summary why Macdonald polynomials should not add q and t to the ring if necessary? Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Hi Mike, > I will add the Error message improvement to my list of > things to fix (Anne has also identified a number of issues that > I need to address yet). The idea behind the choice is that > we don't want to assume that the user wants sage to change > the base ring just to use Macdonald polynomials. > One possibility is that we set the default base ring to be > QQ['q','t'].fraction_field() so that a call of the form > Sym = SymmetricFunctions() automatically assumes that > the base ring is a space where all the bases are defined. > > This is not the behavior now, do you think this is a good idea? I think this is a bad idea since often people will just want to work in Sym = SymmetricFunctions(QQ) rather than over QQ['q','t'].fraction_field(). Best, Anne -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: testing new symmetric function functionality
Hi Franco,
I will add the Error message improvement to my list of
things to fix (Anne has also identified a number of issues that
I need to address yet). The idea behind the choice is that
we don't want to assume that the user wants sage to change
the base ring just to use Macdonald polynomials.
One possibility is that we set the default base ring to be
QQ['q','t'].fraction_field() so that a call of the form
Sym = SymmetricFunctions() automatically assumes that
the base ring is a space where all the bases are defined.
This is not the behavior now, do you think this is a good idea?
I have a general question to everyone though.
Right now .parent() doesn't return much from these objects.
I think that it should have the following behavior...
If we define:
sage: Sym = SymmetricFunctions(QQ['q','t'].fraction_field())
sage: Mac = Sym.macdonald()
sage: MP = Mac.P()
sage: f = MP[3,2] + MP[2,2,1]
I think that
f.parent() == MP
MP.parent() == Mac
and
Mac.parent() == Sym
should all be True.
Currently only the first returns True and the others don't have a parent().
Is the .parent() method what I think it is? What should Sym.parent() be?
-Mike
should all return true.
On Thursday, 7 June 2012 12:26:15 UTC-4, Mike Zabrocki wrote:
>
> Hey SFA users...
>
> I've been working on a patch to change how symmetric functions are used in
> the future. I will be deprecating some common functions soon on the sage
> combinat queue and we will try to get this into sage in an upcoming
> version. Starting soon: SFAxxx where xxx in {Schur, Monomial, Homogeneous,
> Elementary, Power} will not be the way to access these functions.
>
> Old notation:
> sage: s = SFASchur(QQ)
> sage: h = SFAHomogeneous(QQ)
> sage: e = SFAElementary(QQ)
> ...
>
> The new notation will be:
> sage: SF = SymmetricFunctions(QQ)
> sage: s = SF.schur() # or .s()
> sage: h = SF.homogeneous() # or .h()
> sage: e = SF.elementary() # or .e()
> sage: p = SF.power() # or .p()
> sage: m = SF.monomial() # or .m()
>
> Moreover, LLT polynomials, Hall-Littlewood, Jack and Macdonald symmetric
> functions have all been moved into SymmetricFunctions(R).
>
> sage: Mac = SF.macdonald()
> gives an error because q and t are not in the ring! (this is different
> behavior than before where the q and t were added to the base ring)
>
> New notation:
> sage: SF = SymmetricFunctions(QQ['q','t'].fraction_field())
> sage: Mac = SF.macdonald()
> sage: MP = Mac.P() # or .Q() or .J() or .H() or .Ht()
> sage: HL = SF.hall_littlewood()
> sage: HLP = HL.P() # or .Q() or .Qp()
> sage: Jack = SF.jack()
> sage: JP = Jack.P() # or .Q() or .Qp() or .J()
> sage: LLT = SF.llt(2) # 2 is the level here which needs to be specified
> sage: HS = LLT.hspin() # .hcospin()
>
> The real improvements are behind the scenes. Your field can be more
> general than before and your q and t parameters should be something in that
> field.
> sage: SF = SymmetricFunctions(QQ['x','y'].fraction_field()); (x,y) =
> SF.base_ring().gens()
> sage: MPxy = SF.macdonald(q=x,t=y).P()
> sage: MPy5 = SF.macdonald(q=y,t=5).P()
> sage: MPy5(MPxy[2,1])
>
> Other changes include bringing .omega_qt(), .scalar_qt() and .nabla() to
> all bases and adding q=value, t=value as optional parameters.
> I could use some help testing. If you use symmetric functions and notice
> any bad behavior please pass along odd doc tests.
>
> If you want functionality does not seem to be part of these changes,
> please feel free to add your two cents.
>
> -Mike
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/exnOtHS4rVYJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: testing new symmetric function functionality
Hi Mike,
I did some timing tests on the old and new code:
sage: Sym = SymmetricFunctions(QQ['q','t'].fraction_field())
sage: s = Sym.schur()
sage: m = Sym.monomial()
sage: timeit('m(s([6,3,3,2,1]))')
25 loops, best of 3: 8.51 ms per loop
sage: timeit('m(s([10,6,3,3,2,1]))')
5 loops, best of 3: 214 ms per loop
sage: M = Sym.macdonald()
sage: Ht = M.Ht()
sage: timeit('s(Ht([4,2,1]))')
5 loops, best of 3: 16.2 ms per loop
as compared to
sage: Ht = MacdonaldPolynomialsHt(QQ)
sage: s = SFASchur(Ht.base_ring())
sage: m = SFAMonomial(Ht.base_ring())
sage: timeit('m(s([6,3,3,2,1]))')
25 loops, best of 3: 8.25 ms per loop
sage: timeit('m(s([10,6,3,3,2,1]))')
5 loops, best of 3: 211 ms per loop
sage: timeit('s(Ht([4,2,1]))')
5 loops, best of 3: 16.1 ms per loop
So the new code seems only very slightly (negligibly?) slower.
Best,
Anne
On 6/7/12 9:37 AM, Mike Zabrocki wrote:
> Hi,
> I should add that one thing that should really be tested in addition to
> behavior is *speed*!
>
> With these changes there might be potential slow-down from previous versions.
> We don't want this to happen. I've tested a bit, but this is one thing that
> is even more difficult to identify than a bad doc test.
>
> If there is some functionality that you use in particular I am asking for
> testers who are willing to run heavy computations with and without the patch
> applied to try to identify where the changes I
> have made may have slowed things down. The changes I have made with the
> classical bases are minor, but with Hall-Littlewood, Jacks, Macdonald and LLT
> had their caches shaken up a bit. Please let me
> know if you notice slow downs (or improvements).
>
> -Mike
>
> On Thursday, 7 June 2012 12:26:15 UTC-4, Mike Zabrocki wrote:
>
> Hey SFA users...
>
> I've been working on a patch to change how symmetric functions are used
> in the future. I will be deprecating some common functions soon on the sage
> combinat queue and we will try to get this into
> sage in an upcoming version. Starting soon: SFAxxx where xxx in {Schur,
> Monomial, Homogeneous, Elementary, Power} will not be the way to access these
> functions.
>
> Old notation:
> sage: s = SFASchur(QQ)
> sage: h = SFAHomogeneous(QQ)
> sage: e = SFAElementary(QQ)
> ...
>
> The new notation will be:
> sage: SF = SymmetricFunctions(QQ)
> sage: s = SF.schur() # or .s()
> sage: h = SF.homogeneous() # or .h()
> sage: e = SF.elementary() # or .e()
> sage: p = SF.power() # or .p()
> sage: m = SF.monomial() # or .m()
>
> Moreover, LLT polynomials, Hall-Littlewood, Jack and Macdonald symmetric
> functions have all been moved into SymmetricFunctions(R).
>
> sage: Mac = SF.macdonald()
> gives an error because q and t are not in the ring! (this is different
> behavior than before where the q and t were added to the base ring)
>
> New notation:
> sage: SF = SymmetricFunctions(QQ['q','t'].fraction_field())
> sage: Mac = SF.macdonald()
> sage: MP = Mac.P() # or .Q() or .J() or .H() or .Ht()
> sage: HL = SF.hall_littlewood()
> sage: HLP = HL.P() # or .Q() or .Qp()
> sage: Jack = SF.jack()
> sage: JP = Jack.P() # or .Q() or .Qp() or .J()
> sage: LLT = SF.llt(2) # 2 is the level here which needs to be specified
> sage: HS = LLT.hspin() # .hcospin()
>
> The real improvements are behind the scenes. Your field can be more
> general than before and your q and t parameters should be something in that
> field.
> sage: SF = SymmetricFunctions(QQ['x','y'].fraction_field()); (x,y) =
> SF.base_ring().gens()
> sage: MPxy = SF.macdonald(q=x,t=y).P()
> sage: MPy5 = SF.macdonald(q=y,t=5).P()
> sage: MPy5(MPxy[2,1])
>
> Other changes include bringing .omega_qt(), .scalar_qt() and .nabla() to
> all bases and adding q=value, t=value as optional parameters.
> I could use some help testing. If you use symmetric functions and notice
> any bad behavior please pass along odd doc tests.
>
> If you want functionality does not seem to be part of these changes,
> please feel free to add your two cents.
>
> -Mike
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: testing new symmetric function functionality
Hi,
I should add that one thing that should really be tested in addition to
behavior is *speed*!
With these changes there might be potential slow-down from previous
versions.
We don't want this to happen. I've tested a bit, but this is one thing
that is even more difficult to identify than a bad doc test.
If there is some functionality that you use in particular I am asking for
testers who are willing to run heavy computations with and without the
patch applied to try to identify where the changes I have made may have
slowed things down. The changes I have made with the classical bases are
minor, but with Hall-Littlewood, Jacks, Macdonald and LLT had their caches
shaken up a bit. Please let me know if you notice slow downs (or
improvements).
-Mike
On Thursday, 7 June 2012 12:26:15 UTC-4, Mike Zabrocki wrote:
>
> Hey SFA users...
>
> I've been working on a patch to change how symmetric functions are used in
> the future. I will be deprecating some common functions soon on the sage
> combinat queue and we will try to get this into sage in an upcoming
> version. Starting soon: SFAxxx where xxx in {Schur, Monomial, Homogeneous,
> Elementary, Power} will not be the way to access these functions.
>
> Old notation:
> sage: s = SFASchur(QQ)
> sage: h = SFAHomogeneous(QQ)
> sage: e = SFAElementary(QQ)
> ...
>
> The new notation will be:
> sage: SF = SymmetricFunctions(QQ)
> sage: s = SF.schur() # or .s()
> sage: h = SF.homogeneous() # or .h()
> sage: e = SF.elementary() # or .e()
> sage: p = SF.power() # or .p()
> sage: m = SF.monomial() # or .m()
>
> Moreover, LLT polynomials, Hall-Littlewood, Jack and Macdonald symmetric
> functions have all been moved into SymmetricFunctions(R).
>
> sage: Mac = SF.macdonald()
> gives an error because q and t are not in the ring! (this is different
> behavior than before where the q and t were added to the base ring)
>
> New notation:
> sage: SF = SymmetricFunctions(QQ['q','t'].fraction_field())
> sage: Mac = SF.macdonald()
> sage: MP = Mac.P() # or .Q() or .J() or .H() or .Ht()
> sage: HL = SF.hall_littlewood()
> sage: HLP = HL.P() # or .Q() or .Qp()
> sage: Jack = SF.jack()
> sage: JP = Jack.P() # or .Q() or .Qp() or .J()
> sage: LLT = SF.llt(2) # 2 is the level here which needs to be specified
> sage: HS = LLT.hspin() # .hcospin()
>
> The real improvements are behind the scenes. Your field can be more
> general than before and your q and t parameters should be something in that
> field.
> sage: SF = SymmetricFunctions(QQ['x','y'].fraction_field()); (x,y) =
> SF.base_ring().gens()
> sage: MPxy = SF.macdonald(q=x,t=y).P()
> sage: MPy5 = SF.macdonald(q=y,t=5).P()
> sage: MPy5(MPxy[2,1])
>
> Other changes include bringing .omega_qt(), .scalar_qt() and .nabla() to
> all bases and adding q=value, t=value as optional parameters.
> I could use some help testing. If you use symmetric functions and notice
> any bad behavior please pass along odd doc tests.
>
> If you want functionality does not seem to be part of these changes,
> please feel free to add your two cents.
>
> -Mike
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/BL6LbzXBo6wJ.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
