Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

(continued)
...translates to a single unit count, added to the low digit...at least in theory.

   In the longer term, bulk tracking is the same, that being cumulatively taking off a single unit 'borrow' from high digit, with attendant 'plus ten' action, into the one's macro column...all happening at rate of once every ten decrements.
   The aspect that does show promise, is that each of the starting index values can be brought to 'end', in appropriate number of 'loops' or passes.  That is, for example, the maximum starting at nine, will have 9 passes through, before 'extinguished' by way of going to digital 'zero' state.  Same idea with example '5' starting index; You get 5 loops or passes, then index is 'extinguished' to digital or discrete 'ZERO'.
   All of this, importantly, is done 'blindly' or without conditional (instructions).

[RJSV]

Attached picture of stack of multiplies.

[RJSV]

Going down through that stack of multiplies (please see previous picture), each entrance value, as 9 down to 1 input variation, each starting value will last an additional step downward, according to value.
A starting value, of '5', will make it through 5 iterations, or loops, in the unrolled scheme.
   Of course, each number starting value still will go through a same process, ten loops, regardless.  That took a little testing and trial runs, to determine the running values to use:
  First set of three is; 'X.6, X.7, X.7'
and next is;             'X.7, X.8, X.8'
and, lastly;.           'X.8, X.9, X.9'

[RJSV]

Looking at the immediate nature, of each loop or iteration, first up is decision(s) for the shortest effective run, that being starting at '1'...(ignoring 0, for a second, here, lol).
That start, at count of '1', has no hope, of ever really getting to 'zero', using RATIO reductions, and benefit can be had, by judging any value less than '1.0' to be an effective discrete '0'.

   In a way, having that impossible goal, at data=1, (goal of reaching a 'usable' zero), helps free up attention, on the OTHER 8 compromises needed.
Next up, an arriving '2' digit, for a decrement; That calls for, ideally, a multiplier of 1/2,...in order to simulate the decrement from '2' to '1'.  But that multiplier is too extreme.  Turns out, the good multipliers are X.6, for the first iteration, and then 'X.7' works for the next three iterations, in the 'loop' of ten.
Main basis for this restraint, comes from the upper ranges values (starting at 9, 8, or at 7).  With those starts, they get decimated too fast, to be able to recover, by way of using multipliers that are too big.
It all becomes a ' number fudging ' exercise.
   Starting at '9', for example, even with semi-reserved multiplier kept too high, at X.6, the '9' goes next down to '5.4'...when perfect is = 9-1 = 8 (eight).
The saving grace, there, is that your '9' isn't finishing, quite yet, and so you have some more time, to 'number fudge' compensate, for previous 'fudgein' the multiplier.
Result is a decrement 'process', ending decently well, but not even close to a linear walk-down, in equal steps.
   In that way, the method starts to need larger multipliers, at the very end, or last 3 steps or so.
But, looking back at previous example, starting with low value of '2' to decrement, those values, already vanishingly small, or below the threshold of '1.0', those values just get, also, multiplied by the slightly larger 'X.9' with no consequence.
It's the earlier values, in the multiplier stack, that affect all decrement starts (that being 9 down to 1).

   While this present discussion is somewhat discontinuous, with recent 'partial borrow' concepts,...it at least has a semi-coherent function, consistent from start (9) to finish (0).

[RJSV]

   To restate things, just to be 'tidy'; in the coding for typical For-Next repeating structures, it's like the card game where, watching the action, you can begin to deduce, and react, to the probable outcomes.  With a '9' input, for example, you'd know that there is time, still, even after a 'move' or two, to handle more immediately possible entrance and exit.  A value of 'two' going in, is needing a quick, or brief consideration, as that index (initial value) finishes in two passes.  The '9' value has about 7 more places, allowing compensating multipliers to be employed, with more immediacy as process gets near to nine (indexes or loop indexes).

   For efficient time use, I've wanted to extend loops, beyond the low word value having ten iterations.  That is, better time efficiency is had by using more loops, into the high or second word, in the Optical data BUS format.  Say, something like 40 loops, total, using a low and a high decimal digit.
   Otherwise, you would end up doing 10 loops, very fast (optical speeds), but the rest of the code should be tailored to allow more (iterations).  The electronics can have some of the analog conversion simplified, assuming a  COMPARATOR type (flash) operation could resolve the analog light beam intensity or amplitude, skipping the full AtoD requirement.
