Speed of str(positive_integer)..

[Tony Meyer]

> > For small numbers your one beats it because 
> > you don't have to do all the other work that str() does (negatives, 
> > non-integers, etc), but as the
> 
> Yes. But negatives represents not much more work.

Enough that it makes a difference when the task is so small, though.

> I should check, when have some time, how is str() implemented.

I believe the CPython implementation uses sprintf, so that doesn't really
help much.

> > "r = b//c;q = b-r*c" (or "r = b//c;q=b%c", which is better)
>
> (I'm not sure that that is better but i think that it 
> should (at least, in assembler (and for integers)))

By better I meant that it was faster (here, anyway), and clearer (to me,
anyway).

> > (with Python 2.3.4).  I suppose this is the penalty for the 
> > additional work that divmod does with checking signs and so on.
> 
> I'm unsure of how many more things has to do divmod. 

Looking at the implementation in floatobject.c would tell you.  There are
various things it does to make sure that signs come out correctly.

> Anyway, if it's implemented in C it couldn't (i think) use 
> the div from assembler that leaves quotient and remainder on 
> different registers. I mean, it should be specially implemented. :-(

I suppose that the divmod implementation could check to see if both numbers
were integers and then do the faster integer case.  You'd have to convince
TPTB that the speed increase was worth it and that the overhead of doing the
test didn't outweigh the benefits, though.

> Btw, why you didn't answer in the list? 

I did.

=Tony Meyer