[NumPy-Tickets] [NumPy] #2109: mean() with axis=None causes promotion of floating point types

NumPy Trac numpy-tickets@scipy....
Tue Apr 17 14:18:51 CDT 2012


#2109: mean() with axis=None causes promotion of floating point types
--------------------------------+-------------------------------------------
 Reporter:  david.warde-farley  |       Owner:  somebody   
     Type:  defect              |      Status:  new        
 Priority:  normal              |   Milestone:  Unscheduled
Component:  numpy.core          |     Version:  1.6.1      
 Keywords:                      |  
--------------------------------+-------------------------------------------
 It seems that `mean()` with no `axis` argument and no `dtype` incorrectly
 promotes to float64 when taking the mean of an array of dtype float32.
 Here's a test that demonstrates:

 {{{
 def test_mean_promotion_regression_bug():
     x = np.zeros((5, 2, 2), dtype='float32')
     np.testing.assert_(x.mean(axis=0).dtype == x.dtype)
     np.testing.assert_(x.mean(axis=1).dtype == x.dtype)
     np.testing.assert_(x.mean(axis=2).dtype == x.dtype)
     # This assertion currently fails.
     np.testing.assert_(x.mean().dtype == x.dtype)
 }}}

 Also, even specifying `dtype='float32'` in this circumstance fails:

 {{{
 def test_mean_promotion_regression_bug_dtype_specified():
     x = np.zeros((5, 2, 2), dtype='float32')
     np.testing.assert_(x.mean(axis=0, dtype='float32').dtype == x.dtype)
     np.testing.assert_(x.mean(axis=1, dtype='float32').dtype == x.dtype)
     np.testing.assert_(x.mean(axis=2, dtype='float32').dtype == x.dtype)
     # This assertion currently fails.
     np.testing.assert_(x.mean(dtype='float32').dtype == x.dtype)
 }}}


 In addition to not sharing this behaviour with `sum()`, docstring reads:

 {{{
 dtype : data-type, optional
     Type to use in computing the mean.  For integer inputs, the default
     is `float64`; for floating point inputs, it is the same as the
     input dtype.
 }}}

 So I believe this is indeed a bug. I don't know !NumPy's reduction
 machinery well enough and don't have time to go digging right now, but am
 filing it here so it doesn't get lost.

 This behaviour seems to go back as far as 1.3.x, at least, so it doesn't
 seem to be the result of any of the recent NA work.

-- 
Ticket URL: <http://projects.scipy.org/numpy/ticket/2109>
NumPy <http://projects.scipy.org/numpy>
My example project


More information about the NumPy-Tickets mailing list