combination function in python

Anton Vredegoor anton.vredegoor at gmail.com
Mon Apr 16 19:40:50 EDT 2007


mensanator at aol.com wrote:

> 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?

Yes, a doc string would help finding it in searches, however since this 
thread now contains a collection of function names it will suffice.

There is also the other consideration of being able to easily read code 
that others write. Functions that try to do the same thing having the 
same name would help. If we had some module in the standard distro that 
would contain comb and fac and maybe a few other functions people could 
start using the same name to point to the same thing etc.

>>>> 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

There is more to it than that. If I see the way the function computes 
the values it gives me hints about how I could write a function that 
lists all combinations.

For example the fact that one can divide the product 'on the fly' -I 
mean without computing the totals above and below the division bar- 
tells me something about how to tackle the problem of generating the 
corresponding combinatorial structure. I *love* combinatorial 
structures. Little functions like this have more than once helped me to 
understand them better.

Math is not so much my way of describing things, I like executable 
pseudo code better. Sometimes I had to read math formulas and have 
become somewhat used to that notation -it has its uses too- but if 
things are written down in code I can rely on the *computer* to execute 
the code instead of my brain which unfortunately is not as reliable.

These advantages are lost when one just imports some optimized code library.

> Perhaps you should use the name
> 
> comb_works_just_like_the_gmpy_version_only_slower()

Or maybe 'comb_in_executable_pseudocode', but maybe some other 
implementations posted in this thread would be better suited for that.

Anyway, I have the impression you just don't get the point of people 
posting various functions so that one can determine which algorithms 
work best or so that one can include each others ideas and create better 
functions that combine the best elements of all posted code. Cutting and 
pasting Python functions works a lot better in Usenet than importing C 
libraries.

If no one posts code -even if it's not completely working code- how are 
we to learn from each other? The fact that someone else somewhere 
already saw the light and wrote the perfect function in optimized C or 
Fortran code should not stop us from 'reinventing the wheel' -as you 
call it- because one can get more proficient in wheel making in the 
process and every now and then it even leads to better wheels.

Don't even get me started about this archaic scheme of writing code only 
for 'work' instead of for gaining insight that you seem to promote.

> But when there *is* no documentation, that becomes a problem,
> doesn't it?

This thread is also documentation and I hope it will encourage people to 
post more code and share thoughts.

> 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?

The main virtue of Pythons standard library should be that it shows one 
how to do things and that it introduces a common naming scheme. That was 
what got me interested in python in the first place: Now I got to see 
how things work! No more dark secrets and proprietary code!

Sometimes it's better to sacrifice clarity for speed and write optimized 
lower level code but that doesn't mean there aren't large trade offs 
involved.

In the future if computers will become faster it would be wise to drop 
the optimized code libraries again and reintroduce the Python versions 
of the same because by then the Python versions would be fast enough and 
it would also result in a smaller code base (but a more functional and 
flexible and readable one).

What are you doing on this planet anyway if it's not trying to 
understand things?

>> 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.

Real work is just an excuse for having a larger slice of the cake than 
other people. Other people can be just as or even more essential in the 
whole process of developing code than those who get paid.

A reason against using third party libraries in general is not wanting 
to include too many external dependencies that would force the user to 
download all kinds of things from different places which could change 
their urls or web interfaces. It would also introduce more points where 
version conflicts or license conflicts could occur.

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

It does matter a lot in the long run if people can compare their code to 
the code other people write. If still other people profit from these 
public exchanges and then adopt a condescending attitude towards the 
grass roots processes -either because of misguided adoration for the 
best programmers or because they think themselves to be the best or 
maybe because of some archaic work related value system- that would 
dampen the enthusiasm a bit.

>> 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.

Perhaps even your kind of misguided criticism would be better than such 
a fatalistic attitude.

A.




More information about the Python-list mailing list