no sign() function ?

Pierre-Alain Dorange pdorange at
Mon Dec 22 17:51:52 CET 2008

Istvan Albert <istvan.albert at> wrote:

> try testing on a large number of candidates that are all (or mostly)
> positive or all (or mostly) negative and you'll see performance
> numbers that are substantially different than the ones you report:
> candidates = range(1000)
> In general the function sign_1() is expected to be the fastest because
> in most cases will detect the sign with the fewest operations, it only
> visits the rest of the comparison when it hits the corner cases. Only
> if you have lots of +/-0.0 cases will it be slower than the rest, due
> to having to call an expensive operation.

You're right.
On a range or a random list sign_1 is the fastest :

with :
        for i in range(1000):

In my first candidate list, the two ZERO (-0.0 and +0.0) make sign_1
less productive because it call atan2().
With random number sign_1 is faster, just a bit faster, except if the
candidates contain some ZERO.

I also make other test, with a range(1000), sign_1 became really faster
: -41% (near twice faster than sign_0). 
I then rewrote a sign_0 version testing first positive, then negative
and ZERO as the last test. I also made tests and return integer.
It make it faster +20% but not as fast as sign_1 for a range.

What is strange is that when testing with "range" list (0 1000) or (-500
+500), sign_1 is twice as fast as with a random generated list.
The only thing a saw is that range generate an int list and random a
float list...
So it seems sign_1 is really fastest with integer, but not with float

Range from -500 to +500
sign_0 : 0.38"
sign_1 : 0.27" (-40%)

Range from 0 to 1000
sign_0 : 0.32"
sign_1 : 0.25" (-22%)

Range from -1000 to 0
sign_0 : 0.46"
sign_1 : 0.30" (-35%)

1000 Random from -500 to +500
sign_0 : 0.37"
sign_1 : 0.42" (+13%)

Pierre-Alain Dorange        <>

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

More information about the Python-list mailing list