That digital threshold might be '0.xD', where 'D' is one count or greater...roughly equiv to be at 10 mV or greater, (that being more correctly stated in LUMENS).

   First time through, you would need 10 iterations, to assure that the smaller index gets decremented all the way down (to zero).  After that, the repeating small, or low decimal digit will be going down through each count, explicitly, and by shifting the WORD.  That ending situation can do the decreasing iteration count in a more sensible (and simpler) manner.
So, for example, doing an extended number of loops, say 22, you would get the first 2 done, ratiometrically, and then following that you could decrement the two decades of the high digit, as the low digit counts down, with an overflow every ten times.  That you would know, explicitly, in the compiler stage, exactly where things sit (current full two-digit iteration count).

[RJSV]

End of Year (almost), better grab your hats, folks.
   Hyper- Partitions (that means any and everything gets its own defined path conduit.)
Changing the multiplication for using individual 'shutters', having ten of those LCD or similar, on each bit flag, or column.
(Please also see diagram).  The stretched out linear version is best for illustrations, but a more compact form uses a 4 by 3 grouping; fitting all ten signals around the perimeter basically. That leaves two extra signal places, in the middle.

  On the rt. side, the multiplication filter is shown, magnified, as there is one of those, per each of the data BUS integer identified columns.

[RJSV]

   You might have noticed, in previous diagram, the mask (shown on right side) is based on tenths, as in 8/10ths.  This has been a vexing topic, as the weights, of light beam intensities, are from 1, up to 9, max.

[RJSV]

(previous diagram).
   In multiplication by ratio it's done in ratios of 1/10th up through 9/10ths...so there is no '10/10ths' mask filter or light 'valve', as that's just unity (transmission).

   Now, when transmitting data words, the form can include an active 'zero' in that defined column, but of course having no weight value (or zero weight).  At any rate, most devices need a definitive clock or other sync when the data has no 'there' there.

[RJSV]

   One of the advantages of doing this more 'nuanced' multiply action, acting on each individual signal, is that there is then no need for any light diffusing or averaging pathway(s) or lens, as all action is already element by element, kept in separate conduits.

   Viewing the last illustration, showing how a couple of paths have been kept separate, in example '8' with a data signal '4', where the two numbers are to be combined (summed together).  If that partial SUM (of 8+4=12) had been completed, then any subsequent decrement could not be easily done, as the '12' is somewhat out of range.  As per the recent discussion, the optical processing actions do not have explicit conditional testing, so it is important to keep estimates within range boundaries.
By doing (any) required decrement on just one, of the two partial terms, a more typical in-range decrement can be done. (And, WHEW,...that process is bad enough, in-range, lol.)

   A very similar situation for multiply, of partial elements from some previous outcome can apply, using simple math of multiply commutation, doing partial multiplies on each term.  Partial results can be combined (summed), now, or can be kept separated if another later process needs.

[RJSV]

   Assuming the 'stack' of ratios works out, compromising between single decimal digit loop counts, the interplay between indefinite or unknown iteration counts has been explored, and tentatively looks workable.
   After the one pass down through, the ten values of loop, the process should be aligned, in terms of each small data word (decimal).  After this, it is valid to assume we are at a 'rollover' or zero to nine underflow point, and can perform a definitive decrement, of the high digit, with attendant carry (actually borrow), over to lower digit.
   The compiler knows, now, where things are, in terms of count-down PHASE, and will typically have two decades worth of count-down to perform.
So, with an example incoming index value of '22' for example, the result is a somewhat raw, decrement process, blindly, counting down the low digit, '2', but within ten actual runs, and then, a more definitive and digital count-down does the decrements of the teaming twenty...in two sets of more conventional decrements, (using digital shift-right functions to decrement).
   Hopefully, the electronics pick-up, at bottom of big loop sweep, will have many tasks simplified.
