On Tue, Apr 12, 2011 at 11:49, Mark Wiebe <mwwiebe@gmail.com> wrote:

On Tue, Apr 12, 2011 at 9:30 AM, Robert Kern <robert.kern@gmail.com> wrote:

You're missing the key part of the rule that numpy uses: for array*scalar cases, when both array and scalar are the same kind (both floating point or both integers), then the array dtype always wins. Only when they are different kinds do you try to negotiate a common safe type between the scalar and the array.

I'm afraid I'm not seeing the point you're driving at, can you provide some examples which tease apart these issues? Here's the same example but with different kinds, and to me it seems to have the same character as the case with float32/float64:

np.__version__ '1.4.1' 1e60*np.ones(2,dtype=np.complex64) array([ Inf NaNj, Inf NaNj], dtype=complex64) np.__version__ '2.0.0.dev-4cb2eb4' 1e60*np.ones(2,dtype=np.complex64) array([ 1.00000000e+60+0.j, 1.00000000e+60+0.j])

The point is that when you multiply an array by a scalar, and the array-dtype is the same kind as the scalar-dtype, the output dtype is the array-dtype. That's what gets you the behavior of the float32-array staying the same when you multiply it with a Python float(64). min_scalar_type should never be consulted in this case, so you don't need to try to account for this case in its rules. This cross-kind example is irrelevant to the point I'm trying to make. For cross-kind operations, then you do need to find a common output type that is safe for both array and scalar. However, please keep in mind that for floating point types, keeping precision is more important than range! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco