On Tue, Apr 12, 2011 at 11:49, Mark Wiebe <mwwi...@gmail.com> wrote: > On Tue, Apr 12, 2011 at 9:30 AM, Robert Kern <robert.k...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion