So...running through the outline of method, you would do a single digit decrement, on the lowest digit, but with a mechinism to build or re-create the '9' as a whole BUS full of (9) ones...The next higher digit can supply this...but conventional pencil and paper subtract on multiple digits needs to provide that borrow action only one in every ten pases, as normal integer decrements.
So, it's a phase alignment problem...but the partial, unconditional borrows, of value '1' each, should be evaluated, as the errors may be tolerable, in the bigger picture, of a three digit decrement scheme.
Consider this;. You've started with a '7', on the lowest digit, perform a ratio based reduction, by
'(7 X 0.
' which is '= 5.6' supposed to be '6'.
Uh, that was supposed to show the '.8', not emoji...
Then, assuming unconditional borrow, there, even if it's not properly 'phased' with a real rollover, '0 to 9'.
So the error there is figured by adding the borrow, that was obtained from the next, higher, digit. Of course this is wrong, in the immediate view, but the error never less will be to take that '5.6' and plus the lateral borrow coming over, will then be '6.6'.
That is, if the borrow is perfect...(I'll get to that in a second). So, now your integer decrement is higher than the target '6.0'. The delta (∆) or error delta is going to be ' ∆ = -0.4 '.
That implies that your next psuedo decrement will operate on '6.6', instead of a pure integer '6.0'. So part of the bigger question is, how many of these operations are chained together. It's a road worth traveling, as (I) have little objections to exploring avenues that 'smell' a bit bad, if it's not gonna kill me.
I don't have, yet, complete evaluation, but if you consider a single digit in there; a '2', that will go through only three decrement processes, to get to underflow, ' 0 to 9 '. You would have ' 2 to 1'...giving an actual result of ' 2 X 0.8', plus '1/10' of borrow (~1), for a result of '2.6'. Supposed to be a '1.0'.
Next, would be '2.6 X 0.8' plus '1/10th' of borrow (~1), for result '2.18', that's supposed to be '0'.
For a third time, '2.18 X 0.8' plus '1/10th borrow' (~1),
or a decrement result of '1.744', where then it sits, in the optical BUS macro-column. That isn't a 'proper' underflow, needing actual to be rollover to a '9', but that's where the scheme relies on electronic interpretation, so I'm only annoyed...not devastated yet.
Another example, up higher in the single digit chain, like an iteration count of '7'...(Let's take a look);
Skipping the bulk of calculation, that comes out to
'result of 7 - 3 = 6.02', supposed to be '4.0'.
This process needs adjustment, obviously, but remember the conventional carry or actually 'borrow' is traditionally an integer '10', so being out of phase, in application of that larger size creates an error more prone to something like:
Say, worst case, a '9', that would have;
'9 + 10 lateral borrow', or result of '19'.
The outcome there would have been '17.2', as a result of adding a worst-case lateral borrow of '10'.
True result, of course, of '0 - 1' should be '9'.
So, for a start, that scheme, of doing unconditional partials (of borrow at 1), shows some promise, over a fully blind adding of ten, every ten times.
You just don't know where that lands, phase-wise.
More imperfections / solutions coming up...
( SEAT BELT LIGHT IS...OFF ).