Ben: Before you do any substantial work, please check my proposal. I have tried to provide background / explanations, and a set of coherent interfaces. Please look at: http://photon.poly.edu/~hbr/boost/combinations.html The code in the .hpp (linked) is only temporary and not debugged. I am in the process of writing test cases. I'm happy to send it to you too... Keep in mind it is work in progress. I have a job and am spending far too much time on this at the moment :) --HB PS: I am not sure about the Incrementor/Decrementor interfaces, unless I can come up with a convincing example where the underlying type is not int and does not have operator++ and operator--, but it still makes sense to count with it... On Nov 13, 2007, at 1:50 AM, Ben Bear wrote:
2007/11/13, Hervé Brönnimann <hervebronnimann@mac.com>:
Ben: the naming partial_permutation would be a very good idea. I like it. Am I correct that your (very cute!) idea would be extended to prev_ as follows:
bool next_partial_permutation(first, middle, last) { reverse (middle, last); return next_permutation(first, last); }
prev_partial_permutation ( { bool result = next_permutation(first, last);
oh, here should be:-) bool result = prev_permutation(first, last);
reverse (middle, last); return result; }
That's all good, then. BTW, you *should* assume that the client has already sorted the range. In other words, garbage in, garbage out, and that's OK. There's not reason to penalize those who keep their ranges sorted. It simply needs to be documented as a Requirement: and given again as a Post-condition: (since the functions maintain the sorted range invariant).
ok, I will prepare a resume source code that contains partial_permutation and combination, but without initializatons. It will be very simple, against gacap. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost