Live data from Hacker News

The Evolution of a Python Programmer

gist.github.com

11–20 of 45 posts

Re: The Evolution of a Python Programmer

#11
post #7

Apparently, #EXPERT PROGRAMMER wins for efficiency ;)

Not surprising - many Python built-ins are implemented in C. And for any numerical or computational libraries, doing it in C is all but essential.

Tangential, but this is why NumPy totally changed my workflow. I can use all of the benefits of Python, including its libraries and syntax, and still have a program that executes at the speed of C, rather than Python[1].

[1] Not literally the speed of C, but you get the idea.

Re: The Evolution of a Python Programmer

#12
post #10

If you can live with floating point results: from math import gamma def factorial(x): return gamma(x+1) This has the advantage of working correctly for non-integer arguments.

True, but it requires 3.2+ and does not work correctly for large integers (floating-point runs out of precision long before Python's arbitrary-size integers become unusably large.)

(Of course, this is a silly problem.)

Re: The Evolution of a Python Programmer

#13
post #10

If you can live with floating point results: from math import gamma def factorial(x): return gamma(x+1) This has the advantage of working correctly for non-integer arguments.

The factorial itself is only defined for non-negative integers. This may seem pedantic, but what you've defined there is actually Gauss's pi function, which has many interesting mathematical properties, but is not equivalent to the factorial because it has a larger domain. The results that it gives for non-integer arguments aren't any more "correct" than a factorial function throwing an exception, because they're both behaving appropriately for their defined domain.

Edit: The math module has a factorial() function anyways, so it's a bit of a moot point. Use that :)

Edit Edit: Thanks for the catch, I did mean non-negative integers instead of positive.

Re: The Evolution of a Python Programmer

#14
post #13
post #10

If you can live with floating point results: from math import gamma def factorial(x): return gamma(x+1) This has the advantage of working correctly for non-integer arguments.

The factorial itself is only defined for non-negative integers. This may seem pedantic, but what you've defined there is actually Gauss's pi function, which has many interesting mathematical properties, but is not equivalent to the factorial because it has a larger domain. The results that it gives for non-integer arguments aren't any more "correct" than a factorial function throwing an exception, because they're bot…

As far as I know, 0! = 1, so I assume you meant non-negative integers instead of positive integers?

Re: The Evolution of a Python Programmer

#15
Half of those are incorrect implementations that junk the stack and most of the rest are idiotic rebaked jokes from the late 90s. Nowhere near to http://www.willamette.edu/~fruehr/haskell/evolution.html which is not only enlightening but actually funny when it tries to; or even to http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.... which was funny when it started and still is the original. Can we stop making HN into the next xkcd?

Re: The Evolution of a Python Programmer

#16

Half of those are incorrect implementations that junk the stack and most of the rest are idiotic rebaked jokes from the late 90s. Nowhere near to http://www.willamette.edu/~fruehr/haskell/evolution.html which is not only enlightening but actually funny when it tries to; or even to http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.... which was funny when it started and still is the original. Can we stop mak…

I actually thought this was the best thing I read today. So please don't stop posting these.

Re: The Evolution of a Python Programmer

#18
post #10

If you can live with floating point results: from math import gamma def factorial(x): return gamma(x+1) This has the advantage of working correctly for non-integer arguments.

True, but it requires 3.2+ and does not work correctly for large integers (floating-point runs out of precision long before Python's arbitrary-size integers become unusably large.) (Of course, this is a silly problem.)

The documentation says it requires 3.2+, but it is working in 2.7 on my Mac, both the 2.7 shipped by Apple and the 2.7 installed by MacPorts.
Post reply on HN