combination function in python

[mensanator at aol.com]

On Apr 15, 4:16?pm, Anton Vredegoor <anton.vredeg... at gmail.com> wrote:
> mensana... at aol.com wrote:
> >> We're getting closer and closer to something I already posted a few
> >> times here. This implementation was unfortunate because I consistently
> >> used an uncommon name for it so people couldn't easily find it
>
> > But then, who's looking for it?
>
> The OP was trying to find it in the docs, assuming it was some kind of
> builtin function. I can see the logic of that and I can also see the
> logic of including some other smallish functions like for example fac.
> Failing that, the next recourse would be the Internet, or a Usenet
> search but that would imply well named Usenet posts and function names.

Isn't that what docstrings are for? Can't you leave
the function name noverk() and add something to the
effect of "this function calculates combinations"?
Then it would show up in searches, wouldn't it?

>
> >> (mea culpa), and maybe also because it uses the despised reduce builtin.
>
> >> def noverk(n,k):
> >> ? ? ?return reduce(lambda a,b: a*(n-b)/(b+1),xrange(k),1)
>
> This is a rather concise function which has the added advantage that it
> returns 0 when k>n.

import gmpy
print gmpy.comb(4,8)

## 0

>
> >> BTW I hereby give up the strange name for this and request a better name
> >> that everybody will use so there will be no confusion anymore. Maybe
> >> comb(n,k) ?
>
> > No, that name's already used by gmpy. And a single
> > function doesn't replace all of gmpy's other
> > functionality, many of which are needed in the
> > same applications where comb() is used, so there's
> > really no need for your function.
>
> Actually, by proposing comb I am *honoring* gmpy and
> I'm also complying with it.

Perhaps you should use the name

comb_works_just_like_the_gmpy_version_only_slower()

> In Python we use namespaces to differentiate between such
> things.

Provided they get used.

> You might want to read the documentation about it some time.

But *I* always use namespaces, as *I've* read the documentation.
But when there *is* no documentation, that becomes a problem,
doesn't it?

>
> > Your time is better spent applying the tools provided
> > by gmpy rather than trying to re-invent the wheel.
>
> Please let me be the judge of how to spend my time.

Suit yourself.

> In this case it seems rather unjustified to introduce
> dependencies on external modules when only a few functions
> are needed.

Unless you don't know how to write the functions you need
in which case you're better off relying on external
modules. Have you ever wondered why Python even *has*
a standard library? Why doesn't everyone just write
the functionality they need?

> Since I'm also interested in the
> functions themselves -in this case- I'd rather have a
> few lines of code in my source than importing an
> optimized code library.

Well, some people prefer optimized libraries because
they have real work to do, not just acedemic excercizes.

> There *are*
> situations where such things are completely justified,
> but I don't think this is one of them.

So it doesn't matter whether anyone can find noverk(),
does it?

> You could take it up with the gmpy author and
> induce him to get gmpy included in the standard distro if you are so
> inclined.

Alex Martelli knows more about that subject than I and
it would be pointless for me to bug him about it.

>
> A.