Nicolas, thanks so much for figuring out where the problem is!
I opened a ticket
http://trac.sagemath.org/sage_trac/ticket/12969
For the record, this problem also occurs in plain sage-5.0 without the new
symmetric function patch in the sage-combinat queue applied that Mike
and I have been working on. The commands there are slightly different:
sage: H = MacdonaldPolynomialsH(QQ)
sage: P = MacdonaldPolynomialsP(QQ)
sage: m = SFAMonomial(P.base_ring())
sage: Ht = MacdonaldPolynomialsHt(QQ)
sage: m(P.one())
m[]
sage: Ht(P.one())
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (1075, 0))
....
TypeError: do not know how to make x (= McdP[]) an element of self (=Macdonald
polynomials in the Ht basis over Fraction Field of Multivariate Polynomial Ring
in q, t over Rational Field)
Mike, you said this does not occur for you. Are you still working with sage-4.8?
But even in sage-4.8 I get the above failure.
Best,
Anne
On 5/17/12 7:30 PM, Nicolas M. Thiery wrote:
> On Thu, May 17, 2012 at 07:27:31PM -0400, Mike Zabrocki wrote:
>> It is the test for the function .nabla() that was failing (I think like 836).
>>
>> sage: Sym = SymmetricFunctions(FractionField(QQ['q','t']))
>> sage: P = Sym.macdonald().P()
>> sage: P([1,1]).nabla()
>> ((q^2*t+q*t^2-2*t)/(q*t-1))*McdP[1, 1] + McdP[2]
>>
>> It seems like calling the qt_kostka functions was interfering with
>> this some how.
>
> Ok. It took me a good hour reducing the darn thing by dichotomy. The
> failure highly depended on the order of evaluation of the different
> doctests. Here is a minimal example that triggers the failure:
>
> R = QQ['q,t'].fraction_field()
> Sym = sage.combinat.sf.sf.SymmetricFunctions(R)
> H = Sym.macdonald().H();
> P = Sym.macdonald().P();
> m = Sym.monomial();
> Ht = Sym.macdonald().Ht();
> m(P.one())
> Ht(P.one())
>
> At the end of the day, this is a bug in the coercion system. Sage does
> not find a path from P to Ht, whereas there definitely is one:
>
> def coercion_graph(self, G = None):
> if G is None:
> G = DiGraph()
> if self not in G.vertices():
> G.add_vertex(self)
> for h in self._introspect_coerce()['_coerce_from_list']:
> coercion_graph(h.domain(), G)
> G.add_edge(h.domain(), self)
> return G
>
> R = QQ['q,t'].fraction_field()
> R.rename("R")
> Sym = sage.combinat.sf.sf.SymmetricFunctions(R); Sym.rename("Sym")
> p = Sym.p(); p.rename("p")
> s = Sym.schur(); s.rename("s")
> e = Sym.elementary(); e.rename("e")
> m = Sym.monomial(); m.rename("m")
> h = Sym.complete(); h.rename("h")
> H = Sym.macdonald().H(); H.rename("H")
> P = Sym.macdonald().P(); P.rename("P")
> J = Sym.macdonald().J(); J.rename("J")
> S = Sym.macdonald().S(); S.rename("S")
> Ht = Sym.macdonald().Ht(); Ht.rename("Ht")
> m.coerce_map_from(P);
> print Ht.coerce_map_from(P)
> G = coercion_graph(Ht)
> G.show()
>
> This is quite bad, for it can appear at any time. We can just hope
> that we won't get hurt too much in practice until coercion is fixed.
> In the short run, you may want to force a coercion P->Ht before
> calling the qt_kostka function (which is the one triggering the
> coercion P->m).
>
> Please open a ticket with the above so that it does not get lost.
>
> Cheers,
> Nicolas
>
> PS: by the way: I added a patch in the queue so that one can now do
>
> sage: s = SymmetricFunctions(QQ).s()
> sage: G = s.coercion_graph()
>
> I won't have the time to work further on it, but anyone willing to
> take it over is welcome.
>
> --
> Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
> http://Nicolas.Thiery.name/
--
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.
