On Fr, 2016-06-10 at 20:16 +0000, Ian Henriksen wrote: > On Fri, Jun 10, 2016 at 12:01 PM Nathaniel Smith <n...@pobox.com> > wrote: > > On Jun 10, 2016 10:50, "Alan Isaac" <alan.is...@gmail.com> wrote: > > > > > > On 6/10/2016 1:34 PM, Nathaniel Smith wrote: > > >> > > >> You keep pounding on this example. It's a fine example, but, > > c'mon. **2 is probably at least 100x more common in real source > > code. Maybe 1000x more common. Why should we break the > > >> common case for your edge case? > > > > > > > > > > > > It is hardly an "edge case". > > > Again, **almost all** integer combinations overflow: that's the > > point. > > When you say "almost all", you're assuming inputs that are > > uniformly sampled integers. I'm much more interested in what > > proportion of calls to the ** operator involve inputs that can > > overflow, and in real life those inputs are very heavily biased > > towards small numbers. > > (I also think we should default to raising an error on overflow in > > general, with a seterr switch to turn it off when desired. But > > that's another discussion...) > > -n > > > Another thing that would need separate discussion... > Making 64 bit integers default in more cases would help here. > Currently arange gives 32 bit integers on 64 bit Windows, but > 64 bit integers on 64 bit Linux/OSX. Using size_t (or even > int64_t) as the default size would help with overflows in > the more common use cases. It's a hefty backcompat > break, but 64 bit systems are much more common now, > and using 32 bit integers on 64 bit windows is a bit odd. > Anyway, hopefully that's not too off-topic. > Best,
I agree, at least on python3 (the reason is that python 3, the subclass thingy goes away, so it is less likely to break anything). I think we could have a shot at this, it is quirky, but the current incosistency is pretty bad too (and probably has a lot of bugs out in the wild, because of tests on systems where long is 64bits). A different issue though, though I wouldn't mind if someone ponders this a bit more and maybe creates a pull request. - Sebastian > Ian Henriksen > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion