4 ms·

What is the "even/odd theorem" ?

ratmice 11mo ago
that all integers are either even or odd, and that for an even integer that integer + 1 and - 1 are odd and vice versa for odd numbers. That the negative numbers have an additional digit from the positive numbers ensures that low(integer) and high(integer) have different parity. So when you wrap around with overflow or underflow you continue to transition from an even to odd, or odd to even.
- xigoi 11mo ago
  If you need wraparound, you should not use signed integers anyway, as that leads to undefined behavior.
  - ratmice 11mo ago
    Presumably since this language isn't C they can define it however they want to, for instance in rust std::i32::MIN.wrapping_sub(1) is a perfectly valid number.
    - xigoi 11mo ago
      Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
      - beagle3 11mo ago
        And yet, Nim does overflow checking by default.
  - School-Cotton 11mo ago
    Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing.
    - xigoi 11mo ago
      Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
      - School-Cotton 11mo ago
        > making basic types work differently from C would involve major performance costs. Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.
      - ratmice 11mo ago
        Presumably unsigned want to return errors too? Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything.
    - Symmetry 11mo ago
      Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern.
      - aw1621107 11mo ago
        Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
      - Asooka 11mo ago
        Back when those machines existed, UB meant "the precise behaviour is not specified by the standard, the specific compiler for the specific machine chooses what happens" rather than the modern "a well-formed program does not invoke UB". For what it is worth, I compile all my code with -fwrapv et. al.

that all integers are either even or odd, and that for an even integer that integer + 1 and - 1 are odd and vice versa for odd numbers. That the negative numbers have an additional digit from the positive numbers ensures that low(integer) and high(integer) have different parity. So when you wrap around with overflow or underflow you continue to transition from an even to odd, or odd to even.

xigoi 11mo ago
If you need wraparound, you should not use signed integers anyway, as that leads to undefined behavior.
- ratmice 11mo ago
  Presumably since this language isn't C they can define it however they want to, for instance in rust std::i32::MIN.wrapping_sub(1) is a perfectly valid number.
  - xigoi 11mo ago
    Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
    - beagle3 11mo ago
      And yet, Nim does overflow checking by default.
- School-Cotton 11mo ago
  Signed overflow being UB (while unsigned is defined to wrap) is a quirk of C and C++ specifically, not some fundamental property of computing.
  - xigoi 11mo ago
    Nim (the original one, not Nimony) compiles to C, so making basic types work differently from C would involve major performance costs.
    - School-Cotton 11mo ago
      > making basic types work differently from C would involve major performance costs. Not if you compile with optimizations on. This C code: int wrapping_add_ints(int x, int y) { return (int)((unsigned)x + (unsigned)y); } Compiles to this x86-64 assembly (with clang -O2): wrapping_add_ints: lea eax, [rdi + rsi] ret Which, for those who aren't familiar with x86 assembly, is just the normal instruction for adding two numbers with wrapping semantics.
    - ratmice 11mo ago
      Presumably unsigned want to return errors too? Edit: I guess they could get rid of a few numbers... Anyhow it isn't a philosophy that is going to get me to consider nimony for anything.
  - Symmetry 11mo ago
    Specifically, C comes form a world where allowing for machines that didn't use 2's compliment (or 8 bit bytes) was an active concern.
    - aw1621107 11mo ago
      Interestingly, C23 and C++20 standardized 2's complement representation for signed integers but kept UB on signed overflow.
    - Asooka 11mo ago
      Back when those machines existed, UB meant "the precise behaviour is not specified by the standard, the specific compiler for the specific machine chooses what happens" rather than the modern "a well-formed program does not invoke UB". For what it is worth, I compile all my code with -fwrapv et. al.