> Did you make a quick benchmark on Partitions().random_element(), with > and without caching? Given that number_of_partitions (which was > already fast) was even further optimized recently, maybe caching is > not relevant anymore? > > From the remark in partition.py, I think that whoever cached number_of_partitions initially must have done this. I just checked now and the speed when the function is cached is quite dramatic:
The following timings show that there is a dramatic speed-up when number_of_partitions is cached: *With caching* sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 25 ms per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 24.6 ms per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 25 loops, best of 3: 25.4 ms per loop *Without caching* sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.23 s per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.23 s per loop sage: %timeit [Partitions(n).random_element() for n in range(100)] 5 loops, best of 3: 1.26 s per loop I have added all of this to the trac ticket. Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/HQYl08bMYYYJ. 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.
