Andy

I have a student edition of ML R2010a on Windows 7. It comes with the default prompt 'EDU>>', which I wanted to change back to the familiar '>>'. setPrompt worked, but it leaves too much space (copied and pasted):

EDU>> setPrompt('>>');
>> see how much space there is?

I would have preferred:

EDU>> setPrompt('>>');
>> only one space before text

Still, great stuff. Thanks, Yair!

I will respond to your points in order:

1. You're not duplicating the functionality of nchoosek, you are extending it (if only by a few lines). But you are duplicating a small part of the functionality of partitions.

2. John found your documentation confusing, which it was.

3. It's not an issue of being upset. I don't have any particular need for your code, so I really don't care if you use nchoosek. But you stated that speed was a goal, and I suggested two ways to improve the speed: rewrite nchoosek, and use MEX files. You don't seem to like either of these ideas, for whatever reasons that you have not shared.

4. nsumk is not a waste of space, nor did I ever say it was. I said I see no justification for using it instead of partitions unless the speed is further optimized.

5. I don't know when 6x changed to 10x. On my machine, nsumk was 4-6x faster than partitions. For example:

n=13;
k=6;
tic;
[m,x]=nsumk(n,k);
t1=toc
tic;
y = partitions(k, ones(1,n));
t2=toc
isequal(sortrows(x),sortrows(y))
t2/t1

% displays:
t1 =
    0.6823
t2 =
    3.3452
ans =
    4.9028

In any case, since you seem intent to ignore suggestions for improvement, it's not worth my time to continue commenting on this code.

"A skeptic might suggest that your confusion (and complaints about 0 appearing in the solution, or numbers greater than n for that matter) arose not from lack of clarity on my part but from your assumption that this function should follow the same syntax as your own (though as it turns out, you were not even using your own function appropriately - thanks to Andy for noticing)."

Well, that's a somewhat misleading summary of the argument. John at no point said that the same syntax used with his partitions function should give the same result. Rather, he was referring to the syntax used for nchoosek, which your original help section said that nsumk was somewhat related to. (The nature of that relationship was precisely what you were asked to make more explicit.) The complaints about 0 (or 4, or 5) appearing in the output were unrelated to partitions. These complaints were because your original help file didn't say in full detail how it treated vector inputs. (More specifically, it didn't say explicitly that only the length of the vector input mattered.)

Also, I'd like to reiterate a point I made earlier. It seems that the only argument for nsumk over partitions is speed. If this is the case, have you explored a MEX option to see if it would be made even faster? I would think a performance increase would help in two scenarios:
1) the speed increase is significant enough to allow for higher inputs to return in reasonable time, or
2) the function is going to be run over and over again, and the savings of a few seconds per call will translate to minutes overall.

First, a speed increase of five times really is irrelevant when the size of your output grows super-exponentially in the size of your input. It would take a much greater speed increase to move to n=16 or higher. (I should mention that although your included speed tests indicate that nsumk can handle n=15 and partitions can't, in fact neither function returns with n=15 and k=11 on my machine, so I can't confirm the speed difference.)

Second, I can't think of any reason you would need to run nsumk repeatedly with the same arguments, since the output will never change.

On the other hand, if you could increase the speed by a factor of 100 or 1000, you might be able to use n=16, and that would be a real argument for nsumk.