Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

   I let a little time pass...couple seconds, while I obsess on little itty bitty decrements.  Wondering now, what about a 3 digit non-standard 'integer decrement'?
Then, it would be same pattern of approximate solution, always followed by and corrected by the 'Terminus', conventional fast electronic / optical hardware, at 'bottom' of run.
   To decrement, say ' 432 ', or actually more
 like ' 0.432 ', you would decrement the '2', followed by a 1/10 unconditional roll-over type 'borrow', creating an add or increment...so no action in the 'ones' column.
Plus now you'd like to avoid the rollover, of 'tens' column digit, ' 3 '.  Same deal.
The tens column gets a decrement, (or actually a 'virtual' decrement), followed, as with the ones digit, it's followed by a 'virtual' increment from the 1/10th partial (unconditional) roll-over borrow.
(Gosh, this technology is FUN!).

   Then, at last, it's time to pay the piper
(what ?? His 10 %?...gawd this language abuse is FUN!)
For the final, high digit it gets similar treatment, that being an equivalent approximation, to a decrement by
' 0.001 '.  That done by way of multiplication, by something similar to ' X 0.998 '.

   I've tried 'talking up' the ladies, in nearby BAR, when asked what I do.  (Refer to above text)

[RJSV]

   To point out why the decrement is not trouble-free, let's try single digit decrement of ' 14 ', obviously out of range, but still a valid analog value, in the ones column.
   Try decrement ' 14 ' all in one column.  With single (discrete or digital type) multiply of ' X 0.8 ' you've obtained an answer value of ' 11.2 ' where the exact answer should be ' 13.0 '...a value too low by ' 1.8 ', or
a ∆ of ' - 1.8 '.
Correct value, for a ' 5 ' will be multiplied out
 as ' 5 X 0.8 ' = 4 which is exact.  So choice involves whether or not you can live with that substantial error, by letting the single digit get out of bounds...although still valid as a BUS signal.
   Using a wider multiplier, like ' 0.85 ' or even deeper, into ' X 0.998 ', or ' X 0.9997 ', can help the process achieve stated goals, but issue is more along the lines of practical extreme tactics, rather than some extra hassle doing the 4 digit X 3 digit multiplies in hybrid analog X digital forms.

[RJSV]

   The problem with using multiply (by 0.8 for instance) is that it's only spot-on at one point, as when multiplying by the one digit ' 5 '.  That will give a clearly accurate ' 5 - 1 = 4.0 ', which is very integer-like.
But each of the count single digit numbers obviously will decrease, below ' 5 ' or will be too big above ' 5 '.
Would be nice, to create ranges, say using 2 ranges, high and low, each using a center, like ' 3 ' for the low range decrement, and the number ' 6 ', as the high range center. (Please see diagram).  As the distance to those 'centers' decreases, the counting down error, vs. true integer decrement becomes less.
   Perhaps, having another parallel parameter, running along with your target digit could track along as the numeral digit changes,...creating one range for each digit decrement, possibly further 'controlling' each process step error.
   Diagram showing; splitting into the two ranges for computing a 'pseudo integer' decrement, having low enough error that can be tolerated, through some longer chain (of further decrements).

[RJSV]

  Now that last explanation is not entirely relevant, as the single digit by single digit multiply is not employed, but it serves to illustrate the issues about accuracy (of a traditional decrement).
Surprising that the results are not wildly inaccurate.  I would have thought that the ' X 0.8 ' multiplier would be expanded, in resolution, to something like ' X 0.85 ',
or ' 0.854 ' etc. when going to higher digit columns, ignoring the lower partitioned 2 columns, but it turns out the compromise multiplier jumps to something more close to ' 0.998 '.
   
   All of this may seem boring / useless,...until it isn't.
Many innovations started this way, although caution and reality seem pretty stacked (against).  Then, O.K. could just call the attempts an interesting / entertaining 'puzzler', like some gastly giant crossword puzzle.
   Getting a very high speed Floating Point package together would be very nice!  At least, now motivating to learn the inside details, around the use and formats of floating point, and (64 bit) 'double-precision'.
