3

I want to perform some standard operations on numpy float32 arrays in python 3, however I'm seeing some strange behavior when working with numpy sum(). Here's an example session:

Python 3.6.1 |Anaconda 4.4.0 (x86_64)| (default, May 11 2017, 13:04:09) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

import numpy as np
np.__version__
Out[3]: '1.12.1'
a = np.ones(10).astype(np.float32)
np.sum(a).dtype
Out[5]: dtype('float32')
(np.sum(a)+1).dtype
Out[6]: dtype('float64')
(np.sum(a)+1.).dtype
Out[7]: dtype('float64')
(a+1).dtype
Out[8]: dtype('float32')

Any reason why adding a scalar to the result of a sum (which seems to have dtype of float32) would cast it back to float64? To be clear, I know that I can explicitly cast the scalar to float32, however as the last line shows, numpy still respects float32 when adding a scalar to an array. Any explanations or suggestions how to keep things as float32 without explicit casting?

ytsaig
  • 3,267
  • 3
  • 23
  • 27
  • Floating point numbers in Python are 64 bit, so a straight-forward conversion would be to `float64`. It makes sense that adding a `float64` and a `float32` would produce a `float64`. – Mark Ransom Aug 29 '17 at 22:45

1 Answers1

4

The result of np.sum(a) is a NumPy scalar, rather than an array. Operations involving only scalars use different casting rules from operations involving (positive-dimensional) NumPy arrays, described in the docs for numpy.result_type.

When an operation involves only scalars (including 0-dimensional arrays), the result dtype is determined purely by the input dtypes. The same is true for operations involving only (positive-dimensional) arrays.

However, when scalars and (positive-dimensional) arrays are mixed, instead of using the actual dtypes of the scalars, NumPy examines the values of the scalars to see if a "smaller" dtype can hold them, then uses that dtype for the type promotion. (The arrays do not go through this process, even if their values would fit in a smaller dtype.)

Thus,

np.sum(a)+1

is a scalar operation, converting 1 to a NumPy scalar of dtype int_ (either int32 or int64 depending on the size of a C long) and then performing promotion based on dtypes float32 and int32/int64, but

a+1

involves an array, so the dtype of 1 is treated as int8 for the purposes of promotion.

Since a float32 can't hold all values of dtype int32 (or int64), NumPy upgrades to float64 for the first promotion. (float64 can't hold all values of dtype int64, but NumPy won't promote to numpy.longdouble for this.) Since a float32 can hold all values of dtype int8, NumPy sticks with float32 for the second promotion.

If you use a number bigger than 1, so it doesn't fit in an int8:

In [16]: (a+1).dtype
Out[16]: dtype('float32')

In [17]: (a+1000000000).dtype
Out[17]: dtype('float64')

you can see different promotion behavior.

user2357112
  • 260,549
  • 28
  • 431
  • 505
  • I'm a little confused by this explaination. A uint32 can hold up to 4e9, but a float32 can hold up to ~3.4e38. How come a float32 can't handle a uint32? – SapphireSun Aug 19 '18 at 03:12
  • 1
    @SapphireSun: It's got plenty of range, but less precision. A float32 can't hold 2^32-1, for example. – user2357112 Aug 19 '18 at 04:32