Robin Becker wrote: > it's probably wonderful, but I don't think I can ask people to add numpy to > the > list of requirements for reportlab :)
Maybe NumPy makes it into the core Python tree one day. At some point other Python users than die-hard scientists and mathematicans will realise that for and while loops are the root of all evil when doing CPU bound operations in an interpreted language. Array slicing and vectorised statements can be faster by astronomical proportions. Here is one example: http://tinyurl.com/y79zhc This statement that required twenty seconds to execute dim = size(infocbcr); image = zeros(dim(1), dim(2)); for i = 1:dim(1) for j = 1:dim(2) cb = double(infocbcr(i,j,2)); cr = double(infocbcr(i,j,3)); x = [(cb-media_b); (cr-media_r)]; %this gives a mult of 1*2 * 2*2 * 2*1 image(i,j) = exp(-0.5* x'*inv(brcov)* x); end end could be replaced with an equivalent condensed statement that only required a fraction of a second: image = reshape(exp(-0.5*sum(((chol(brcov)')\ ... ((reshape(double(infocbcr(:,:,2:3)),dim(1)*dim(2),2)')... -repmat([media_b;media_r],1,dim(1)*dim(2)))).^2)'),dim(1),dim(2)); This was Matlab, but the same holds for Python and NumPy. The overhead in the first code sniplet comes from calling the interpreter inside a tight loop. That is why loops are the root of evilness when doung CPU bound tasks in an interpreted language. I would think that 9 out of 10 tasks most Python users think require a C extension is actually more easily solved with NumPy. This is old knowledge from the Matlab community: even if you think you need a "MEX file" (that is, a C extension for Matlab), you probably don't. Vectorize and it will be fast enough. -- http://mail.python.org/mailman/listinfo/python-list