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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
