On Fri, Dec 31, 2021 at 12:12 AM Charles R Harris <charlesr.har...@gmail.com> wrote:
> > > On Thu, Dec 30, 2021 at 4:12 AM Lev Maximov <lev.maxi...@gmail.com> wrote: > >> On Wed, Dec 29, 2021 at 9:59 AM Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> On Tue, Dec 28, 2021 at 2:54 PM Warren Weckesser < >>> warren.weckes...@gmail.com> wrote: >>> >>>> On 12/28/21, Lev Maximov <lev.maxi...@gmail.com> wrote: >>>> > On Tue, Dec 28, 2021 at 3:43 PM Evgeni Burovski >>>> > <evgeny.burovs...@gmail.com> >>>> > wrote: >>>> > >>>> >> Very nice overview! >>>> >> >>>> >> One question and one suggestion: >>>> >> >>>> >> 1. Is integer wraparound guaranteed for signed ints, or is it an >>>> >> implementation detail? For unsigned ints, sure, it's straight from a >>>> C >>>> >> standard; what about signed types however. >>>> >> >>>> > Signed ints wraparound in just the same way as unsigned, both in C >>>> and in >>>> > NumPy. Added an illustration. >>>> >>>> Overflow of *signed* ints in the C language is *undefined behavior*. >>>> In practice, most compilers might do what you expect, but the >>>> wrap-around behavior is not guaranteed and should not be relied on. >>>> >>>> Warren >>>> >>>> >>> There used to be one's complement machines. I expect Numpy will break >>> badly if it is compiled for anything that doesn't use two's complement. >>> >> >> Chuck >>> >> >> Yes, according to C standard signed integer overflow is undefined >> behavior. >> >> So, does NumPy guarantee wraparound for signed ints overflow? >> (at least provided that the platform is two's complement) >> >> There is an open issue >> "Document behavior of casts and overflows for signed integer types" #17982 >> https://github.com/numpy/numpy/issues/17982 >> There is some discussion, but no definitive answer. >> >> As a side note, Rust has both checked/unchecked wraparound arithmetic and >> saturated arithmetic >> as specialized methods: >> >> pub const fn saturating_add(self, rhs: u32) -> u32 >> pub fn saturating_add_signed(self, rhs: i32) -> u32 (experimental) >> pub const fn saturating_mul(self, rhs: u32) -> u32 >> etc. >> >> > There have been discussions about overflow behavior. The main problem is > performance when there is no hardware support. There used to be > architectures that offered that (VAX), but it has fallen out of favor. > NumPy doesn't have an official policy that I know of, but it is currently > pretty much two's complement with overflow wrap. Which is not to say that > things will never change, but it isn't a priority. > Yes, that reflects my expectations. My primary concern right now is how to formulate this to the readers of the article so as not to mislead them. Can they rely on the wraparound for the signed ints in NumPy? Or is it rather 'use at your own risk'? Btw, is signed integer wrapping covered by regressions? Lev > > Chuck > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: lev.maxi...@gmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