Idea is to get the low level routines, optically done, to get the messy digit by digit multiplies and integer decrements working, and the higher up layers WITHOUT these super cludges.
   One other thing to realize is majority of digit by digit multiplies have overflow, (like ' 3 X 4 = 12 ') and cannot 'skip' over the lower digits like the decrement has.
So THAT problem maybe looms; I'm more optimistic now, after all the fiasco around decrements, and the employment of clues and deduction, in that optical ALU design.

[RJSV]

   Here is a pretty wild idea:. (seatbelt light is ON).
   In diagram, every multiply ' X 0.8 ' has that residue light amount, supposed to be a '1' as in recent discussion.  For building a digital BUS, separately right 'on the spot', each of 5 of these analog multiplies saves that way, each time a shift-in. So, after those 5 there is '4' or up to '4' and that's DIGITAL, now!
  Advantage is, each column that is clear (of any light), is completely clear, after having no actual conduits, blocked at first.  That way the last 4, assuming there are at least 5 'analog' conversions available...

[RJSV]

   It looks like I got lucky, in doing the format type, where there are 3 columns, each with column weighted sub-totals.  Ignoring decimal pt. for a second, you've got ' 4X 100's' + ' 2 X 10's ' + ' 5 X ones '. 
That separation allows for keeping things into bounds, although the analog BUS style does allow for, really, any analog weight or value.  But with keeping to limits you've reduced, tremendously, the 'guesswork' required to resolve and decrement from ' 10 ' max., Integer counts ' 10, 9, 8, 7, 6, 5 ' that's about half the possible range, of starting point, for iteration count-down.
The 'worst' (I think) is attempting to 'decrement' a '1', as shown follows:
   Say, multiplier is X '0.6', compare that with previously described '0.8'.  So implementing attempt to decrement a '4' and also doing a constant offset added in first, result is:
   '(4+0.5) X 0.6 = 2.7' Should be '3', that's '∆ -0.3 ' error.
   '(1+0.5) X 0.6 = 0.9' Should be '0', or '∆ + 0.9' error.
   You can see, the 'last' decrement is problematic, and is needing to be a good, zero or close as possible.
(See diagram).
   The restriction of the '2' value digit shown as the middle or tens column digit means that there isn't some big, arbitrary value, '.000 thru .999 ', but rather it is limited to ten possible values, to guess at, assuming we'll behaved single digit.  Separating out the 3 digits that way allows for some fancy guesswork.
   Having the TWO ranges, each with associated method, allows for 'analog' decrements, by way of decimation or 'ratiometric decimation', on first range.
The second range can then take over, that being decrements from ' 5, to 4, to 3, 2, 1, 0' that being digital decrements, achieved thru shifting.  Shifting the partitioned analog word creates EXACTLY zero, not some little residue, like 0.004 after several diminishing functions, of ratiometric style.
   '

[RJSV]

   So, it's very hard to conceptualize, but each smaller portion is somewhat simple.  The main idea is to do reasonable integer-like decrements.
  Viewing the previous diagram, showing a 3-digit value, ' 425 ', readers can surmise; problem becomes separated into ranges, by digit power, but with more separating concepts, using two ranges within an unknown digit, so then, we have a closing in, on that (exact) integer value.  This, of course, is separate from any 'compiler' that tracks, implicitly,...know the exact loop count, representing that 'unrolled loop'.
   Looking at case-by-case, there are (now) only 10 cases, not some open-ended 'hundreds' of possible analog values.  For example, a number value like '493' will have some stranger multiplication value, (to simulate an integer decrement), to go to '492' vs. a reasonable ranged '0 thru 9', or '0 thru 10'.

   Reluctantly, I've supplemented the partitioned analog BUS format style, to include a '10' weight bit flag.  So, in total you've got 10 weight flag signals, plus another 'zero weight' flag, useful as a data transfer flag, for inclusion of zero state (in data transfers).
   A difficult situation is with a single '1' state coming into the number decrement apparatus.  With that, the decrement is performed with error, often figuring too high, like going from '1' down to 'zero', which, imperfectly will be a '0.6' result, or '∆= +0.6 ', too high.
