On Tue, Apr 12, 2011 at 13:17, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Apr 12, 2011 at 11:56 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Apr 12, 2011 at 12:27, Charles R Harris <charlesr.harris@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