It seems that the binomial coefficient function  nchoosek  is not
vectorized, or at least not vectorized in a way that makes intuitive
sense to me.

For example,

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
x = 1:5;
nchoosek(50,x);

??? Error using ==> nchoosek at 24
The second input has to be a non-negative integer.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I find it strange that one cannot put in a vector argument (non-
negative integers, none greater than the first arguement) into
"nchoosek"  and get a sensible function of the input x out of it.

How about the Matlab team incorporating this feature?

Jim

Feel free to submit a feature request at the appropriate place.

Jim Rockford <jim.rockford1@gmail.com> wrote in message <64f1e691-8b98-4c09-9063-842160cf9d85@t18g2000vbj.googlegroups.com>...
> It seems that the binomial coefficient function  nchoosek  is not
> vectorized, or at least not vectorized in a way that makes intuitive
> sense to me.
> 
> For example,
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> x = 1:5;
> nchoosek(50,x);
> 
> ??? Error using ==> nchoosek at 24
> The second input has to be a non-negative integer.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> I find it strange that one cannot put in a vector argument (non-
> negative integers, none greater than the first arguement) into
> "nchoosek"  and get a sensible function of the input x out of it.
> 
> How about the Matlab team incorporating this feature?
> 
> Jim

I'll conjecture that the reason this has NOT been
implemented is because it would cause a serious
conflict. A huge base of existing code would fail
were this to be done.

The current implementation of nchoosek does this
when passed a vector argument:

nchoosek([2 3 5 7],2)
ans =
     2     3
     2     5
     2     7
     3     5
     3     7
     5     7

That is, it generates the combinations themselves,
all 6 possible combinations of these 4 elements,
taken 2 at a time.

So, yeah, maybe it would be nice. But we all want
our code to continue working with new releases of
MATLAB too, with a minimal effort. I've got MATLAB
code that I wrote as far back as roughly 1988, and
it still runs nicely.

A beauty of MATLAB (or any language, really) is
that you can solve this problem trivially. If you
frequently want a vectorized version of nchoosek,
then write it yourself. Give it a different name of
course, so that this will not break existing code
provided by TMW.

John

On Dec 6, 7:20=A0am, "John D'Errico" <woodch...@rochester.rr.com> wrote:
> A beauty of MATLAB (or any language, really) is
> that you can solve this problem trivially. If you
> frequently want a vectorized version of nchoosek,
> then write it yourself. Give it a different name of
> course, so that this will not break existing code
> provided by TMW.


Sure, writing a special routine wouldn't be hard.  But now that you
mention it, it's gotten me thinking a bit about what makes the
"vectorized" Matlab code comparably fast.  Is it simply the case that
the "vectorized" .m  routines have the usual for-loops and things, but
that code is compiled, and this is what makes it so fast?  Is there
anything else to it, besides routine-specific optimization tweaks
(i.e. the FFT algorithm for Fourier transforms, etc)?

For instance, what makes a Matlab call to   sin(x)     with vector
argument x  so fast?

Thanks,
Jim

Jim Rockford <jim.rockford1@gmail.com> wrote in message <944e1f08-f665-4e83-ad73-4638891f7844@h10g2000vbm.googlegroups.com>...
> On Dec 6, 7:20?am, "John D'Errico" <woodch...@rochester.rr.com> wrote:
> > A beauty of MATLAB (or any language, really) is
> > that you can solve this problem trivially. If you
> > frequently want a vectorized version of nchoosek,
> > then write it yourself. Give it a different name of
> > course, so that this will not break existing code
> > provided by TMW.
> 
> 
> Sure, writing a special routine wouldn't be hard.  But now that you
> mention it, it's gotten me thinking a bit about what makes the
> "vectorized" Matlab code comparably fast.  Is it simply the case that
> the "vectorized" .m  routines have the usual for-loops and things, but
> that code is compiled, and this is what makes it so fast?  Is there
> anything else to it, besides routine-specific optimization tweaks
> (i.e. the FFT algorithm for Fourier transforms, etc)?
> 
> For instance, what makes a Matlab call to   sin(x)     with vector
> argument x  so fast?
> 


Yes, the vectorized calls are invoking compiled built-in routines at some level of the code. Note however that not all routines in the MATLAB library are this way. For example, nchoosek() is a .m file  like any either.

>>type nchoosek.m

It only benefits from vectorization to the extent that the commands inside nchoosek.m invoke other optimized/compiled functions.