Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

   Some errors to correct, in the approach to decrements:

   (Please see diagram).  That method of partial underflow borrows is cute...but problem is that it brings all the work over, to the high digit, of the 3 digits.
Kind of like passing the buck, ending up with same issues as started, where the separate digits would be isolated from each other, creating smaller ranges, thus smaller errors with ratio derived 'decrements'.

   The green highlighted column shows where the terminus electronics, taking over the end of the BUS lines, would have to interpret that '2.20' and put the partial fractions back where they belong.  That would take up time.
   The yellow highlighted digits, in this version (shown) do that thing of 'virtual add 1' with, also, 'virtual subtract 1'...a bit ridiculous sounding.

Other faults exist, will post notes on a couple points.

[RJSV]

And, OOPS;
   Meant to format that picture as a decrement, of '1' not a full subtract.  But point is, I needed to keep an underflow mechanism, for the two lower digits.
Likely will be forced to use 'partials' still, because of the whole unknown quality or 'blind' calculation(s).

[RJSV]

   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 ).

[RJSV]

   So to be clear,  the partial, '1/10th borrows' are still used, as light for generating new signal(s), to add to the macro-column (ones digit).
   For the actual decrement procedure, that's kept in a 'box', constraining the limits, that being '0 thru 9', maximum '9'.  Those fancy partial carries (borrows), operate on a bigger range, of course being two digits, or laterally across the multiple digits.  The real, whole digit 'borrow' thing extends, so you'd want a '1/100th' borrow, taken from highest digit...every pass thru a comprehensive decrement structure.
   That is because your second digit, in the middle, is also in same situation as the lowest digit.  Might turn out advantageous, to do the multi-digit subtraction (of '1'), backwards, in high to low order.
I'm ready...that's easy when there is no conditional actions in the routine.
   In the 'CODE STACK', implementation is not complex, or bulky...it's the MATH explanation(s) that take up 'bulk'.  They usually don't 'FLY' the engineering dept., In any new airplane...too much bulk and weight.

Math correction diagram enclosed, thanks.
-- Rick-Jack

