On further consideration, this change doesn't make much sense to me. The
speedup is from dropping the a = a + 0.0 -- how does changing the dtype of
weights replace this?

OTOH assuming that weights is real is probably OK -- I thought we were
forcing 'a' to be real.

BTW, copy=0 is the default for asarray.
On 30 Jan 2015 10:50, "Minh-Long Do" notifications@github.com wrote:

---

You can view, comment on, or merge this pull request online at:

#5525
Commit Summary

• Add @Profile tag to profile code line.
• Remove unnecesary step of turning numpy array int type to float.
  Increased performance. See Performance of numpy average and numpy.mean function #5507.
• Remove @Profile

File Changes

• M numpy/lib/function_base.py
  https://github.com/numpy/numpy/pull/5525/files#diff-0 (3)

Patch Links:

• https://github.com/numpy/numpy/pull/5525.patch
• https://github.com/numpy/numpy/pull/5525.diff

—
Reply to this email directly or view it on GitHub
#5525.

I think the best solution would look something like:

wts = np.asarray(wts)
dt = np.result_type(a.dtype, wts.dtype, float)

and later on always make calls to the ufuncs with dtype=dt specified:

scl = wgt.sum(axis=axis, dtype=dt)
avg = np.multiply(a, wgt, dtype=dt).sum(axis) / scl

There is also a very weird construct a little bit further down:

if returned:
    scl = np.multiply(avg, 0) + scl

which we could probably do away with if we implemented the above, as the only conceivable reason I can see to do that would be to have scl be of np.result_type(avg.dtype, scl.dtype).

Doesn't np.result_type(a.dtype, wts.dtype, float) upcast float32 to
float64?

On Fri, Jan 30, 2015 at 2:55 PM, Jaime notifications@github.com wrote:

I think the best solution would look something like:

wts = np.asarray(wts)
dt = np.result_type(a.dtype, wts.dtype, float)

and later on always make calls to the ufuncs with dtype=dt specified:

scl = wgt.sum(axis=axis, dtype=dt)
avg = np.multiply(a, wgt, dtype=dt).sum(axis) / scl

There is also a very weird construct a little bit further down:

if returned:
scl = np.multiply(avg, 0) + scl

which we could probably do away with if we implemented the above, as the
only conceivable reason I can see to do that would be to have scl be of np.result_type(avg.dtype,
scl.dtype).

—
Reply to this email directly or view it on GitHub
#5525 (comment).

Yes, you would need to use np.result_type(a, wts, 0.) (or use a.dtype if you want it to never behave like a scalar for a, etc.)

In the current code base by doing a = a + 0.0 is to force a to be real. So I was wondering if np.average(a, weights=None, returned=False) also accepts an array of complex numbers. Because, if it accepts np.complex128 then the operation a = a + 0.0 would not be necessary since the imaginary and real parts of the complex number are already np.float64 . So I did the following in the if statement if not isinstance(a, np.matrix) to reduce unnecessary operations that forces a to be real.

if a.dtype is np.dtype('complex128'): 
    if weights is None:
        # Just convert into an np.array
        a = np.asarray(a)
    else:
        if a.dtype is not np.dtype('complex128'):
            # Convert to np.array and set np.dtype to float64
            a = np.asarray(a, dtype=np.dtype('float64'))
else:
    # If a is a np.matrix and there are weight values
    if weights is not None:
        # if dtype of a is not np.dtype('complex128') then make it to be np.float64
        if a.dtype is not np.dtype('complex128'):
            # No need to attempt conversion for np.float64 if it is already np.float64
            if a.dtype is not np.dtype('float64'):
                # Worse case scenario, np.matrix is not np.float64 then the following will force a to be np.float64
                a = a + 0.0

The performance of this change by using the script https://gist.github.com/skuschel/2d148a37a2ce17925fb0 provided by skuschel is the following:

execution time np.average: 3.06e-01 sec
exectution time np.mean: 3.00e-01 sec

What do you guys think?

Sorry I accidentally closed it.

In the current code base by doing a = a + 0.0 is to force a to be real

Real or complex while preserving inexact type. It is an tricky way to achieve that end. Maybe we should just check for inexact? This PR looks a bit too complicated to me as it stands.

@minhlongdo At some point the commits will need to be squashed into one and the commit message cleaned up. See doc/source/dev/gitwash/development_workflow.rst for discussion of commit messages.

@charris Will do, thanks for the feedback.

@charris I looked into inexact and it does indeed simply the proposed solution.
I somehow managed to mess up, so I made a new pull request #5551. I am sorry for the mess.