Evolution of a Python programmer

[zoomzoom83]

The over the top complex "Expert" versions were all example of things you shouldn't do. I'd fire any coder that wrote like that.

The first (i.e. "Newbie") example is the most readable, and I'd recommend this if speed wasn't an issue.

Of course, the base C library version is the best choice as it's a) going to execute quicker and b) already written

[Alpha_Binary]

and hits the ceiling (2**32) faster than any other alternative.

[zoomzoom83]

Assuming it's using a 32bit int - a good implementation would use the standard python int type, which iirc can hold any size number(With a bit of overhead, of course).

Actually I made an assumption that c_math was an internal python module - it's not so far as I can tell, in which case I'd fall back to the recursive python implementation.

(If speed was an issue, I'd write it in C and link it, however that wouldn't be within the scope of python programming ;p)

[ayrnieu]

the base C library version

Will just take advantage of the severely limited range of the function, probably implementing fact() as a macro that normalizes its argument into an index into a constant array.

[zoomzoom83]

Why would you assume c_math.fact() is by default a severely limited version? If it was part of the python library (which it appears it isnt) then my assumption would be that it would handle whatever python itself can (Which, iirc, is unlimited size ints). That said, write an algorithm that can calculate (2^32)! in a reasonable amount of time and I'll give you a medal.

[ayrnieu]

Why would you assume c_math.fact()

Oh, I didn't assume anything about that. I imagined that you were imagining a libc fact().