[Numpy-discussion] Odd numerical difference between Numpy 1.5.1 and Numpy > 1.5.1
robert.kern at gmail.com
Tue Apr 12 15:21:37 EDT 2011
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.
> Nope, the kind stuff is missing. Note the cast to float32 that Mark pointed
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
> In : ones(3, '?') + 0
> Out: array([1, 1, 1], dtype=int8)
> In : ones(3, '?') + 1000
> Out: 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
"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
More information about the NumPy-Discussion