The method used is probably 2/3 intuitive with barely 1/3 understanding, of some theory involved. OK, maybe 50/50. Expression I've heard, in politics and war, is 'Better LUCK than GOOD', which isn't wholely flattering.

But I've poked and cursed, )mildly(, mainly the compromise between the highest integer-mocking value, starting using a '9.0', but lately using '8.5'. Here's why:

Keeping the first low value multiply in mind, that being a ratio to take down a '3', down 1 (integer or close) unit, to value of '2'. By compromising, just a little, on the full scale range then a decent low end multiplier can be just a liiiitttle, squeezey less, without getting high-end too low.

That little compromise, brings the F.S. range down by 0.5, resulting in countdown from 8.5, in 7 steps for OCTAL use, but not linear at 1.0 per step. Average step size is closer to 0.6, but important to stop, integer-like, with 8 points used as integer-like OCTAL or 8-state counting.

Probably a method 2/3 'LUCK' and persistence. The microprocessor DECREMENT instruction is a must, to get a decent functional platform. Otherwise, perhaps 1/3 is the 'GOOD', or competent aspect, of designing computational elements.

In the diagram, you can notice that the stack structure has the 8 points, in close analogy to a straight, 9 down to 2 decrement, each ideally of subtraction of (exactly) 1.0. In this case, having the F.S. reduced is just simply a 'warp' or scale diminish, to fit 8 inexact counts into space of 7 integers. Please note, that this approximate layout ends up at '1.9'; an approximate value for the perfect '2.0' target goal. Close enough, to proceed with a more full examination of number output results.

Now setting aside the usual type of whole number rounding, this 'coded' sequence will possibly do similar rounding operations, but on an analog range. Take, for example, the two code numbers '4.6' and '3.8', having a mean of '4.2', where your 'rounding' down would be any value below '4.2', and rounding up when '4.2' or greater (within the two counts).

Of course those are the coded values, not the OCTAL value that is range (0 thru 7) for equiv of 3 binary bits of result.

But going in detail down that stack, of multiplies, you can get a sense of, mostly, nice integer behavior:

See, '8 to 6, to 5 to 4, to 3, and again to 3, and a third time, 3, and last two are rounded at 2.

Looks like needing more work adjusting, but that's OK, as previous numbers were far off the mark.

Also, note that my quick assessment at the end was using conventional, rounding at value+0.5, up or down, but still gives a glimpse of the similar form when correctly decrement that range of numbers.

Surprisingly, just the small reduction in overall range, from the '7' counts from '9' to a '2', to a similar '7' counts, but across F.S. range of '8.5', is enough to grant some leeway down at the crucial countdown of '3 to 2'.

Also, note where I've indicated, a full function set of decrements, bringing '9' down, has a last step doing '2.3 down to 1.9', which indicates that the count size, there, is 0.4, while a reconciliation with a separately occurring case of decrement a (stack input) of value '3' in the coded WORD shows up as '2.0', approximately.

What this indicates, is an approximate segment run, of roughly 0.5, in both cases. One case being a '9' decremented down, with the last segment, in the 7 decrements of the multiply stack, the last segment being a '0.4' to approx '2', while case for the other end of the integer-like function, the last segment being a '0.8' down, to approx '2.0'. Those two values, of segment size, are at least close, in terms of order of magnitude, compared to Full Scale (F.S. being near 9 or 8.5).

This tells, that the various interests and outcomes, doing the stack of multiplies, CAN be adjusted with some degree of confidence. To be obtaining, reliably, an OCTAL WORD, at 3 digital bits, is the ultimate goal here, for the digital decrements function output.