[RJSV]

   Considering the multiply operation itself, turns out the X0 point8 (X 0., that's basically it, optimized for a '5' that being mid-range of 0 through 9.  To prioritize a little higher, say with '6' being the zero-error point, you could use X 5/6, or effectively X 0 point 8333. 
The meaning of that is, an exact decrement result of 5, from starting at '6'.

   When using (various) ratio splits it is easy to build in that ratio...but a bit more trouble when solving the latter by way of digital multiplication.  With the former factor you can do a simple single digit multiply, with usual permanent structure built, keeping 80% and spitting out 20%.
   But with the latter ratio, you might want
   Factor of 0 point 833,  which calls for a 3 digit multiple digit multiply.

   At any rate it's simplified, in light of discussion on other more accurate factors, (like 0.998).
The misunderstanding was, that a factor like '0.998'
(Zero point 998) is for a three digit number being reduced. 

[RJSV]

   I had mentioned (please see reply 227, above), had mentioned the issues of how accurate is a lateral borrow amount.
   Repeating the context needed, it's a 3 digit number that you wish to decrement, and the tactic is to be doing decrements using decimation by ratio, as discussed.  First focus is on just the lowest digit, and that gives your perfect answer mid-range, at '5' (going to a '4'.). You get same thing, no matter where you've put a decimal point, such as going down to '40' from '50'.
Part of my mistake there, originally, was assuming that going to 100 (counts) gives MORE accuracy...it doesn't and that is simply because the range of compromises is larger.  The larger range (psuedo) decrement IS useful, during each 'partial' borrow.

   Having a range of 2 digits, 00 through 99, you need to maintain that the ideal is at 50, counts.  So there you use X 0.98 which will take that 50 count, down to 49.

   So to be clear, you need the most accurate, single digit ratiometric (multiply), that being X (0 point eight), and then, for the unconditional 'borrow', you are 'stuck' with 2 digits, of accuracy, or said as a count range of 100.
For that, it's less accurate, (using X 0.98).  In that case, (usually when taking a lateral borrow of 1/100th) the ideal is '50' to decrement (to 49) as the ideal center point, for minimum error.  That's going to be less accurate if you are applying it to '20' as the result will be ' 20 X 0.98 = 19.6'.  Whereas a simple X (0 point eight) gives a result of 16.
   When you look at those results as a decrement of '2' the most accurate is the single X (0 point eight),
1.6, VS 1.96...although albeit both are not the correct '1.0' desired.

   Same argument applies with more digits, where, for example, 3 digits of significance, using 500 as ideal point, and multiplier of X '0.998'.

   I've gained some fairly good theory behind some guesses and adjustments that have worked, in the numbers runs.

[RJSV]

...oh and by the way; concerning that multiply operation, for a decrement-like result,  has a repeating 2-digit characteristic.  Meaning that, a multiplier to simulate decrementing '20', for example, differs from a multiplier to simulate decrementing '2', which isn't intuitive!  I would have said that decimal points and zeros are all relative, but apparently not...or I'm not cyphering things, correctly.
   There might be a MATHEMATICS term for this, as similar to the computation of squares, or even of any two numbers (single digits), like '9 X 9' or '8 X 7'.
   At any rate, while it was shown here, that doing pseudo-decrement of a '20' gets more accurate; '19.6', while pseudo-decrement of '2' gets more accurate '1.6' depending on flexible use of the two different multipliers, depending on 'significant' digits.  I barely know the meaning, (lol).
   But the difference is simply calculated, and appears to be periodic in that every odd or every even number of significant digits had this phenomena repeated.

   So, in partial ignorance, I've learned to look...is it '2' or '20'...,  '200', or '2000', because realistically it's different outcome in terms of accuracy
   That's all I want, out of this brief, sojourner into one single microproc. instruction, the integer decrement.

[RJSV]

  A little confused doing post, with included diagram, the instructions say 'drag to include file' which before I just needed to click on file ?

[MK14]

  A little confused doing post, with included diagram, the instructions say 'drag to include file' which before I just needed to click on file ?

Dave (EEVblog), has started a thread, about possible forum software fixes/changes/upgrades and possible new features.  So, I suspect you are noticing one or more of the (possibly temporary) changes.

https://www.eevblog.com/forum/chat/are-there-any-eevblog-server-app-youd-like-to-see-installed/msg4560622/#msg4560622

[RJSV]

   Anyway, that 'Trouble diagram' indicates the trouble or inaccurate areas, vs the single-digit that I wish to decrement.  That being taking 1 down to 0, always a problem, with the multiply.
   But the method mode switch, at count of '4' gets the sliding or bit flag shifting going, so we don't really need the lower half (of decrementing 9 down to 0).

[RJSV]

Thanks MK14,  I have a puppy moaning and whining, whilest I try my patience, but the results are very good, somewhat.
   It's a beautiful and spunky female Terrier!

[RJSV]

(puppy demanding my attention, lol).
   Referring to that (above) error map; it is an absolute value of error, from perfect decrement, but the lower half does not apply, unless you've decided to persist in using the multiply by 6/7, all the way down.

I've included that, only for reference.  I believe the first mode of decrement, 9 down to 4, will end up at 3.61, a little low from the desired perfect ' 4.0' .
For reference to before, it was '4.167' which is actually better match, to perfect decrement result, 9 down to 4.

But that's OK, as I'm learning by stumbling.
   The upper ranges will multiply out to being 'too low', while the lower ranges (although not used in ratio style) turn out 'too high'.  Might be possible to just keep with the style, all the way down to 0. 
   The 'too little' up in higher single digit might be a good compromise, to actually compensate for the lower range (4 down) error of being too much...
(Whew).
   Patience is a virtue !

[RJSV]

   So the principal applied here is to utilize the error of going too little, as compensation for the too much, result of cascaded multiplies.  That's decently 'sound', as the real purpose, of decrementing, is as a 'loop' count, in a typical 'FOR -NEXT' code structure.  So the ending values, of '1' and then a detectable '0' are the best goal.  Second best, is having that index, diminishing to zero, be inhibiting your values, within the loop, or, said differently; causing any function output of the loop to be unchanging, due to the index 'EXPIRATION'.

   Friend of mine (at MDS QANTEL, Hayward, Ca), coined the term binary 'Confuser',...seems appropriate!

A couple words, about the inventor / invention process:
   It can be a need for tolerance, as new stuff does not have the 'framework', necessarily, to get oriented.  So inventors have to tolerate the newness with attendant confusion, as part of the whole deal.
   I guess I'm saying that's the setting, when new ideas come.

A related aside, some yt 'reaction or critic's videos were commenting (on Jimi Hendrix or BB King live performances),  saying; 'He loves it !', meaning love for the work and 'sounds' being created.
That's distinct, from 'conceit',...just a love for the work, and for the results.

   That's going on here,...(never mind the clever genius, behind the curtains).

[RJSV]

  Well, sorry, temporarily, didn't want to waste your time reading, the split decrement thing looks like a dodgy-fail, in the short-term view.
While starting at loop iteration '9', for decrement to zero the other starting points have roadblocks, if use the same structure, as I wanted.

  If you consider starting at '8', (eight), for the integer wanna-be you've got a couple options, none appear to work out, for proper ending, which is a zero, looking something like '0.6'.  That would end up at the electronics stack 'terminus' or A to D sensors.

  Problem in mind, is to avoid too much 'kludge' in the overall decrement situation.  Say, the optical system can be designed to run fast,
at 1 Terraherz, but has a 'KLUDGE FACTOR' making it 8 times more bulky.  That brings the measurable, practical speed closer to
125 giga-hz.  Plus it's more shear bulk and length of BUS runs.
  The literature, circa 2020, mentions optical logic speeds on order of 'Tens of Femto-seconds', but we don't want to squander that, on fool-delusional kludges.  Already resigned to loss of micro-scale...needing some 10 to 40cm (height, when set upright), for the ALU subsystem / accelerator.

  But...the 'BOSS' said check out all seemingly useful options.  Thankfully, my 'employment' situation doesn't depend on immediate success.

  The alternate method, is with having multiple entrance points, done by the conditional capable electronics..., at the end of the data BUS lines.
That's an entrance for '9 going down to 8', for '8 to 7', '6 to 5', etc on down.
  The silicon compiler knows the iteration.  One option is for the 'top' or starting, to load a full bus of ones; Ten ones as a little 'supply' of light to be used when needed, as it is helpful to revert to INCREMENT function, in some situations.
  That way, the actual 'loop count' tracking is done in the silicon 'compile' stage, as avoiding any conditional testing that is difficult without MORE new developments for fast switches.

  The incrementing or tracking of loop iterations can be pretty easy, as various parts of older discussion here have covered.
No

[RJSV]

   So, eventually, the executable 'code' to describe here, will be 50 'lines', produced in the compile stage, with a typical repetition at 2 Ghz.  Previous discussion was focused on '40' lines, but that results in irregular timed outputs.
   Some attention also, on the mechanical package, relating optical refraction index, length of BUS runs, and included elements doing direct manipulation of a 'bulk photon' beam.  I think, tentatively, that the refraction index, 
using 760 nM light, is factor of 4.  So, light waves travel through silicon at 1/4th the vacume speed.

   One of a few major hurdles, is investigating the stacking, of many silicon wafers, with attendant requirements for accurate relative orientation, down through that stack.  Plus, each wafer to wafer bond isn't perfect, but needs to pass the guided light through directed normal to the plane of each wafer.
   That, is helped by the mildly small structures, at 100 microns order, per 'gate' as I've incorrectly termed the passive BUS manipulation structures.

[RJSV]

   That was, 50 'bubbles' at 10 lines each.  Rate estimate is 500 lines per 500 picosecond circulation time.  That's a nice, one line per picosecond or an equivalent to 1 Terraherz.

   For a glimpse of what some running code would perform, a demonstration could include an incrementing iteration count, 0 thru 9, with a multiply operation, say 'iteration count X 14'.

   For that, you've got to take care of incrementing your iteration count, which is then followed, structurally, by the multiply, which is the two sub-functions, of single digit multiply, and with provisions for carry propagation, to next digit.
   This all takes up more (lines of code), than a usual microprocessor, but fast and with potential energy use savings.

One other little regret is the lack of flexibility, for having more of a parameter input, to any loop counts, rather than a hard-coded (structurally coded, actually), loop entrance and number of total iterations.

  Would be nice to keep the kludges private, meaning that one level up, in application, is as standard as possible, software-wise.  Plus, some form of plasticity in the layout would be great!
That means, FPGA style modifications that are done in real-time; creating low-level configurations that run for something like 100 milliseconds, or that run for 1 second, following a 40 millisecond 'reconfigure' operation.

In that, the contents to be impressed, would be the simple operations, like decrement, subtract, multiply, etc.

[RJSV]

   Here is some interesting info, on latest progress:

   'Stumbled' upon a reversed technique that show promise...but a little more complexity.  Actually, doing reversed structures, or reversing an approach...is an existing FORMAL tenent, featured in various literature on creative potential, and how to control or increase it!

   According to the various books, (I've not read), I've heard that by creating a variety of 'options', a person can actually increase the likelihood of a good outcome, whether that be a 'new' type of aluminum or fiber crankshaft for an engine, or for various business models, and lots of other fields of endeavour.

   But my approach recently was 'Stumble, Evaluate', which can work, with luck.  You've got to be pretty darn good at the 'observe / Evaluate'...; to compensate for lack of initial vision.

   I've been blessed with lots of creativity, in heaps, but then not so lucky, in the memory department.  Hence the constant notes / notebooks.  I like to call it imagination,  pressurized and flowing from a fire hose.
With a 'cue', the recent memory can be accessed.

   The passive computing DECREMENT, digital or analog, needed methods to perform 'blindly',...an unavoidable 'pun', I know...lol.   For the decrements, within loops, or un-rolled loop contents, it is needed to set up a computing pass, down through the optical hardware, where there are no CONDITIONALs...at least until switching hardware gets faster
 (50 Femto-seconds !).

   Without a condition test, you've got less options, but one promising way is to outright SKIP doing CONDITIONALs, at least directly.   For example, I want 10 loops, maximum, when doing decimal oriented math.
   Keeping a full 10 loop structure then, is it possible to manipulate your parameters, especially the iteration count, and have the new value cause the 'loop' to extinguish, or go inconsequential ?   YES, that's no so hard!

   But there are burdens to this approach.  I want ten loops, or repeats, traditionally done by way of;
   FOR I = 10 TO 0,.   STEP = -1

   With setting up something like a single digit DECREMENT,  (blindly), of, say, for example, '4',  you've got to get your little subroutine to act four times, and then go to 'extinguished' mode, to ride out the last, empty 6 loops left.
That way, it's the same effect as exiting the loop
after 4 times through.  (I'm only talking about the one parameter, for now).  With other parameters and operations present, in the FOR-NEXT body it gets more complicated, needing an enable / disable mechanism.

   So, now, one way to do that 'extinguish' thing, in a DECREMENT function, is to simply change the psuedo-decrement multiplier, from 8/10ths, to a pure 1.0.
That way you've got function...until a stopping point is reached.
   So, I've reversed the operation, and NOW, topsy turvy as your DATA, (example, digit '6') is semi-permanent, in your optical calculation stack, for now.  It's the multiplier that gets changed, as a defacto enable / disable avenue. 
   Want a X 2 function ?  Then do the ratiometric decimation, twice.  Then 'extinguish' any further change, as your fixed loop cycles the rest of the way, or actually more literally as the downward flow skips out on doing anything, as progress down another 7 bubbles of code, in the ten bubbles of an un-rolled loop.
Sloppy writing, but the implementation isn't major.
   Hold on to your hats...more new stuff coming.

[RJSV]

   Turning the process order backwards, it is easier to keep your original data, unchanged, and progressively alter the multiplier.  That's the same multiplier that we will be, eventually, disabling by way of setting it to One.

   With optimizing for the mid-range of a '5', between 0 and 9, you've got 8/10 (NOTE: emoigies don't like zero point eight...lol).
   Now for a progressive deepening of that number, you simply multiply each new copy by 8/10, creating a series.  Your DATA digit simply stays the same, in each iteration, while it's the multiplier that progresses down.

   For example, I've calculated that, for a function of
   '6 -3', you're needing a multiplier of 0.328.

Initially looks way off, with a result of '1.91' using 3 significant digits, low from the perfect result being
a '3' (from '6-3').  But...in this game that's better than a shrug.  Pretty wide, at error of '- 1.09' but it is what it is,
everything being optimized in blind 'One Size Fits all'.

Ya got your SPEED, tho.
   Seriously, though, the formerly described altering of the multiplier, making it a '1' for avoiding change, breaks down, as an idea.  That is because concepts, (so far) can't include having BOTH parameters in any multiply be 'fluid', or copies off the BUS...One of the inputs to a passive optical multiply must supply MASK information, under electronic management.

   So, in an initialize / set-up session, preceding the 50 bubbles (at 10 lines each), the electronics must go around, setting up a few of those DATA words, and preferably be able to get some efficiency, time-wise.

   The electronic session time will likely be much longer than the optical pass, with the whole timing picture being a long long setup and then, Zip...done and starting on another preparatory pass.

   Complicated, but not really excessively, compared to modern wafer FAB technology. 
The possibility of gradual upgrades, using ultra high speed switches seems compatable with the techniques (/kludges).

This optical logic field is fascinating, if nothing else !

- - Rick B.

[RJSV]

Mistake correction:
   Going from 6 down, with the updated methodology gives subtraction result of '3.07', much more satisfactory, than the previous '191' quoted.

   The corrected error estimate goes to '+ 0.07 ',.
where previous statement said error was '- 1.09'.

   This updated method can use the (unchanging) list of values, each is 8X the previous value, so the chain of calculations does not aquire errors, so fast.  Remember, any single digit number has to be using the best-fit, for least error over the range (0 thru 9).
   But looks like can avoid a chain of the very rough accuracy multiplies, and just go straight to the value at hand.
   So for the third decrement, from '6' starting, to compute '6 - 3', it's just the one multiply, (supplied by the programmer).  Multiplying by X 0.512 for the third decrement, gives that '3.07' result.

   Please don't expect perfect accuracy when
doing '5 - 3' as that STILL is throwing around compromised numbers, based on '5 - 1 = 4' being the only really accurate inflection point, in the imperfect curve of multiply errors.
 
   Much better error figure for the '6 - 3', that being off by '+ 0.07'...(that's easier to defend..., as per my last posts, on error est.).
Thanks
That comes out as '5 X 8/10' = 4

[RJSV]

   Current consideration, for an optical, or all-optical microphone, mostly here as a demonstration item, for some signal processing orientation.

   Included picture depicts a light-splitting wedge, currently deflecting leftwards.  The (hypothetical) air sound wave sensitive diaphragm, typical 1880's physics, will, back and forth, produce alternate beams, into the outlet conduits.
Separators as the conduits keep things separate, for further distinct processing, if needed.
Bottom graph showing how there really isn't a practical, direct physical 'negative'.  So simple choice was made, as to which, arbitrary side of the microphone is '+' light, or '-' (minus).

[RJSV]

   An older format might lend a useful match,
called ' Bi-Quinary'...or something, (1930's).
   In the Bi-Quinary' number, you've got 5 states, with a sixth 'bit' for range; that being high/low.
If you noticed, that last picture featured the microphone amplitude (displacement caused), where the actual light beam amplitude goes 'positive' on either audio cycle,...a bit of a natural rectifier.

   Suggestion would be, perhaps the (microphone) signal could be similar, having 5 states, of weighted amplitude, (meaning no '0'); then having 1 flag, for range and 1 flag for polarity, (+ or -).

That whole format, isn't base 5, it's really a similar.

[RJSV]

   Picture shows a conventional digital counter, waveforms output as decimal count-down and consequent under-flow or borrow.
One point is, that underflow 'carry' action moves, ripple style, from low to high, and the timing, precisely, has small glitches.  That's simply due to the physical delay in updates, so, for example, (see diagram), a
 decimal '40' being decremented, as two digits:
  Briefly, you might have '49', there, as the normal update of the '4X', high digit, to '3X'.  Then, of course, you've got a readable little string of two.

[RJSV]

   The next photo, shows the '1/10 th' borrow scheme, happens every cycle.

[RJSV]

   Now, I haven't shown it yet, but there is a complicated response, trying to do the blind decrement, as unconditional functions ...

   Somewhat resembling cardiac 'fibrilation' or 'spazz' like small twitches.  The 'count', so-called, in optical terms, just sits there, seemingly, near some value...in this example a '2' .  You first get that unconditional borrow, fragment,...thrown into the small digit BUS.
Then, a 'standard' ratiometric decrement just takes it away again (that newly added '1').
Whew, and as if that wasn't enough; each of those operations, quite simply constructed by the way, but each structure / approximation and possible compromises in the math introduces enough raw error to cause that seemingly constant 2 to 3 shifts, could drift slowly, up and down...

   In overview, seems like the lower digit just 'spazzes', uselessly, while the upper digit does the work of both, in terms of handling count of 0 thru 99.

[RJSV]

   In spite of obvious flaws; bad looks & horrible smell, the multiplication stack seems feasible, if, albeit, dicey...extremely dicey...

   An arbitrary (for now) digital or discrete level of
 '1 count' on the low digit is the analog threshold, between a digital 'one' or digital 'zero'.
Like in a card game, the entering value is not known,...just that the double digit (decimal) INDEX is somewhere similar to two separate integers, each being 0 through 9.

   A 'LEAKY' style of integer to integer 'borrow' would, in a water computer analogy, would release the time-to-time 'full' borrow (was every 10 times), as instead a continuous leak, of equivalent volume
   In this case, given the (conventional) 10X relation between the two decimal macro-columns, a continuous 'borrow' of 1/10th count from the high digit translates to a perfect, single unit count,