Dwedit wrote:

8-bit dividing by 10 is the same as doing 16-bit multiplication by 0x1A (00011010), then discarding the low byte. So that's x << 4 + x << 3 + x << 1 in 16-bit math.

Dividing by 6 is multiply by 0x2B (00101011), or x << 5 + x << 3 + x << 1 + x.

16-bit shifts and adds take up code and time.

To clarify, this is a fixed point

*approximation* technique. The results are not entirely accurate.

The approximation works because a division by 256 is "cheap", so you can rescale the input with a pre-multiply.

**Code:**

x / d = x * a / 256

d = a / 256

a = 256 / d

d = 10 --> a = 256 / 10 = 25.6

x / 10 = x * 25.6 / 256

d = 6 --> a = 256 / 6 = 42.666...

You will notice that these are not

*exactly* 26 (0x1A) or 43 (0x2B). This is why it's an approximation, and you will find the result is off by 1 in some cases:

**Code:**

⌊ 69 / 10 ⌋ = 6 (6.9)

⌊ 69 * 26 / 256 ⌋ = 7 (7.0078125)

Depending on whether you need perfect results or not, this may not be an acceptable compromise. You could increase it to 24 bits for more precision, or in some cases you might be able to adjust some errors by carefully adding a bias value.

Dwedit, I'm curious why you offered these numbers in hexadecimal

*and* binary but not decimal. What significance do they have in hex/bin?