Raul got it right with his nparts verb. In my original example of par, I
constructed the required output of par by hand. In that process, I
overlooked the majority of the possible combinations of the ways that 5
items could be separated into 3 containers. That caused confusion in the
various attempts to implement what I proposed. I wasn't very thorough in
vetting my example output, and Mike valiantly tried to point out the flaws
in my proposal. Raul showed how much I missed clearly in my par example
when he demonstrated:
#3 nparts 5
25
#3 par 5
6
Rob also pointed out the issue in his posts. Erling's v7 verb got to the
same result as Raul's nparts.
The number of possible partitions of n objects grows rapidly with n:
#3 nparts 5
25
#3 nparts 6
90
#3 nparts 7
301
#3 nparts 8
966
Increasing the number of partitions reduces the number of combinations but
significantly increases execution time with Raul's nparts :
#4 nparts 8
1701
#5 nparts 8
1050
#6 nparts 8
266
The 5 #nparts 8 took over 30 seconds to run on my i7 laptop. The #6 nparts
8 took about 3 minutes.
Is there a more computationally efficient way to calculate the partitions?
Skip
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
