Pyrex praise (repeat)

Bengt Richter bokr at
Wed Aug 7 09:19:23 CEST 2002

On Tue, 06 Aug 2002 13:07:11 -0700, Terry Hancock <hancock at> wrote:

>"Mike Rovner" <mike at>
>> "François Pinard" <pinard at> wrote in message
>> news:oq7kj4yx81.fsf at
>> ...
>> > A final point, which looks important to me, is that any good wrapping of a
>> > pre-existing C library is best done while giving a Python flavour to the
>> > interface, would it be only for a nicer and natural object orientation.
>> ...
>> That is completely true.
>> Pyrex is my language of choice for wrapping pretty complex set of C
>> interfaces written in a totally not-OO style in a nifty OO Python interface.
>> I choose Pyrex for that very reasons Francois described. It gave me total
>> control and uniformity of my program.
>> The only small addition I made is handling array of structures and I believe
>> that soon can be handled inside Pyrex itself. Greg is doing very good job.
>I'm wondering if Pyrex is for me --
>For a game AI project I was working on awhile back I was
>trying to implement a theoretical model of character agent
>emotions. Anyway, it involved "fusing" a set of emotions
>(i.e. a Python list containing emotion objects, which are
how long a list?? How often do the values in the list change?
how often do you have to go through the list?
>4-vectors in the model, presumeably tuples of floats, or
>perhaps tuples of a saturating "vague number" type, like a
>fuzzy logic value).  "Fusing" is basically "summing",
>except the procedure is non-linear (they don't follow
>simple vector addition, and the elements are not treated
>symmetrically -- I think this rules out Numeric, though
>I haven't proven that to myself yet).
is the fusing function continuous? Do you fuse a four-tuple
with another four-tuple and return a single value? Or do
you fuse a whole vector of 4-tuples into a single value, or
a new 4-tuple, or what? How many possible output states
are there? How many shades of emotion do you really need
to compute for your game? Four floating doubles is a lot
of state space ;-)

>I tried a pure-python implementation, but there didn't
>seem to be any way to do it without just looping through all
>the list members, and this took an awful long time to run.
all the how many list members?
>(Too long for the game).
Please give us a clue as to the scale of your problem.
I am really wondering what the model is. How many entries of
4-tuples do you have to loop through? Is it one per game denizen
or all possible objects in the game? What is the algorithm trying to do?
Check how x feels towards y by crunching on x's 4-tuple and y's 4-tuple
and doing that for all y's that x can sense? And then moving on
to the next x and doing it all over again? And expecting to do this
at movie frame rates for thousands of objects? ;-)

It's easy to hack together something that sort of looks at everything
with respect to everything, and works fine for n<10 but quickly becomes
unusable. That's an algorithm problem, and all you can do with C or C++
is move the threshold of uselessness up. Best to look at what you can
do with the algoritm first, unless you have a full thing already working to spec
but a little slow, and just want a way to brute force your way to usabilty.

>So I started working on a C implementation, but it's a real
>pain.  It's conceptually very object-oriented, with tiny
>snippets of math code required, but the overhead of using
>something like C++ seems prohibitive (why write all of that
>in C++ when I'm only going to use it in Python?).  Also,
>I've written maybe 200 lines of C++ in my life, and so
>many people bad-mouth it, I'm wondering if I should bother
>with it.
It can be good.
>Also, I need to do a fast loop through the Python list, I
>think, so I need it to integrate well with Python, and I
>don't really want to recode any basic Python types!
>So I tried to get a handle on the Python/C API, but I don't
>quite see it yet -- I've read some of the documentation,
>but it hasn't really become clear to me how to get started,
>and I have the feeling the result is going to be kind of
>clunky (from the development point of view -- lots of lines
>of code).
I don't get the feeling the design is solid yet. Python is
great for quick prototyping of ideas. AND communicating them.
You can write "little snippets of math code" in python and
provide real examples probably faster than you can write
prose about it.

>Should I chuck it, and learn Pyrex instead?  I've seen
>a few snippets of pyrex, and it looks kind of promising. My
>impression is that it might be good for this project --
>embedding small amounts of C code into a Python object
>model.  Or should I just plow through my resistance on
>the Python/C API? (Maybe the wall's not as thick as it
>looks?).  What does either of them do to your build/distribution
>complexity?  (I.e. can I use distutils with either --
>I've never used it, but I plan to someday :-) ).
>I kind of dropped the project, but if I saw an easier way
>to proceed, I might want to pick it up again.
Show us an example of critical code that was too slow,
and maybe people will have some ideas that will help.

>Obviously this is all subjective -- just looking for
>some opinions.
Can't read your mind ;-)

Bengt Richter

More information about the Python-list mailing list