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.