On Tue, Apr 12, 2011 at 10:49 AM, Mark Wiebe <mwwi...@gmail.com> wrote:
> On Tue, Apr 12, 2011 at 9:30 AM, Robert Kern <robert.k...@gmail.com>wrote: > >> On Tue, Apr 12, 2011 at 11:20, Mark Wiebe <mwwi...@gmail.com> wrote: >> > On Tue, Apr 12, 2011 at 8:24 AM, Robert Kern <robert.k...@gmail.com> >> wrote: >> >> >> >> On Mon, Apr 11, 2011 at 23:43, Mark Wiebe <mwwi...@gmail.com> wrote: >> >> > On Mon, Apr 11, 2011 at 8:48 PM, Travis Oliphant >> >> > <oliph...@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) >> >>>> >> >> 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]) > > 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
