PartitionTuples.cardinality has problems

[pdehaye]

It works for smaller values.

sage: PartitionTuples(100,13).cardinality()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/Volumes/Scratch/Users/duser1/sage/<ipython console> in <module>()

/Users/duser1/sage/local/lib/python2.6/site-packages/sage/combinat/partition.pyc in cardinality(self)
   3183             185
   3184         """
-> 3185         return ZZ(gp.eval('polcoeff(1/eta(x)^%s, %s, x)'%(self.k, self.n)))
   3186 
   3187 

/Users/duser1/sage/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:6820)()

/Users/duser1/sage/local/lib/python2.6/site-packages/sage/structure/coerce_maps.so in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3254)()

/Users/duser1/sage/local/lib/python2.6/site-packages/sage/structure/coerce_maps.so in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3157)()

/Users/duser1/sage/local/lib/python2.6/site-packages/sage/rings/integer.so in sage.rings.integer.Integer.__init__ (sage/rings/integer.c:7212)()

TypeError: unable to convert x (=  ***   at top-level: polcoeff(1/eta(x)^13
  ***                 ^--------------------
  *** polcoeff: non existent component in truecoeff.) to an integer
sage: 

As noted below, this turned out to just be an issue of increasing the precision in the pari function call. The attached patch fixes the problem:

Attach trac_11476--fixing-partition-tuples_cardinality-am.patch

[andrew.mathas]

This seems to be problem in the pari function call, or possibly a bug in pari. I have  emailed the pari development group to ask them about it.

This failure appears much earlier than the example above suggests:

sage: PartitionTuples(17,2).cardinality()
...
TypeError: unable to convert x (=  ***   at top-level: polcoeff(1/eta(x)^2,
  ***                 ^--------------------
  *** polcoeff: non existent component in truecoeff.) to an integer

If you run pari natively you get the error more quickly:

Desktop: sage -gp
GP/PARI CALCULATOR Version 2.5.2 (development git-b703ee3)
i386 running darwin (x86-64/GMP-5.0.2 kernel) 64-bit version
compiled: Sep 12 2012, gcc-4.6.3 (GCC) 
(readline v6.2 enabled, extended help enabled)

Copyright (C) 2000-2011 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 500509
? polcoeff(1/eta(x)^2, 16, x)
%1 = 5822
? polcoeff(1/eta(x)^2, 17, x)
  ***   at top-level: polcoeff(1/eta(x)^2,
  ***                 ^--------------------
  *** polcoeff: non existent component in truecoeff.
  ***   Break loop: type 'break' to go back to GP

This is a little surprising as the number of 2-tuples of partitions adding to 17 is 8470, which isn't that big.

[andrew.mathas]

I had a reply from Karim Belabas (UMR 5251) on pari-dev and it is just a matter of increasing the precision:

(08:12) gp > 1/eta(x)^2
%1 = 1 + 2*x + 5*x^2 + 10*x^3 + 20*x^4 + 36*x^5 + 65*x^6 + 110*x^7 + 185*x^8 + 300*x^9 + 481*x^10 + 752*x^11 + 1165*x^12 + 1770*x^13 + 2665*x^14 + 3956*x^15 + 5822*x^16 + O(x^17)

The series precision is too low, so the 17-th coefficient is unknown. Use

  1/eta(x + O(x^101))

if you want to access its 100-th coefficient (for instance).

Cheers,

    K.B.

I'll upload a patch shortly.

[tscrim]

Looks good, just do an automatic trac link :trac:`11476` in the doc.

Thanks.

PS - Its somewhat entertaining to me to compute these huge numbers:

sage: PartitionTuples(162,120).cardinality()
414170543784152902405501503878656556915420510510717572175693806227335527665907778197451415072951

[andrew.mathas]

Thanks for catching this...it seems that the version in the queue did this properly but that I hadn't uploaded it here...fixed now.

Cheers, Andrew

ps. I didn't check any of these big numbers by hand:)

[tscrim]

Thanks! I'll double-check everything once #13072 is fixed up, but basically this is a positive review.

[tscrim]

I believe this needs to be rebased to remove the fuzz:

Hunk #1 succeeded at 1626 with fuzz 1 (offset -1 lines)

but good otherwise so I am setting it to a positive review.

Travis

[andrew.mathas]

Fixing fuzz in applying patch