Thus, that area of decrement function should be more heavily emphasized / prioritized.  When starting up higher, say starting at '9', it is guaranteed that the final 4 decrements, or so, will be purely integer.  At the least, that will help speed up and simplify any electronics utilized at the 'bottom' of code stack.
There are only '10,...(11 ??)' conditions or starting conditions to consider, while optimizing the whole set, with various compromises.  Remember, at first glance the system does not know what iteration count is present, for all the 'detective work' used to narrow down the range needing solutions.  Of course, all this complication, is only to be able to do a decent DECREMENT, of some single digit, within a string of weighted digits. (We don't know those values either!)

[RJSV]

   And so I've laid out some approach, with consideration for limiting factors, mainly being needing to do a run-thru table for the ten possible input values, to the start of the structure (remember, this is a mostly passive design, for speed.)
  Starting at '0, 1, or 2,...) you've got a fairly difficult / error prone range, to maybe prioritize, simultaneously tolerating larger errors, as get to '4 or 5', (starting value to count down).  Then, after '5' of those, the switchover to integer decrement, '5, 4, 3, 2, 1, 0, underflow), where the 'extra' light from ratiometric decrements can take over, as there is enough (light amplitude) to perform decrements by shifting right (digital).
The analog 'borrow', or underflow gets in the mix

   By the way, the electrical values I've been using, on the '000 thru 999' BUS format, is '0.1', for big digit '1',(column or  'macro-column').
The middle digit is value, (ten X less) '0.01', and smallest digit is analog value '0.001' for each count.
To create an actual physical value, those three weighted 'macro-columns' are simply added together, for the range outcome to be '0 thru 0.999 volts.  This of course is going to actually correspond to some number of lumens.

[RJSV]

   Here is a diagram illustrating the BUS format supplemented by a '10' weight bit (flag) within that one macro-bus, for the middle of 3 decimal digits (tens).
Besides concatenating the '10' column it is needed to have a 'zero' weight, only for place to place data transfer purposes.
   The other 2 macro-columns have similar considerations, although the highest digit, 'hundreds' does not have underflow.  A bug exists (no one spotted it, lol),  that is where it is needed to propagate an underflow borrow, when you have a 3- digit value like:
   '031'... Need to be careful of improperly decrementing that high digit, for proper result without overflow on the highest of the three digits

Right now, I have to go offline, about 3 days, constructing tables and more tables.

- - thanks for considering analog !

[RJSV]

Dual formats

[RJSV]

   With a single digit, (within one macro-column), was thinking (incorrectly), going to need a load constant, of ' 9 ', as an isolated digit reload, or underflow borrow.
Some early format had each column at 'equal' weight, physically, ranging 0.0 thru 0.9 on each of the three, but this time they have true relation, being in form of
   '4 x 100', '3 x 10', '1 x 1'.
   But, needing a '9' 's worth of light amplitude, whenever a borrow happens, going '0 to 9', is what WOULD HAVE been called for...However, that value '10' brought over, cross to next (macro) column has been replaced, by the little, 1/10 carries, that happen unconditionally...that's the rules of the game.  Now as to whether, or not, that brings in small to moderate errors...things are so confused / confusing that it's best to start generating tables, via my simulator hardware, (OR, if someone want to volunteer, to crunch the data tables for us...?).
   It's possible, the unconditional 1/10th carry, a 'one' put (added thru merging) into current macro-column, is maybe too early,...adding something before an underflow even happens, resulting in a too-high result, temporarally.
That, actually when taken properly into account, might yeild some useful results, in the quest for taking a '1' downward close to underflow territory.  Of course, going from '0' down is, like I said, problematic, but that's only if a fully expressed underflow (like conventional) is needed.  It likely is not needed.
   It's like the book, they say, you have to read it, before you can (evaluate) what's in it.
Cheers.

[RJSV]

   To explain, in more detail, the multiplying conversion, to take a '1' to a '0', won't ever work perfect; there always is some residue.  But also, we are stuck (I think) stuck with using whatever unconditional multiplier that was used on '1 to 0' decrementing by ratio, that being for the first half of decade, '5 down to 1'.  So, the compromise strategy is to find a good multiplier, but that only is accurate enough, to do those decrements.
There isn't a need to have a one size fits all approach, as the whole purpose is to create segmented ranges, each handled the 'best' way.
That means, real numbers '0,1,2,3,4,5' and integers
of '6,7,8,9,10', each to be decremented.  So, since the low range strategy can ignore the high range, that allows for more focus, just on the restricted range.
And note that this is BEFORE considering even more 'ranging', detective or criminologist style deduction, where possible.  One example could be that your high analog value digit, might not get up past '3' or something.  Then, your high digit routine might have some additional 'tweaks' that can be employed, seeing as upper ranges, like '654', or '855' will not happen, or will not be so bad, with a bit more error, in the decrement of real number.

[RJSV]

   The process of 'pealing away' at the analog BUS involves using same width conduits, in this enclosed diagram.  (Sorry, kind of sloppy), the diagram features each 'pull away' conduit, (or sometimes open paths), that is part of the functional ratiometric decimation...that simply means that each pull-away takes off 20%.  If I had used the original method, multiplication, that would require varying the sizing, or conduit width, in an array to array butt together, where conduit walls don't match up.  You see, after the first 80% / 20% split, you would need, for the 2nd. split-off, you would need 10 conduits (again), then do the
80% / 20 % on those...or some other semblance to obtain the ratio for doing ratiometric multiply.
Then, again for the third split-off, again changing scales. (The diagram actually was a bit difficult and took a long time).
But the diagram serves to show how, you can split-off a 20% portion, relatively, and how, with some thought, that split-off can continue by keeping the same 20% relative, this time, relative to the 'top' or signal entry point.  That is because there is an implicit lowering of 'standard' levels, as you trace paths down thru system.
(Of course in this diagram the signals literally flow conventionally, left to right.)
But here, by keeping to the first 'standard' level, the other 3 channels take care of relative amplitudes by splitting off the way it does; that is with EQUAL sizing from the source, by way of using 2 conduits each, for an equal outcome in each split.
It may seem wrong, as there are only 5 signals, but that is a consequence of needing 20% each time, (for the original ratio of X .8 times the total.). The signals turn out to each being 20% but the ratio varies.  Instead, the signals are all relative to the original arriving signal, rather than just an ongoing applied ratio.  In that case, each signal would be a smaller copy, and the conduit walls / widths would change after every split-off.
   Please see diagram, the first BUS conduit split-off is shown, circled, where the packet of light gets moved over, tucked into the first active position (#1), on a new digital BUS being built up.
By doing 5 of these that way, you've then obtained a digital word having 5 states for (later) shift type count-down, classic rightward digital 'bit' shifts.
Seems kind of simple.  What's not intuitive is how that turns out;  that 'only' 5 'ones' are split-off, not ten.  That's really only a consequence of everything relating to the original signal level point (in space, actually), rather than an ongoing 'standard 100%' that changes or gets reduced downstream.
This scheme basically 'sucks' the light quantities off the incoming (analog) BUS, and creating a fresh new DIGITAL copy, of the proper count.

[RJSV]

   So then, somewhere in the middle of doing the 10 analog computations, (the multiply by X 0.8 ) it is possible to drop the less accurate analog pseudo-decrement, and resume count-down in digital form.  That means, of course, the unit weighted digital BUS rather than binary weighted encoding.
Still need to work out the mode switch-over place, probably at number '5', (or near).

   Actually, this variation, of BUS number decrement, is likely replaced by the more esoteric '3 digit' at once method, of decrement, described a while back, and involving the whole '1/10th underflow' continuous.
Starting this just as a (trivial) bit of work not strictly called for, but to obtain info on overall accuracy.

[RJSV]

   Picture showing; The number crunching isn't really bad, but I've had to resort to some amount of floundering,...to get my bearings on that analog and digital 'decrement' (psuedo).
   The digital 'ones' are at count values 10 or above, to have some decent amplitude, for the 'terminus' electronics to read.  Using the counts, of '000 thru 999' or actually thru '0.999', each peel-away needs to contain a digital '1' level that is enough, right now I've started using '010' for each digital bit flag, so a count-down, of numeral '5' involves total of '5 X 10' that will get moved over, into the count-down shifter.  Working backwards from there, it is needed to have '50' as the ending point, for becoming the new WORD for controlling '5' decrements.  That is variable 'j', in the unrolled loop that I've been describing.
   Now, working backwards, into the analog decrement, by way of usual ratiometric multiply, I've figured those first 5 psuedo-decrements do ten (counts) each, of reduction split-off, generally in a range close to 10 counts each (counts being a substitute for analog light amplitude).

   Works out pretty well, as the goal is to work the numbers forward in the process, during the 'loop' downward code stack.  In other words, each step will grab 20 % 'residue 'or as close as can get, and leave the 80% main value to continue down the list.
   That 20% approx. is a bit sloppy, moving down from '20' counts on the first save, to '16', to 12, 10.2, and lastly '8.2' (on the low side).  Figuring 10.0 is close....but lacking explanation.  Some random impulsive changes got things this way...a partially satisfying match...
For a digital threshold, similar to the TTL spec, suggested digital threshold is at '7' counts, with 10 being enough guarantee.

   Weird part was the numerical adjustments to get results.  Number multipliers were '0.8', '0.85', '0.98', and '0.998', with results being the proper amounts in the take-off residue and the numeral amount being in the flow so to speak.  Generally you multiply, to get the ratiometric reduction or decrement, and then, for an example like 'X 0.85', you do a 'X 0.15' as the remainder or 'residue' light.  That's on paper, simulating the numbers as light travels down the 'code stack'.

   For example, I've determined, by working backwards, as mentioned above, that '100' counts of intensity or amplitude are needed to supply the 5 'withdrawals' of ten each, and the count of 50 that is present at the start (of ratiometric decrements).
   Photo shows, using multiplier of '0.8' gets a fairly good compromise, having enough amplitude for each bit flag in the new digital WORD being created.  If take off too much, then errors creep in, and if take off too little, there isn't enough 'light' quantity to do the digital WORD buildup for having '5' digital shifts to do later.

   It seems like a '0.8' multiplier gives good results, for single digits (for doing decrement approximation).
When doing '2' significant digits, you might prefer multiplier like '0.98:, and, it seems, for 3 significant digits, you'd want to use '0.998' as a multiplier.

   All this gets to feeling a bit 'lost' in this attempted adjustment, for least amount of error, simulating a single digit decrement.  But the '0.8' multiplier works pretty good, taking off or splitting off a bit too much amplitude, so that then, the feed over, to new digital WORD will not be 'enough', to supply a valid digital 'ones' level, of 10 or more counts to each new bit flag position.
Those bit flags, by the way, hopefully, can simplify any electronics used, digitally, for translation to usual electronics / computer output.

[RJSV]

   Here, an aside, I've included a back yard garden light assembly, this first picture has a seven sided arrangement.  That middle yard light has a role in regulating the bunch, as it's light will prevent the main assembly from illuminating, until the regulating unit expired (batteries discharged).  The light from the regulator shines on each of the lower 7 little garden lights.
   Fun and lots of scotch tape.

[RJSV]

   This next picture shows a six sided version, where all the yard / garden solar lights are arranged in a six sided wheel, with another outside perimeter of 12 little solar lamps.
   Logically, each lamp performs as an inverter, shutting off when a flashlight shines on the solar lamp, with a switching circuit (that includes a buck DC converter, for the single AA rechargeable battery.
   With a bunch of single lamps, each will go dark, when receiving light, but when there's two, one shining on the next,...; You get a sweep of lamps going dark, briefly, as a flashlight sweeps over.
   That effect helped launch my 'new career', designing Hillbilly SuperComputers.

[RJSV]

   Third picture, has another six pack sitting up top, that tends to suppress the lower level yard lights, as the six sit up on top.  Flashing or sweeping a flashlight can be causing very brief 'flashes' or impulses, as the occasional series acting Gates produce.

[MK14]

I don't know, if you are interested in this.  But it reminds me, of your ongoing computer project ideas and work.

The following video, seems to show that they recently made a new computer (type), out of actual DNA.  It has been constructed to play naughts and crosses (tic-tac-toe).  There are flashes of light (sort of), to indicate the desired moves.

[RJSV]

   The diagram, enclosed, shows, graphically, a region of response, for those flashlight sweeps across (please see the 2 trails, red colored.)
   When sweeping a flashlight, across the assembly, you could move to the edge, with the torch, so your 'pulses' of light response get very short...which is interesting, kind of.  In some past experiments, I had realized that several classic, conventional circuits can be modeled, by the light gates.

   With a random assemblage, of say 20 yard light gates, you can have various flip-flop actions, where led stays on, after one of those flashlight sweeps.  Makes sense as any two inverters can, potentially connect via light paths.  Course, it's mechanically awkward, some, as those garden light packages don't really 'like' to point the led and responsive photocell, at some places...(like pointing at self,...that seems to cause a dim lockup, of a garden device...analog feedback of various sorts via the input sensing photocell.

   What's really interesting, and from a standpoint of Neurological science studies, is that an 'edge detect' function can happen, in that 'random' collection of solar cell 'gates'.  Been covered before, here.

   When a person 'plays',...keep an open mind as there are effects sometimes that have interesting angles.
Backyard art, but with a geometric bent, plus Neurology...wow, nice!

[RJSV]

   Yeah, thanks, MK15, it's the creative process that I'm pumping here, meaning doing those things necessary to foster some novel creation.

   "Very fluid", I'm thinking, watching the video (a couple posts back),  with using DNA to implement / indicate rules of play.  That Steve Mould yt channel also featured a video on water computing (binary gates).
And don't forget, as a semi-employed 'architech', these novel things are gratifying...his and mine.
   If only I could spell.  (I hear it is illegal, to 'claim', falsely, to be an architect...heh heh).
I've tried to do some very loose,  wild-ass gleam in the eye shit...being a former 1970's hippie.  That cultural blip was known for some really creative 'output'.

   Tried 'sliding' the bit formats, tried reading Nuerology texts (for dummies)...  The human audio processing is a marvel, as it truly LACKs any decent speed (> 1 mSec).
   Tried using 'digital' conventional frame, but placed analog values in those boxes (fascinating!).  A big part of the creative environment is knowing yourself, and limits.  For me, better have that notebook near...anything that seems promising (logic gates) needs a quick jot-down, or it's lost in the 'Lyme' brain fog.  Huh ? Whaa ?

   Anyway, thanks for feeding in some ideas, I really would recommend Steve Mould's water computer discussion.  Another basic part, of creativity, in my view, is a real fast and loose approach, but a person needs to, same time, monitor and restrict that flow, some times.  For instance, I've deliberately steered clear of 'Quantum' effects (to harness), but you've got to be 'nimble', if time comes to engage those Pop-fiction, fancy wordy 'entanglement' type phrases.

   My quantized 'signal processor', right now... Is a FLASHLIGHT,  2 rubber bands,  and a bunch (80+) of Solar Yard Lights.  And yes, I bought a whole FLAT, of those little lights, at $ 1.25 each.

Thanks

[RJSV]

   Oh, and on that subject, of fostering creativity,  don't forget the arts, and music world.  Those folks often don't get the higher tech salaries,  but struggle on never less.  Many artists have had to flee, to some modern media involvement, for popular appeal.
   Ever Google 'Biography of ....'?
I found a great autobiography, guitarist BB King wrote;
   'Blues Everywhere'.    (1996).

[RJSV]

   Here is a simulated view of one of those OPTICAL BUS combiners, with a human hair laid across.

   It would be a low-power microscope setting, scaled some 100 microns across the whole picture, with hair at maybe 30 microns.
   That's 100 microns is 1/10th millimeter.

[RJSV]

   Thinking about accumulated errors, going through a small (<11) set of decrements.  I need a math / error estimating person.  (Maybe a statistics expert).
   The decimal system has a max value of  '9', so you could say the 'expansion factor', going from '1' to '9', or to '10' is factor of 'X9' or ten.  That might contribute to the minimum error, in some chained multiply, such as what happens in this 'psuedo' decrement approach.
Then, maybe consider binary, base two, where there isn't even another numeral 'weight';
   Problem there is that any multiply that is substituting for a true integer decrement has an unsatisfactory performance, in the attempt to convert a (real number) of '1' down to '0', or at least very very low result.

   Let's look at three ranges and number BASE's;
   Suppose we run the numbers, on 'BASE 10', (decimal), on 'BASE8' (octal), and on 'BASE 12'.
That's all in the continued context here, of finding the best (compromise) multiplier, across the full range, of a single digit.
   With binary, a 'guess' that any digit is going to be a '1' as a real number is obvious, so you would either do the ratiometric multiply, of 'factor' X '1', being done, or you would actually START with a '0', so any compromise is moot, as you could, actually, multiply any '1' value by any extremely low value, like X '0.1' or X '0.01' etc, just to simulate a conventional decrement.
   Now, that last line is shown as decimals '1/10' and decimal '1/100th' but I meant the equivalent concept in binary (fractions).
   Obviously, you would have include all of the 'partial' underflow mechanisms (already discussed), in order to properly handle any decrement of '0'.  But point is, that you could (attempt) to implement that hairy strategy...

   So there, the question would be if using binary, multiple digits, with all the unusual DECIMAL oriented mechanisms, translated for being able to 'subtract' with appropriate light beam amounts brought over from higher columns.
   
   THEN, I should also do the same process, for octal and for 'BASE' or 'radix' '12, for comparison.
By way of some sort of principal, there HAS to be one of those four, that is with least error, while moving down a chain of decrementing.
    Looking at 'BASE 12' this way, your maximum value is '11X' the minimum ('1').  So each evaluation seeks to produce an error map.  I considered binary because there is NO max,...just a '1', so you could concentrate all your efforts on multiplying that way way down.
That falls apart, though (I think), as not sure if can then 'decrement a 'zero', with all the borrow/underflow mechanisms considered...I mean, why not just BLOCK the whole BUS, then...That will give a 'zero', but leaves the '0 down to 1' underflow.
   'Seat Belt Light is...ON FIRE...'

(Maybe use BASE 3 ??)   Heh Heh.
   Actually, maybe sounding flippant, but that's just the presentation.  The real goal, right now, is to evaluate whether a format switch up to 'base12' or down to 'base 8', will affect the cumulative error(s), when performing multiple (psuedo) decrements.
   Can't believe each (base or radix) has same errors...

[RJSV]

   Or part of what 'I think' I'm saying, is that the decrement of a '1' is the most problematic, as any decent ratiometric operation does not result in zero.
So...going to BINARY, digit by digit, you can maybe simulate a decrement that doesn't have the ratiometric limitation, because there is no other digits, to compromise with, against a multiply times a 'ones' value.  That's attractive, as lacking the need to compromise for other values, above '1'.
But, that means that you could just BLOCK the whole, friggin BUS, to get that 'one' down to a zero...I don't like that, as still need the underflow borrow strategy, for bring a decremented value to 'wrap around', like '0 wraps to a 1', counter-style, like the Ole' 7400 series counters do.