[Numpy-discussion] in place random generation

Travis Oliphant oliphant@ee.byu....
Wed Mar 14 23:57:46 CDT 2007


Charles R Harris wrote:
>
>
> On 3/14/07, *Daniel Mahler* <dmahler@gmail.com 
> <mailto:dmahler@gmail.com>> wrote:
>
>     On 3/12/07, Travis Oliphant <oliphant@ee.byu.edu
>     <mailto:oliphant@ee.byu.edu>> wrote:
>
>     > I'm not convinced that the broadcasting is causing the slow-downs.
>     > Currently, the code has two path-ways.  One gets called when the
>     inputs
>     > are scalars which is equivalent to the old code and the second gets
>     > called when broadcasting is desired.  Their should be only a
>     very small
>     > speed hit because of the check.   So, it should be possible to
>     do both
>     > without great differences in speed.
>     >
>     > Perhaps the speed hit is due to something else (like creating
>     0-d arrays
>     > from scalars, or something similar).    So, in other words, I
>     think the
>     > problem is fixable, but we need someone who can track down where
>     the
>     > slowness is coming from.
>     >
>     > -Travis
>
>     The problem is very easy to reproduce.
>     What would it take to do the tracking?
>     I'd like to see this fixed.
>     Presumably the python profiler is no use since the problem is
>     inside C code,
>     which is not my expertise.
>
>
> Well, it is not creation of scalars per se that is slow.

I think the problem is in two places (with 2 being the largest slow-down).

1) Conversion of scalars to 0-d arrays
2) Using ufuncs to check for illegal parameters.  What used to be a 
simple Python object comparison is now a ufunc.  While this works for 
arrays of parameters it is *a lot* slower for scalars.

The solution as I see it is to branch earlier down the scalar / array 
paths so that scalars are never converted to 0-d arrays at all.

-Travis



More information about the Numpy-discussion mailing list