[Numpy-discussion] Odd numerical difference between Numpy 1.5.1 and Numpy > 1.5.1

[Robert Kern]

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