[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Fwded Post



There must be a downside to integer arithmetic aside from the complicated
code, though, right?  If not, wouldn't Python just use integer arithmetic
behind the scenes from floating point numbers?

Integer arithmetic must not keep as accurate precision, correct?

Disclaimer:  I must admit I didn't understand Guillaume or Pete's
implementation of integer arithmetic, just the concept.

as a side note, on my Celeron 400Mhz:
FLOAT TIME:    4.82999992371
INT TIME:          2.36000001431

-- rob

----- Original Message -----
From: Pete Shinners <shredwheat@mediaone.net>
To: <pygame-users@seul.org>
Sent: Friday, February 08, 2002 12:13 PM
Subject: Re: [pygame] Fwded Post


> Guillaume Proux wrote:
> > Talking about floating point values, my background (game,demo) is the
> > Amiga, the little
> > one that did not come with a MMU nor a FPU. So floating point
> > computations were VERY
> > expensive and we would most of the time do 32 bits fixed point
> > arithmetics for that.
> >
> > Nobody uses this technique apart from me?
>
> integer arithmetic is good like this for small tight loops. in fact many
> of pygame's internal functions like rotate/scale/draw all use integer
> arithmetic for extra speed.
>
> i've always been very curious if integer arithmetic in python was really
> any faster than regular float/int conversions. since i'm in the
> benchmarking mood apparantly, i did a quick test to see what's up..
>
> my initial thought would be they come out pretty close in speed. to my
> surprise, the all-integer version comes out twice as fast. wow.
>
> FLOAT TIME: 2.81134796143
> INT TIME: 1.44705092907
> <<with python-2.1 on a 800mhz celeron2>>
> the test just increments a numeric value by "1/8"th many times. i don't
> think this means everyone should go out and change their games from
> using floating point positions to integer. in a game, the amount of time
> spend moving the objects is so tiny, that cutting it in half probably
> won't even show up on the frames-per-second.
>
> on the other hand, if you really do have a lot of game objects (like a
> particle system especially) keeping track of the positions this way
> could bring some speed to you. it might be worth investigating there.
>
> in any event, i'd recommend _not_ doing the math with integer arithmetic
> like this until you are happy with how everything works with regular
> floating point. the code can be a lot harder to read and work with.
>
>


----------------------------------------------------------------------------
----


> #test speed between int shifting and float-int conversion
>
>
>
> def float_test():
>     inc = .125
>     pos = 0.0
>     for x in range(800000):
>         pos += inc
>         int_pos = int(pos)
>     print "  final pos = ", int_pos
>
> def int_test():
>     inc = 1
>     pos = 0<<3
>     for x in range(800000):
>         pos += inc
>         int_pos = pos>>3
>     print "  final pos = ", int_pos
>
>
> import time
> start = time.time()
> float_test()
> print 'FLOAT TIME:\t', time.time() - start
>
> start = time.time()
> int_test()
> print 'INT TIME:\t', time.time() - start
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org