no sign() function ?
pdorange at pas-de-pub-merci.mac.com
Mon Dec 22 17:51:52 CET 2008
Istvan Albert <istvan.albert at gmail.com> 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.
On a range or a random list sign_1 is the fastest :
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
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 <http://microwar.sourceforge.net/>
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
More information about the Python-list