But, it helps a lot to be able to go beyond just a single loop pass, at ten iterations.
Doing 25 'bubbles' of functional code, at 20 lines each, repeats the big loop sweep, at 2 Ghz, or equiv. time period of 1 pico-seconds per line executed.

[RJSV]

(So much innovation going on...sometimes can't keep track!)
   Picture showing the organization / format suggestions, having a basic, two-digit decimal count of 0 thru 99, representing analog values for light beam intensity (actually; LUMENs).
   'Ghosting' is a reference to placing another digit, being 10X higher, or smaller by same, decade ratio.
So, obviously an increment overflow, or carry, would represent attention put into the next, adjacent digit.
So, while it was, initially, a functional involvement with 'another' discreet digit, it rapidly became clear, to maintain a package, identified as such and such (register), and keeping those 'ghosted' or extra ranges intact, rather than depositing into a 'HIGH' digit register.  This way, a similar functional control is kept, as before, where digits, of unknown value can be processed, but must be kept 'in range'.
   So, both the 'high' identified digit, and the 'low' digit, have overlapping realms; the 'high' digit having a 'low' shadow or ghost, while, similarly, the 'low' digit having a 'high' digit or word, in same (macro) column as the regular 'high' digit.
   And, (holding on to your hats, right?), that's only the half of it...both of those 'counts' holding registers also have potentially, 'ghosting' digits, on the other side, upper and lower.  The whole mess maps into a basic 4 digit range.
The choice of analog limits is somewhat arbitrary, actually better expressed in Lumens, ultimately.  But the basic scale, is from 1/10th up to 1.0, with the lower of the two (main) digits representing 10 mVolts, (if it were appropriate to even use volts).  But the 10 mV conveys about the right amount, being precise, but not too low, as it gets down near 1 mV or lower.
   The 'digital' ones and zeros threshold is at count of ten, or 0.01, in this number system.  (That's columns are, going to rt. from decimal place, the 'hundreds', then 'tens', then 'ones' column.)

   None of this, so naive as to think to be 'linear'...probably far from it, by the time sensor nonlinearities etc. get factored in.

[RJSV]

Various two-digit 'ghosting' formats;

[RJSV]

Sorry, forgot to mention:
   A valuable aspect, of having the decimal format, with conventional powers; Ones, Tens, Hundreds, as macro-columns, is that an effective multiply, by ten, can be had, simply by dropping your signal into another column.  So, for example, a ratiometric multiply, by 0.5 can be resolved to an answer as X5 to compensate for the reduction effect.
   Each of the 3 macro-columns uses the same (voltage), 0.1 thru 0.9, but since each column is 10X the next, in standard DECIMAL writing formats, you've got powers of ten multiplication, instantly available (to use at light speed delays).

   Sometimes that's not strictly correct, as some setups have a high and low digit complementary, where the low digit physical values match the math...that is, the two digits, high and low, can be simply directly added together, to resolve the full analog value.
In other cases, here, you must first attenuate the low digit, (by 10X), when intending to sum into a whole, coherent sum, for analog output.

[RJSV]

   Now, many of the conventional appearing features, such as digital bit shifting, I've skipped over, temporarily, while describing some of the more 'unintuitive' matters, here.  But those conventional operations lie at the heart of digital CPU and ALU elements.
   One example, using bit shifts, locates a bit flag, location 5, in the word line-up.  Then, later, a blindly acting routine or function can shifts that flag to the right, towards the margins, and headed to the Zero flag location.  This way, as you've been doing decrements, you get your ZERO FLAG, positively asserted, and just coordinated with the data word, itself, going to zero (or count word, whatever).
To do that, of course, you would need to define a word for doing that shifting in.  In other cases, you might need that 'flag' to be negative logic going, placing a zero for doing a logical 'borrow', in some cases.
That zero would be shifted rightward, the proper number of times, to end up as needed.
   Of course, the simple shift right, assuming packed format, will reduce the (digital) word value by one integer count.  In the example, Word data=5, you would start out with five ones, in the right side columns, with the 'ones' values being a '1' in the so-called 'LOW' digit.
As far as representative counts, that would be '0.01' as the one or digital 'ON' resolution.

   In some cases, a more special 'shift right' can be employed, where the packets of light (beam) are shifted and 'packed' but kept as an accumulation, into the lowest value column (col. 1).  Eventually, after all the word shifts have played out, you would have all the light (amplitude), of '4' total, sitting in column one.
That's a bit strange, at first, but purpose is for when the amplitude values are 'sagging'...  By using a process resembling a 'pump', some of the analog values, in columns, can be combined, to obtain more functionality, digitally.  For example, ten columns, each with 0.2 value, can be 'pumped' together to create two columns, each with a valid digital 'one', or logical 'ON'.

[RJSV]

   More explanation, on how that stack of multipliers is designed, (pls see diagram).  As indicated, using a '4' as an example target (for ratiometric decrement function).  The goal in every case (1 thru 9) is to get as large a bracket, as possible, around the GO / NO GO decision point, which is set at '1.0'.
In the example, starting with iteration count of '4', the count down makes it down to a '1.3', close by (+.3), and with calculated next as '0.91'...a close clearly under the '1.0' criteria, for determining 'expiration' or effective termination.  After this point, you want the loop to be 'dead', but, like in the old cowboy / zombie movies, it just don't know it (loop keeps going, until all ten have executed).
The hope is...that any electronics interpreting this can use simple level comparators, to distinguish between, in this case, between a '1.3', (active), and an
index '0.91', as inactive determination.  Obviously the task involves keeping enough clearance so that various errors do not make the comparator's job unreliable.
But (flash) comparators do help with speed and for reduction of complexity (of the electronics that reinterpret various states that the optical pass computed.

   That stack of multiply values has to be constructed BACKWARDS, meaning that the order of the cluster of ten multiplies must accept the lowest input value, a '2', so that the value can be reduced, (drastically, like with factor of 1/2, or 0.5).  That low '2' value coming in must get reduced, fast, in only two steps (iterations down).
   Similar but opposite effect, on the maximum input value, of iteration = 9.  We would like that stack of multipliers to be somewhat higher value; that way an input '9' can sustain it's presence, through all ten multiply stages.  Finally, at the end, at the tenth iteration, that last multiplier is set at X0.5 which makes for a definite level (below 1.0 amplitude) that gets to the comparator hardware.
   Some earlier attempts, (seen previous posts), used  multipliers of '0.9' towards the end of the line-up, but that choice led to some very close bracketing, of the GO / NO GO comparator levels, to an impractical degree.

[RJSV]

This current enclosed diagram helps to further bring point home; that the fit, between stack of multipliers and stack of indexes, is backwards.  The older diagram features a lower value starting, with decent step sizing, and then transitions (upwards), towards saturating values up around 0.9 or so.  That 0.9 multiplier value creates a situation with very small step sizes, and a resulting value that 'lingers', near the 1.0 decision point when the desired outcome is to have LARGE steps at the end, for a definitive judge, of that special '1.0' threshold.  Anything between 0 and 0.99 is considered as 'zero' amplitude.

[RJSV]

   Current enclosed diagram shows the overall strategy, starting with unknown '42' starting value, and with that lower digit, '2' being decremented, to zero.  Then, as the counting 'phase', of underflow or '0' to '9' is now known, the high digit, '4X' (also unknown) is decremented, once per decade, while the explicit shifter, operates on the low (explicit shifter) digit.
   The simplified result is that we have done '22' iterations, or 'loops', thus leaving the ending at '20'.  Point being that we don't have to stop at ten (loops or iterations).

[RJSV]

   A good time to mention the inventor gig thing;
   Invention, as a life's trade or occupation can be daunting.  When independent, the PAYout comes...but first requirement is success.  Most jobs pay according to attendance, initially (plus it helps to have a good CV).
   The silly little picture, enclosed, is meant to convey the feeling, struggling with this and that.  Problem with computing architecture is the width or bulky of complexity, and these passive optical computational elements present many problems simultaneously.
   So the approach in this environment requires lots of, maybe call it 'patience', as the diagram shows nine different aspects, simply shown as 'A B C D E F, G H I'
with varying levels of (concept) completion.
   You've got to have 'G, H and I' (elements) defined pretty good, before you can begin to schech the 'A, B' portions, at the beginning of that list.
But, as the dilemma goes, you have an obstacle when trying to focus down, to describe the new stuff, in 'A' and in 'B' items, as there can be a lot of dependency on how the 'G, H, and I' items look and operate.
   This goes to the heart of what could be termed as 'Innovator's Burden', especially when item functions are schetchy, and almost guaranteed...to fail!
But, that's the conditions; PAY comes, maybe later, success with the new device...maybe.
   Plus, meanwhile, friends (and troublesome relatives, lol),  get increasingly anxious, uttering comments like:
   "DUDE, you better go down, get an actual JOB, then!"

Inventor's Burden, I've liked to call that.  No clear path ahead, and that dynamic has to be acceptable, somehow.  I've encountered (former) independents, who vowed, to NEVER AGAIN engage in Patents or Copyrights related (independents) work.
   
   I've even, in office setting, been extorted, for 'hush money', from some questionable characters, events that wear proudly, like some old wartime battle scars / medal of honor.  I mean; How many folks, out there doing 'regular' office job type work, can make the claim, of being an almost-victim, of a cheap extortion attempt (from some amateur homeless bike-riding meth-head).

   Anyway, all drama aside, the independents, not just inventors, but the independent people doing jobs writing computer code, have something in common, and that's the more volitile and future uncertain aspect, of 'the play'.  It takes a certain kind of tolerance, not just for crappy conditions, today, but for the future and the future commercial prospects.

[RJSV]

   In that last post; sorry, forgot to mention, in that item list, for documenting new innovation / invention, forgot to say that, having some misc. novel items to describe, say 'A, B, C', but needing other items ('G, H, I'), to already be detailed, in order to fit into describing item 'C'.  However, that can be similar in reverse...that is, you might also need a near-finished detailed description, of 'A, B, & C', in order to complete the details, on 'G, H, & I', a cross-blocked scenario that gets resolved only by means of more gradual, and less nuanced steps, of design.

   In the current diagram, I've shown another sub-topic details, for the ability to use conventional rightward shifting, of optical signal BUS 'lanes' or beam conduits.
Idea is for a 'calling' routine, to enter with having an index, for counting loops, or for simple in-line iterations
but where only passive functions can occur, without conditional testing, generally of index going to zero value.
(Pls also see diagram enclosed), showing a '5' upon entry, to be decremented in steps, down to zero.
After 4 rightward 'bit flag' shifts you've gotten ALL of the light beam's amplitude, (that's '5', total), into the final, or 'bit flag 0' position.
   But problem is, that digital WORD must be shifted rightward, every time, unconditionally, as long as loop is active (or in-line code, for case of un-rolled or explicitly separate loop contents.)
That would be able, of course, to activate a digital '1' into the carry / borrow flag, (off to the right of data word), but index decrement ending will need to set that carry bit flag only, exclusively, upon ending, the index count, (not on every iteration).
   By including a second register, it is possible to get that carry / borrow flag shifting also, and in-sync with the main word being decremented.  So you've then gotten a conditional flag, upon completion (index = 0), which, in this example, is a digital 'one', but also, the option exists to use a negative logic flag, having that be shifted over to create your terminating flag...this time as a digital 'zero' getting shifted into the carry / borrow signal path or conduit.
Actually, an inverter-like negative logic signal like that is a very valuable feature, on occasion, especially when operating the logic without explicit inverter functions.

   You might note that in diagram I've also featured having an accumulation, of beam amplitude, into the very first column (labeled signal 0).  That's a helpful option, but not necessary for getting the 'loop' iteration ending, in status flag form.

It might be helpful to note; either decrement type and format looks workable...although the 'analog' indexes don't resolve straight down to INTEGER results, like this shifting of digital integer values does.

[RJSV]

   Two months spent, on the DECREMENT functionality, with various good results, although still some left on that list of tasks to check out, (including a test of
 Base 8, or octal performance.)
   Likely a good time to shift focus, onto the issues and tools needed, for robust SUBTRACTION, including typical multi-digits.

   While a complete decrement by decrement would be foolhardy, that's not so bad when doing subtraction digit by digit.  Try, for example;
   325 - 117 = 208
Each column would need up to 9 individual decrement paring; that is, to do '3-1', in third column, you would decrement both numbers, and repeat, until the top number 'exhausts' the lower, leaving a '2' as the positive result in this case.
Next, column 2, and this time a single decrement gets the subtraction finished, leaving a positive '1' remaining.  The lowest column, in that three digit process, however, involves '5 - 7' and so goes negative, to a '-2' result.
   Then, by way of data BUS rearrangement, of terms, you've got the chance to correct, partially at least, by way of TRANSLATING a single signal '2' formatted, into translated value of '8', and where the WORD format is the type using a single column weighted signal, exclusive, per number value...That means that
column (ID) 2, containing a single bit flag, can easily be translated over, in terms of conduit run, or simple path translation.
   For a translation in that example, the signal in
column 2, gets moved to the '8' identified column.  For my SUBTRACTION scheme, that translation is a simple
   '10 minus X' as a complement value, essentially tossing the BUS over backwards, left to right, into order of right to left.
Number '5' stays same, as complement by way of '10-5'
being unchanged, but 4 becomes a 6, and a 3 becomes a 7, etc.

   That helps define the lower digit process; also needed will be the subtraction borrow or underflow alteration, of the high digit, to complete a '3 digit' subtraction properly.
   Worst case, the 3 digits by 3 digits subtraction would involve 9 decrements per column, or 27 decrements, (but at very high speed, avoiding any conditional instructions).

[RJSV]

   One way to sync up your upper or high digit is to use a bias.  In this case, a decrement happens, unconditionally, on the high digit, but usually preceded by a 'plus one'.  But that's not always, as a reverse logic gets shifted, to make each of those 'ones'.

   Please refer to diagram, enclosed.  In the middle WORD shown, a '6', you can see a 'one' is being put back...Much of this, today is embarrassingly naive and cartoony.
But at least, figuring a loss or leakage at 10 %, with 90% left, each time, can be strung along maybe 7 or 8 times, before losses get out of hand.
   Much like stuffing worms back into can!

[RJSV]

Second diagram shows a 'zero' in the left shift.

[RJSV]

Diagram

[RJSV]

In that last diagram, shows the two different formats, with the more explicit integer shifts in the left.
With analog style decrement, the '6' decrements down to '4.8', a value that at least is close to '5'.

   The analog operations, on the right, use diffuse signals, across all ten paths.

[RJSV]

   An effect, called 'Functional Overplay' comes apparent with the various decimal word length, that being ten signals in width.  A kind of a tedium, although not that of immediate labor, but of the repetitious and often useless burden, of those last, few digital partitions, past about (count of) six.
   Especially evident, in some routines, and functions that are forced to cycle through extended variations, that often are too far out from reasonable bounds.
So, a slightly smaller number, or radix, base of base 8 might have better results, when estimates having to use a one size fits all parameter, like 0.8 multiplier for subtraction estimates.

   When applying a signal degrading or decay, at 90% / 10%, the terms obtained look good, until about the 7th time, then the values seem to linger, at around 40 %, without clearly changing like it did at first.
   Looking the other way, at required increase, for any digital 'one' threshold levels, going at multiple of 1.25, or up by 1/4 each step, that number outcome range is up, reasonably, by about 5X, by the time you've increased (X1.25) in about 7 steps.
Point is, that by going to base 8, the cumulative error can be kept down, by using shorter lists, according to word size.  Please see also, reply #252, having a list of 9 multipliers, for using usual base ten.