If there is an implementation that is *always* faster than the alternatives then it makes no sense to keep others around. The pedagogical value of being able to pick a slow algorithm is really limited (especially if the only thing that changes is the time it takes to spit out the same number), and in no relation to the cost of having useless arguments around.
So I'm +1 for number_of_partitions(n,k=None) dispatching to Partitions / PartitionTuples or whatever the fastest implementation is. Preferably as LazyImport, since there should not be a need to compute partitions during startup. Construction of the Partitions() class doesn't really affect runtime: sage: %time _ = [ number_of_partitions(i) for i in range(10000) ] CPU times: user 2.45 s, sys: 0.00 s, total: 2.45 s Wall time: 2.46 s sage: %time _ = [ Partitions(i).cardinality() for i in range(10000) ] CPU times: user 2.57 s, sys: 0.00 s, total: 2.57 s Wall time: 2.59 s On Friday, September 21, 2012 5:09:19 AM UTC+1, Dima Pasechnik wrote: > > > > 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.
