News for hackers. Stuff that matters.
Re:Myths about Integer Overflow in Rust by vog on Friday April 29, 2016 @02:52PM (#11597888)
Why do people invent these strange terms?

"wraparound arithmetic". "unchecked arithmetics". Really?

The correct term is modular arithmetic, which is well established in maths for centuries. And it is properly backed by a really nice and almost dead-simple theory (at least from a programmer's point of view). Is this no longer taught in school?

If you like to emphasize the fact that it's mostly modulo a power of two (2^n), then call it two's complement. However, that overemphasizes the binary representation, which I find most of the time more distracting than helpful.

As a side note, integer division is usually not performed in modular arithmetics, but addition, subtraction and multiplication are.

Re:Myths about Integer Overflow in Rust by jimktrains2 on Friday April 29, 2016 @03:47PM (#11598278)
It's modular arithmetic because of the internals of the processor, not because of some law-of-the-universe.

It could just as easy a processor not allow over- or under- flow operations. However, it's easiest to just truncate the number and essentially do modular arithmetic. That's the difference. Over- or under- flow, checked, wrap-around all refer to the state at which the operation's answer needs more space than it is given. Modular arithmetic and checked instructions are what to do in those situations.

Aside, division in modular arithmetic can be done, but it's not what most people want (hence why usually not performed). 4 / 3 mod 7 -> 4 * 5 mod 7 ( 5 is the multiplicative inverse of 3 mod 7 ( 3 * 5 = 1 mod 7) -> 6 mod 7

Re:Myths about Integer Overflow in Rust by vog on Saturday April 30, 2016 @03:45AM (#11600822)
> It's modular arithmetic because of the internals of the processor, not because of some law-of-the-universe

I beg to differ. There were various integer representations tried, such as having a separate "sign" bit on integers. But the two's complement finally was used by everyone. So there's something deeply unique to modulo arithmetics that none of the other representations could offer. This is not just about saving a few gates in the circuit.

> However, it's easiest to just truncate the number and essentially do modular arithmetic

The point is, there is no truncatenation step. It's just a side effect. If you build any naive adder circuit, substractor, multiplicator - even if you totally ignore negative numbers, you automatically have a full working two's complement, that works for negative numbers without any additional effort.

And why is that? Because the mathematical structure behind it is so dead-simple that it almost works by miracle. (except for division, which is highly non-intuitive and has more pitfalls than usual pitfall of division by zero.)

As a consequence of this simple math structure, it is very easy to build in hardware without any additional handling of nasty special cases.

Re:Myths about Integer Overflow in Rust by jimktrains2 on Saturday April 30, 2016 @11:07PM (#11604676)
> As a consequence of this simple math structure, it is very easy to build in hardware without any additional handling of nasty special cases.

Which is exactly my point! It's only the way we build things, not some hard-and-fast way things work intrinsically. I have no argument with it's an extremely simple way to deal with an over- or under- flow. But that's my point! It's a way to deal with the case, not the case itself!

Re:Myths about Integer Overflow in Rust by jimktrains2 on Sunday May 01, 2016 @09:06AM (#11606014)
I guess I missed my edit window:

> except for division, which is highly non-intuitive and has more pitfalls than usual pitfall of division by zero.

Division literally works the same way it does normally:

10 / 2 = 5 => 5 subtractions of 2 from 10 gives 0.

    0: 10
    1:  8
    2:  6
    3:  4
    4:  2
    5:  0
4 / 3 = 6 mod 7 => 6 subtractions of 3 from 4 gives 0

    0: 4
    1: 1
    2: 5
    3: 2
    4: 6
    5: 3
    6: 0
I wouldn't say it's fraught with pitfalls, just that it's not common to see. FWIW, in an under- or overflow- situation we normally don't want modular arithmetic, hence why we still attempt to trap instead of ignore it.
Re:Myths about Integer Overflow in Rust by vog on Monday May 02, 2016 @06:44AM (#11610413)
I was referring to the non-prime modulo values, such as 2^32 or 2^64. In those cases, you do not only have "well-defined" and "division by zero", but also "division with multiple valid results". More generally, this is the issue of zero divisors. [1]

Modulo 2^n, you have proper division only if you divide by odd numbers, then you have division by zero, and finally you have division by any other even number, which is very different from what people used to. There may be no solution, or two solutions, or many more solutions.

Yes, could can still solve them by reducing the modulo, but that's the extra pitfall that you don't have with plain integers or rationals.

[1] https://en.wikipedia.org/wiki/Zero_divisor

Re:Myths about Integer Overflow in Rust by khedoros on Friday April 29, 2016 @03:34PM (#11598193)
> Why do people invent these strange terms?

Same reason we talk about a "for loop" or a "while loop", instead of just a "conditional branch". Different words add different context to the concept that they're based on. For example, "modular arithmetic" doesn't include the context of checking for undesired leaks in Rust's arithmetic implementation. "Unchecked arithmetic" does.

Re:Myths about Integer Overflow in Rust by zAy0LfpBZLC8mAC on Friday April 29, 2016 @03:05PM (#11597993)
(2147483647 + 1) % m = -2147483648

What is the m?

Re:Myths about Integer Overflow in Rust by periodontal on Friday April 29, 2016 @05:52PM (#11599016)
2147483647 + 1 is congruent to -2147483648 modulo 4294967296.
Re:Myths about Integer Overflow in Rust by vardump on Friday April 29, 2016 @05:55PM (#11599025)
Maybe it's an Apple thing. Sometimes they make up silly names like "Grand Central Dispatch" for executing a block in parallel in multiple threads. "ARC" makes me still think "adaptive replacement cache", not "automatic reference counting". At least they don't call it "automatic retain count". After all, they used to call "reference count" as "retain count". Confused the heck out of me on my first exposure to Objective-C.

Not that others like Microsoft don't do the same thing, renaming commonly known concepts to something they made up. Like DEP vs NX vs XD. Or Interlocked* for atomic operations. Atomic add in Microsoftese is InterlockedAdd.

Re:Myths about Integer Overflow in Rust by renox on Friday April 29, 2016 @06:30PM (#11599172)
Unchecked != modulo in Rust case, I think that the compiler is free to generate either a trap on overflow or a modulo result. After all the MIPS has trap on overflow instructions..
Re:Myths about Integer Overflow in Rust by dllthomas on Saturday April 30, 2016 @04:00AM (#11600855)
> If you like to emphasize the fact that it's mostly modulo a power of two (2^n), then call it two's complement.

And it's signed, and negative numbers work by, well, two's complement...

Referring to unsigned integers, modulo a power of two, as "two's compliment" is at least weird.

Referring to integers with a different encoding of negative numbers as "two's complement" would be incorrect, even if they still wrap around near a power of two.