Figuring out round, floor and ceil with integer division

I was surprised by the observation that Python rounds towards even numbers, so round(0.5) = 0, but round(1.5) = 2.<p>This is indeed clearly documented [1], I guess I never looked closely enough. I found some discussion on the dev-python list [2] which shows at least I&#x27;m not the only one surprised by this!<p>[1] <a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;functions.html#round" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;functions.html#round</a><p>[2] <a href="https:&#x2F;&#x2F;groups.google.com&#x2F;g&#x2F;dev-python&#x2F;c&#x2F;VNf8TABiB9k" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;g&#x2F;dev-python&#x2F;c&#x2F;VNf8TABiB9k</a>

A fun fact about integer division is that on x86 dividing by zero is CPU exception 0. Except, it&#x27;s not just for dividing by zero, it&#x27;s whenever a division is impossible to perform.<p>So, for example what happens if you divide -1 by -INT_MIN? As you probably know, Abs(INT_MIN) is larger than INT_MAX, and so it is not possible to perform -1 &#x2F; INT_MIN, as well as -1LL &#x2F; INT64_MIN. It will crash your program, your emulator&#x2F;sandbox and your server. So, be careful!

In case divisor is always positive, you can use these variants:<p><pre><code> int divF(int a, int b) { return a &#x2F; b - (a % b &lt; 0); } int divC(int a, int b) { return a &#x2F; b + (a % b &gt; 0); } </code></pre> They should be faster as it avoids branching: <a href="https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;qrraj8s6j" rel="nofollow">https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;qrraj8s6j</a>

&gt; We could stop right here but this suffers from overflow limitations if translated into C.<p>FWIW, the final version also suffers from integer overflow limitations. If the difference between an and INT_MIN&#x2F;INT_MAX (depending on whether you floor or ceil) is &lt;= b&#x2F;2, you will have integer overflow.

&gt; transforming a float based algorithm to integers in order to make it bit-exact<p>Modern CPUs, and most programming languages, guarantee bit-exactness for floats most of the times, because they implement IEEE 754.<p>Relatively easy to break (approximate instructions like rsqrtps, FMA instructions, compiler switches like -ffast-math or &#x2F;fp:fast, MXCSR rounding modes) but I think fixing bugs is probably easier than refactoring everything from FP into fixed-point.<p>BTW, multiplication&#x2F;division&#x2F;rounding instructions are much faster for floats. I think a fixed-point version will only be a performance win when the integers are 8 or 16 bits wide, and the algorithm is vectorizable.

Thanks to the author for describing everything so clearly!

I wonder if there is a use case for this instead of fixed point math which is more precise than floating point math

As always, Hacker&#x27;s Delight is a wonderful book for all integer arithmetic tricks and operations.

til: &quot;ceil&quot; is a verb

I&#x27;m intensely interested in this type of stuff, but the article throws me off right away. If I were do undertake this project, I wouldn&#x27;t &quot;define round the way POSIX does&quot; and &quot;integer division the way C11 does&quot;. Instead I&#x27;d reinspect the choices POSIX made and the choices C11 made, and then create routines that work however you need it to, i.e. that are configurable and let you control how it works.<p>Rounding--which btw I prefer to think of as rounding to a decimal place, not rounding to an integer--for example, can introduce biases because there are 10 digits, 0 through 9, but &quot;11 spots on the dial&quot;, from round-down-to-0 to round-up-to-0 and therefore 5 is &quot;the exact center&quot; and always rounding 5 in one direction is going to bias your results in one direction, depending on your dataset. The article is breezing past this stuff.<p>I&#x27;m going to keep reading because I&#x27;m sure I&#x27;ll learn some interesting things, but at the end of the first page my skin is crawling because I can see ambiguities in the examples I&#x27;m being shown and I keep thinking &quot;wut?&quot;.