On Tue, Apr 12, 2011 at 13:17, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Tue, Apr 12, 2011 at 11:56 AM, Robert Kern <robert.k...@gmail.com> wrote: >> >> On Tue, Apr 12, 2011 at 12:27, Charles R Harris >> <charlesr.har...@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. >> >> It's been documented for a long time now. >> >> http://docs.scipy.org/doc/numpy/reference/ufuncs.html#casting-rules >> > > Nope, the kind stuff is missing. Note the cast to float32 that Mark pointed > out.
The float32-array*float64-scalar case? That's covered in the last paragraph; they are the same kind so array dtype wins. > Also that the casting of python integers depends on their sign and > magnitude. > > In [1]: ones(3, '?') + 0 > Out[1]: array([1, 1, 1], dtype=int8) > > In [2]: ones(3, '?') + 1000 > Out[2]: array([1001, 1001, 1001], dtype=int16) bool and int cross kinds. Not a counterexample. I'm not saying that the size of the values should be ignored for cross-kind upcasting. I'm saying that you don't need value-size calculations to preserve the float32-array*float64-scalar behavior. -- 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