David C. Ullrich
ullrich at math.okstate.edu
Thu Jul 12 16:19:41 CEST 2001
On Wed, 11 Jul 2001 20:17:27 GMT, bokr at accessone.com (Bengt Richter)
>On Wed, 11 Jul 2001 14:48:13 GMT, ullrich at math.okstate.edu (David C. Ullrich) wrote:
>>>On my system I get
>>>[18:47] C:\pywk\fib>strL.py str 10L**20899
>>>str took 13.601617 seconds
>>>[18:47] C:\pywk\fib>strL.py strL 10L**20899
>>>strL took 1.044989 seconds
>>>Recursion rides again ;-)
>>Recursive or not, the idea that we can write
>>a replacement for str that's faster is very
>Well, it's a seldom-used aspect of str to print
>monster longs. They surely had more urgent things to do ;-)
Certainly - I wasn't meaning to say that they were
bad or I wanted my money back or anything. It _is_
>>>BTW, how do you put everything inside the strL def
>>>to hide names, and how do you recurse inside without
>>>a warning message?
>I'm leaving this question in ;-)
Ok, I'll leave it in too then; maybe someone who
knows what they're talking about will have a hint.
>>Of course you have to do the recursion in a non-stupid
>>manner, as here; if you'd made a recurzive routine
>>that concatenated Python strings instead of building
>>that list I doubt that recursion would win. But it is
>>curious how often recursion does seem to win in Python.
>>(Doesn't usually beat built-in functions, though.)
>I hope people realize what you are pointing out,
>i.e., that it's not recursion per se that made the gains.
>The algorithm is the thing.
>Recursion is a powerful way of expressing algorithms,
>and the more expressive power you have, the better your
>chances of coming up with a good algorithm.
>Clean expressive power is Python's main attraction IMO.
Huh. A better explanation than I actually expected.
David C. Ullrich
More information about the Python-list