Author rhettinger
Recipients LambertDW, TFinley, mark.dickinson, rhettinger
Date 2009-01-08.02:20:15
SpamBayes Score 0.00643099
Marked as misclassified No
Message-id <1231381217.89.0.520922930359.issue4816@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks David. Looks like we're all in agreement.
Turns out, I did a weeks worth of mulling today ;-)
Accepting the proposal with the following rationale:

1. There exist some valid use cases where r>n.
2. Returning an empty list is the expected outcome with two of the
current pure python versions (the ones that filter results from
product() based on their length, uniqueness and sort).
3. It is consist with the notion of 'all subsets of length r ...'
4. It corresponds to the piecewise definitions of the choose function
and binomial coefficient.
5. It matches the battle-tested APIs of all of the major mathematics
tools we looked at (Mathematica, Magma, GAP, and Sage.
6. The recipe for combinations_with_replacement() is well defined and
useful in cases where r>n -- it is desirable that all the variants of
this function keep their APIs in-sync.
7. The three other posters here all agree on it :-)

Weighing against it:
1. The ValueError version has already been released.
2. There may be use cases where r>n represents an error so that raising
a ValueError would be helpful.
3. The length of the comb/perm doesn't correspond to the non-piecewise,
factorial based functions that are so ubiquitous (MS Excel, HP32SII, CRC
handbook, Handbook of Mathematics, wikipedia's entries for Combination
and Permutation, and GAP's nrCombinations() function).
History
Date User Action Args
2009-01-08 02:20:18rhettingersetrecipients: + rhettinger, mark.dickinson, LambertDW, TFinley
2009-01-08 02:20:17rhettingersetmessageid: <1231381217.89.0.520922930359.issue4816@psf.upfronthosting.co.za>
2009-01-08 02:20:17rhettingerlinkissue4816 messages
2009-01-08 02:20:15rhettingercreate