Charles R Harris wrote: > > > On 3/14/07, *Daniel Mahler* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > On 3/12/07, Travis Oliphant <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
