On Friday, 21 September 2012 10:25:45 UTC+8, Andrew Mathas wrote: > > Among other things, the patch > #13072<http://trac.sagemath.org/sage_trac/ticket/13072>cleans up > sage.combinat.partition. I would like some input as to should > happen to the function number_of_partitions. > > Arguably, if you want to compute the number of partitions of some integer > in sage then you should use the Partitions class: > sage: Partitions(2000).cardinality() > 4720819175619413888601432406799959512200344166 > It has been suggested, however, that in some applications that the extra > overhead required to create the Partitions class would be significant and, > consequently, that it is better to keep a stand alone number_of_partitions > function for *fast* computations of the partition function. > > Currently, in the global namespace number_of_partitions points to > sage.combinat.partition.number_of_partitions > This function does some mild argument parsing, most of which is historical > in that it allows you to choose between different algorithms -- which you > almost certainly do not want to do because the non-default algorithms are > (significantly) slower than the default algorithm. There is also an option > to allow you to compute the number of k-tuples of partitions which sum to > n, for which one can/should use PartitionTuples(n).cardinality() -- > although, see #11476. <http://trac.sagemath.org/sage_trac/ticket/11476> > If there is a need to have a *fast* number_of_partitions implementation of > the partition function then I think that we should deprecate all of the > argument parsing and have the function in the global point directly to the > default implementation, which is currently Bober's algorithm > insage.combinat.partition > s.number_of_partitions. Currently, the function number_of_partitions is > effectively a wrapper to this function with some extra argument parsing on > top to slow it down. >
This decreases the pedagogical value of Sage code for no good reason. I'd rather consider making these various implementations directly visible to the user. Then doing, say, sage.combinat.partition.number_of_partitions_Bober will call Bober's algorithm, sage.combinat.partition.number_of_partitions_FLINT will call the algorithm in FLINT (when it will be available), etc. The user who needs a speedup will then do the choice, if necessary. Needless to say, the default implementation should better point to a fast implementation. So this looks like option 5. :–) Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
