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?