Inconsistent casting behavior in array-scalar vs array-array multiplication

[idfah]

Say we have an array of single precision floats.

>>> a = np.array((1,2,3), dtype=np.float32)
>>> a.dtype
dtype('float32')

If we multiply this array with a 64 bit int scalar, the result still consists of single precision floats.

>>> (a*1L).dtype
dtype('float32')

This is also true of we multiply with a 0-d numpy array containing a 64 bit int.

>>> (a*np.array(1L)).dtype
dtype('float32')

However, if we multiply with an 1-d (or n-d) array of 64 bit ints, we now get double precision floats.

>>> (a*np.array((1L,))).dtype
dtype('float64')
>>> (a*np.ones((1,))).dtype
dtype('float64')
>>> (a*np.ones(a.shape)).dtype
dtype('float64')

I can see the argument for either behavior (since the int has 64 bits perhaps the result should too) but it seems like it should be consistent either way.

I stumbled across this when I discovered that np.meshgrid changes the dtype of single precision float arrays (perhaps a separate issue?) because it multiplies by an array of np.ones unless copy=False.

>>> ax, ay = np.meshgrid(a,a)
>>> ax.dtype
dtype('float64')

>>> ax, ay = np.meshgrid(a,a, copy=False)
>>> ax.dtype
dtype('float32')

[charris]

Scalars and arrays are treated differently when doing promotions. This allows keeoing the type when, say, multiplying a float32 array by a python float (float64). In the array * array case above, there is a search for a common float type to keep precision, although strictly speeking float64 is a bit lacking. The main oddity in your example is that 0-d (scalar) arrays are also treated as scalars in this situation.

The meshgrid case could use discussion, that may be a bug, I'm not sure why it is doing the multiplication with an array of ones.

[idfah]

Scalars and arrays are treated differently when doing promotions. This allows keeoing the type when, say, multiplying a float32 array by a python float (float64).

Why do we need to keep the array's type when multiplying by a scalar? The array is copied anyway, right? I may be missing something... I understand that scalars "are" treated differently during promotion but I don't understand "why".

>>> (a*1.0) is a
False

The main oddity in your example is that 0-d (scalar) arrays are also treated as scalars in this situation.

I agree, seems like 0d should be the same as n-d arrays in any case.

The meshgrid case could use discussion, that may be a bug, I'm not sure why it is doing the multiplication with an array of ones.

Looks like it is done to broadcast it into a new shape. Here is a patch that seems to work:

$ diff function_base.py function_base.py.orig 
3098,3101c3098,3103
<     if copy_:
<         output = [x.copy() for x in output]
< 
<     if not sparse:
---
>     if sparse:
>         if copy_:
>             return [x.copy() for x in output]
>         else:
>             return output
>     else:
3103,3105c3105,3109
<         output = np.broadcast_arrays(*output)
< 
<     return output
---
>         if copy_:
>             mult_fact = np.ones(shape, dtype=int)
>             return [x * mult_fact for x in output]
>         else:
>             return np.broadcast_arrays(*output)

[idfah]

On the other hand, I often view 0-d arrays as being interchangeable with python scalars. I suppose one could make the argument that treating 0-d arrays and scalars differently may lead to additional confusion.

[njsmith]

The reason it works this way is that scalars are often literals. Suppose
you have a very large array, which you have stored using single precision
(float32) to save memory. It would be very annoying if typing '2.0 * a'
triggered an upcast to float64 and doubled your memory usage. You'd have to
be very careful to always write things like 'np.float32(2) * a' or
'np.multiply(2.0, a, dtype=np.float32)' instead.
On 19 Nov 2014 22:12, "Elliott Forney" notifications@github.com wrote:

On the other hand, I often view 0-d arrays as being interchangeable with
python scalars. I suppose one could make the argument that treating 0-d
arrays and scalars differently may lead to additional confusion.

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

[idfah]

Yea, I see that argument. Seems inconsistent but it is also convenient.

My recommendation then (for what its worth) would be to apply the meshgrid patch above to the next release and close this issue.

[njsmith]

Want to make a pull request with your proposed change and a test for it?
On 19 Nov 2014 22:35, "Elliott Forney" notifications@github.com wrote:

Yea, I see that argument. Seems inconsistent but it is also convenient.

My recommendation then (for what its worth) would be to apply the meshgrid
patch above to the next release and close this issue.

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

[idfah]

Sure, I will submit a pull request with a fix and test case tomorrow.

[idfah]

Given two arrays with different dtypes, how does one determine the best dtype to use to store a result involving both arrays. In other words, how do functions like .multiply determine what dtype to use?

[charris]

http://docs.scipy.org/doc/numpy/reference/ufuncs.html#index-4. Basically, the inputs are cast to the type of least precision that can hold both operands and for which the operation is defined.

[rgommers]

meshgrid issue fixed in gh-5302, and the rest is not a bug. so closing.