3 ms·

> Assuming you meant 2^31 Where? > The first equation in that second block (and so the rest of the block) doesn't really make sense in 32 bit two's complement

> Assuming you meant 2^31 Where? > The first equation in that second block (and so the rest of the block) doesn't really make sense in 32 bit two's complement arithmetic My point exactly. > computer representations of numbers aren't accurate The numbers which can be represented in a computer are perfectly accurate. > and don't follow the usual rules, in more ways than just overflow. At a low level, we program computers to perfom bit operations on registers. Some operations are more straightforward and efficient than others, but ultimately it's how we interpret the bit patterns that makes them "numbers". So if they "don't follow the usual rules", it's our own fault. Security of low-level code has been enough a royal fuckup for long enough now that perhaps we should start to reevaluate some of our traditional assumptions about how CPUs should behave.

azernik 13y ago
>> The first equation in that second block (and so the rest of the block) doesn't really make sense in 32 bit two's complement arithmetic > My point exactly. It doesn't make sense because there's no such number as 2^31 in 32-bit two's complement arithmetic, and I don't think the finite range of finite-length number representations is really a solvable problem. This inevitably leads to a lot of mathematical weirdness, because our math is built on the set of integers being infinite (which is the only kind of set of integers in which closure on addition makes any sense at all). >> and don't follow the usual rules, in more ways than just overflow. > At a low level, we program computers to perfom bit operations on registers. Some operations are more straightforward and efficient than others, but ultimately it's how we interpret the bit patterns that makes them "numbers". Any finite representation of numbers is going to have to break the familiar mathematical rules somehow; I'm pretty satisfied with the tradeoffs made in our current integer representations (unsigned more than signed, but that's in some ways an easier problem).
- betterunix 13y ago
  "Any finite representation of numbers is going to have to break the familiar mathematical rules somehow;" How is that? The only numbers you would have trouble with are non-computable numbers, and I doubt you will find many software systems that deal with those. The only limiting factor should be the memory that is available, but that is beyond the scope of software; the software should work up to the limits of available memory, and increase the amount of memory should increase the range of numbers the program can deal with. "I'm pretty satisfied with the tradeoffs made in our current integer representations" I'm not, because (a) the semantics are counter-intuitive and (b) not a day goes by without people finding bugs related to integer overflows or weird, unexpected behavior. We have security problems. We have reliability problems. Voting machines get hacked and report negative vote totals. At the very least, integer overflows should trigger an exception unless the programmer explicitly requests arithmetic modulo 2^32 (or 2^64, or 2^29, or whatever weird bit width the hardware supports).
- marshray 13y ago
  > It doesn't make sense because there's no such number as 2^31 in 32-bit two's complement arithmetic I started out with the definition: 0x7FFFFFFF = 2^31 - 1 Adding one to that 0x7FFFFFFF + 1 = 2^31 - 1 + 1 should be 2^31, but it isn't.

azernik 13y ago

>> The first equation in that second block (and so the rest of the block) doesn't really make sense in 32 bit two's complement arithmetic > My point exactly. It doesn't make sense because there's no such number as 2^31 in 32-bit two's complement arithmetic, and I don't think the finite range of finite-length number representations is really a solvable problem. This inevitably leads to a lot of mathematical weirdness, because our math is built on the set of integers being infinite (which is the only kind of set of integers in which closure on addition makes any sense at all). >> and don't follow the usual rules, in more ways than just overflow. > At a low level, we program computers to perfom bit operations on registers. Some operations are more straightforward and efficient than others, but ultimately it's how we interpret the bit patterns that makes them "numbers". Any finite representation of numbers is going to have to break the familiar mathematical rules somehow; I'm pretty satisfied with the tradeoffs made in our current integer representations (unsigned more than signed, but that's in some ways an easier problem).

betterunix 13y ago
"Any finite representation of numbers is going to have to break the familiar mathematical rules somehow;" How is that? The only numbers you would have trouble with are non-computable numbers, and I doubt you will find many software systems that deal with those. The only limiting factor should be the memory that is available, but that is beyond the scope of software; the software should work up to the limits of available memory, and increase the amount of memory should increase the range of numbers the program can deal with. "I'm pretty satisfied with the tradeoffs made in our current integer representations" I'm not, because (a) the semantics are counter-intuitive and (b) not a day goes by without people finding bugs related to integer overflows or weird, unexpected behavior. We have security problems. We have reliability problems. Voting machines get hacked and report negative vote totals. At the very least, integer overflows should trigger an exception unless the programmer explicitly requests arithmetic modulo 2^32 (or 2^64, or 2^29, or whatever weird bit width the hardware supports).
marshray 13y ago
> It doesn't make sense because there's no such number as 2^31 in 32-bit two's complement arithmetic I started out with the definition: 0x7FFFFFFF = 2^31 - 1 Adding one to that 0x7FFFFFFF + 1 = 2^31 - 1 + 1 should be 2^31, but it isn't.