On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith <n...@pobox.com> wrote: > On 4 Jan 2013 00:39, "Peter Cock" <p.j.a.c...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion