[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

Peter Cock p.j.a.cock@googlemail....
Thu Jan 3 19:17:42 CST 2013


On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith <njs@pobox.com> wrote:
> On 4 Jan 2013 00:39, "Peter Cock" <p.j.a.cock@googlemail.com> wrote:
>> I agree with Dag rather than Andrew, "Explicit is better than implicit".
>> i.e. What Nathaniel described earlier as the apparent consensus.
>>
>> Since I've actually used NumPy arrays with specific low memory
>> types, I thought I should comment about my use case if case it
>> is helpful:
>>
>> I've only used the low precision types like np.uint8 (unsigned) where
>> I needed to limit my memory usage. In this case, the topology of a
>> graph allowing multiple edges held as an integer adjacency matrix, A.
>> I would calculate things like A^n for paths of length n, and also make
>> changes to A directly (e.g. adding edges). So an overflow was always
>> possible, and neither the old behaviour (type preserving but wrapping
>> on overflow giving data corruption) nor the current behaviour (type
>> promotion overriding my deliberate memory management) are nice.
>> My preferences here would be for an exception, so I knew right away.
>
> I don't think the changes we're talking about here will help your use case
> actually; this is only about the specific case where one of your operands,
> itself, cannot be cleanly cast to the types being used for the operation -

Understood - I replied to your other message before I saw this one.

> it won't detect overflow in general. For that you want #593:
> https://github.com/numpy/numpy/issues/593
>
> On another note, while you're here, perhaps I can tempt you into having a go
> at fixing #593? :-)
>
> -n

I agree, and have commented on that issue. Thanks for pointing me to
that separate issue.

Peter


More information about the NumPy-Discussion mailing list