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

IIRC, the behavior with respect to scalars sort of happened in the code on the fly, so this is a good discussion to have. We should end up with documented rules and tests to enforce them. I agree with Mark that the tests have been deficient up to this point.

Chuck

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: forOn Tue, Apr 12, 2011 at 11:20, Mark Wiebe <mwwiebe@gmail.com> wrote:

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

>>

>> On Mon, Apr 11, 2011 at 23:43, Mark Wiebe <mwwiebe@gmail.com> wrote:

>> > On Mon, Apr 11, 2011 at 8:48 PM, Travis Oliphant

>> > <oliphant@enthought.com>

>> > wrote:

>>

>> >> It would be good to see a simple test case and understand why the

>> >> boolean

>> >> multiplied by the scalar double is becoming a float16. In other

>> >> words,

>> >> why does

>> >> (1-test)*t

>> >> return a float16 array

>> >> This does not sound right at all and it would be good to understand why

>> >> this occurs, now. How are you handling scalars multiplied by arrays

>> >> in

>> >> general?

>> >

>> > The reason it's float16 is that the first function in the multiply

>> > function

>> > list for which both types can be safely cast to the output type,

>>

>> Except that float64 cannot be safely cast to float16.

>

> That's true, but it was already being done this way with respect to float32.

> Rereading the documentation for min_scalar_type, I see the explanation could

> elaborate on the purpose of the function further. Float64 cannot be safely

> cast to float32, but this is what NumPy does:

>>>> import numpy as np

>>>> np.__version__

> '1.4.1'

>>>> np.float64(3.5) * np.ones(2,dtype=np.float32)

> array([ 3.5, 3.5], dtype=float32)

>>>>

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])

IIRC, the behavior with respect to scalars sort of happened in the code on the fly, so this is a good discussion to have. We should end up with documented rules and tests to enforce them. I agree with Mark that the tests have been deficient up to this point.

Chuck