Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

Hi there:
   Continued from previous thread, on using Solar Yard Lights, for investigating various switched networks, without interconnecting wires.
   Having some difficulties, getting (proper) experiment settings, and especially, focus on 'edge trigger' logic.  The gist of this is, a solar light contains a (digital) switch, for only operating at night, by using the very same little solar 'panel' as a light sensor.  So, in digital terms, you have a means for 'mixing' various inputs, that are then combined into a totalized 'analog' input, for the level check.  If threshold is exceeded, that means the solar light is now in substantial (ambient) light and will shut off the LED output.
That is basically a 'logical NOR' gate, obviously also useful for 'And gate' functions, equivalent.
  An interesting aside to this; the little yard lights can be operated / switched, by application of two signal 'inputs', optically, where each input is (barely) above
50 %. There things, roughly speaking, can start to resemble neurons, where various input synapses bring analog coded signals for combination.  Of course, there isn't any 'negative' polarity of light, in same sense as electric, plus and minus, but the meanings can still be carried: Most signals, into the solar light, are 'inhibitory' anyway, and inverted logic can conveyed, this time by presence, or lack of presence (of any light).
But in general the inhibitory and actuating aspects can both be expressed, in collections of yard lights, into various relation structures, (like a simple 2-state flip-flop).
   Picture shows, a causally built 'Optical Bench', having top with many mounting holes, for putting gates (yard lights) individually related.  Underneath, is provided various battery packs and solder less proto boards.
A LED blinker provides a light source, for some testing.

[RJSV]

In this enclosed photo, I'm showing the difficult process, of obtaining a decent 'EDGE TRIGGER' on the light beam, from a first 'gate' and to the left, is seen a second gate, meant to be an inverter, in a classic edge detecting circuit (although here it is optical, not electric).  Problem was, mainly with various light levels, in that little, 3 component circuit.  For solving that, edge detector circuit, it was necessary to separate the solar panel (optical input), from the direction the output LED is pointing.  This way, the third gate, will get the full LED output, even while that 2nd gate is no longer inline...the output direction has been manipulated, just do that mechanical alignments are correct (for transfer of enough light to cause switching).
   If all that works, should be able to reproduce those very short pulses of light output, that I've already verified, (but on more 'shakey' informal experiments.)
The classic principal is simple: A delay through an inverter causes a short 'AND' condition to be satisfied, so an electrical pulse output happens. Then, as the inverter catches up, in matter of nanoseconds, the AND gate output goes 'false'.

[RJSV]

This photo showing the transient light (gate on the left) is off, in this view.

[RJSV]

(this view) shows the transient light gate inverter, with LED output ON.

[RJSV]

This current photo shows a kind of dual-nature, in the sense that, in upper, first example it's all digital, gate to gate, while second example, (lower in photo), shows two inputs, reaching the 100% threshold by combined intensity of light input. 
   So can have either, it really depends on context of use, whether you are getting a 'NOR', (with equiv AND, of 'not' inputs), or you are getting a 'NAND', style, where both inputs are needed, to get a logical output (zero).
It's a bit muddied, by the mixing of analog terminology, for inputs, unusual, with typical digital resolved output.

   For more 'context' illustration, a good example can be a design, for an optically sequenced A to D converter, acting to monitor ambient light levels.
By running a 'calibrated' light source into a gate, for comparison with ambient levels, it can be determined when the threshold is crossed, of a TOTAL light input.
So, let's assume today's light is at '30 %' ...an arbitrary number.  Then, by essentially adding in a D to A generated 'light' signal, the 100 % threshold is crossed when your D to A output climbs up to 70%. Thus you get a reversed or inverted answer result that can easily be inverted, to the correct result, of 30%.
The method is classic A to D by creating a source, via a D to A, for comparison.  Either a ramp style, (slow), or a successive approximation style can be used, in the A to D scheme.
   For the OPTICAL A to D subsystem, each of 4 bits are  (individually) raised, then tested, against AMBIENT, and subsequently canceled, if the trial (light level) went too high. That happens 4 times, for each bit (weight).
At the end, you have a 4 bit result, inverted, but it's an analog measure, of ambient light level.
The sequencer and test logic involves some thing on the order of 40 to 50 of those little yard lights.  Makes for interesting and intriguing exploration of digital analog, and neurological concepts, for sure!

[RJSV]

The key to doing the A to D converter is to build a SEQUENCER, as a simple state machine, having a 'test' function, (for analog comparator), where there are 6 simple steps:
   First, everything is cleared, reset, (at step #1).  Then, step #2, will set bit D3, that's the most significant analog value.  For the (optical) comparator, the bit D3 being ON will give the most light, and so is placed closest, to comparing gate.
A 'canceling' step then determines if that (bit3) made an overflow, if so then bit3 is turned back off.
This repeats, for the remaining bits, D2, D1, and D0,
and taking up 2 sequencer steps per bit, 10 steps total, at which time the sequencer sets a status bit 'Conversion Complete', and stops.  Of course, that 'optical' binary encoded result is inverted, but is available, as a 4-bit set of 'light beams', ...(for use in subsequent circuits).

[RJSV]

...Keep in mind, those 'analog' values are somewhat static, built in by way of input 'weights', where the actual (sourced) original signals are digital.  That attenuation is a bit 'casual'; often done by way of adjusting the distance between sender / receiver.
Also, possible to use partial blocks, for obtaining a set percentage of original, by the time it reaches the 'solar cell' receptor.
   A more fluid example, of analog 'input' light levels, is where the actual electronics portion is modified, such as placing attenuation controls, etc (but can't be PWM control, must be static DC driving the LED intensity).
   But that's THE TELL, in a regular nervous system, some of the 'analog' encoding is hard/ permanent in the synapse structure. I'm not pretending to know, much, neuroscience, but wishing more Neuroscientists would read the EEVBLOG!

   So, the outline, for doing A to D conversion, is, first, creation / design, of a simple light pulse SEQUENCER, (of course with an optical output clock), where the sequencing outputs come from a series of SPDT switches, (all optical), where each individual switch separates out one output, and then goes to 'chain' output mode, for next stage, in the 10 or so stages needed, for the 4-bit analog to digital converter.
   Some of the A/d converter is 'cheating', in a sense, by using wire extended LED 'duplicates', in some cases, rather than a purely optical setup, (that would demand certain mechanical proximity of four different light beams, of the 4 bit weights).
That photo, showing a three input 'gate' helps convey the context, of having all three input drivers at full (digital) output strengths, but then each attenuated according to 'weights' assigned within the structure.

[RJSV]

Photo shows (sorry for blurry vertical axis),  a somewhat close to linear drop-off, in the photovoltaic cell, going from 1 inch to 7 inches apart.  Upper curve is cell open-circuit voltage, typically the circuit switches at around 1.3 volts, in.  That sits well with possible 'NPN' type (input), perhaps with 1 kohm base resistor.
That's going to be, approx. 440 uA (micro-Amps).
That will allow for, along with a 1 kohm resistor, a 0.7 V transistor drop (bipolar).
The lower curve is transistor input current, a bit less, than 'inverse square law', but half's, every 2 1/2 inches

[RJSV]

Hi:
I had been considering, what that little 4 pin (inline) package has inside (?). It controls the battery, solar cell panel and LED output.
But (see prev post), looks a lot like a NPN transistor, a black plastic rectangle, but having 4 leads.
But, along with, apparently digital switching, THERE IS one mode, for having 'analog' on that LED output.
By obtaining negative feedback, by (unusual) way of placing your LED output back against your basic 'input' (Solar Cell), that's feedback by way of the LED intensity, which, BTW seems to stabilize at a rather 'dim' setting, perhaps at something like 80 uA (micro-Amps).
   Otherwise, that LED output is fully ON, at the times when logically that works out (usually, when all inputs are 'dark', or nearly so.(

One current problem is, my 'edge triggering' circuit (made from those yard lights), actually triggers well, and brief, but on BOTH edges, rising and falling edges.

[RJSV]

Here is a view of one particular 'switch', or Optical 'Gate', I like to call it. Takes time, but making secure fixtures eliminates some of the distraction, placing various light-operated pieces in relation.
This piece has only the IC, battery, and LED / reflector, while another table-mount piece contains the little square solar photo-voltaic cell, also glued for upright operation.  All this takes dedication, over stretches of days, so I try to make sure that's worth (the extra trouble).
   Main problem is, there is some mechanism, not a capacitor, but something is creating a delay time...maybe could be the solar cell itself.
(Whenever I try Google 'Solar Panel Impulse Delay Time'...I get some results like:
   'Three months lead time, for Solar Installations, in Midwest...'.
(That's useless).
   But in the edge detect optical circuit, it was supposed to trigger on (just) the falling edge, of light beam input.
So I have to figure out, what's going on with the switching action, as it appears there's a delay, before a new surge of light will create a response, from the circuitry. Since it acts in invert fashion, the newly ON light input causes the circuit to flash it's LED ON.
But if that response is delayed, then my circuit will flash on that (rising) edge, of the input.

[RJSV]

A better view.

[RJSV]

Well I solved a couple pesky problems; the Edge Triggered pulse gen now works: solution involves separating the housing / LED, from solar panel, I'll show that.  Other prob was, how to avoid those, horrible, circular structures, rather than on-line (preferred), again, solved with separated LED, from solar panel.
   On the Edge Trigger circuit (please see picture, of optical gates 'A', 'B', 'C' ), the gate 'B' is separated, that way each part can be put in optimum place.  For the reception, of light from gate 'A', you need the solar panel placement, broadside almost, with gate 'A'.
But then, for pointing (gate 'B') LED, that's a different direction, preferential pointing to gate 'C'.  So that's how you place that LED, so gate 'C' gets the best input.
   You get a nice flash, upon shine your flashlight at start, while avoiding that pulse out, when turning off your flashlight. The 'falling edge' is, more literally, the falling edge, from Gate 'A'.
   So, in this case, it's a falling edge detected, as there is that one logic inverter, first.  At any rate, edge triggered pulses help for conveying overflow from each counter bit (falling edge).

   For the Flip/Flop, a simple, on-line form has two gates, labeled as Q -not, and Q.

[RJSV]

This photo shows the on-line Flip-flop circuit, where the first gate is 'Q-not', seen in the left, and is with LED 'ON', meaning illuminated.

[RJSV]

This view, the gate on the right is illuminated, being the 'Q' gate output.  That indicates the 2-state thingy is 'SET'.  For doing a SET, or RESET, you simple put a pulse in, into the opposite gate..., so to RESET, you could pulse the 'Q-not' area / solar cell. Actually, literally, that solar cell, is on the 'Q' part of the flip-flop.
(This stuff gets tidious, to get straight, often).
   In the end, you have a beautiful Optically interfaced flip-flop, that gets a light impulse in for the RESET, and another one, to do flip-flop SET.

[RJSV]

Mired in stagnancy / stalemate, that's for sure.
   I've carefully built a couple of separated components; A lamp with reflector that can be positioned independent of main light sensing circuit and battery.
...An upright mounted solar Voltaic cell, on long wires, for the 'bench test rig'.
Plus, a 'Christmas' style LED blinker, for creating repeatable 'Scope traces...
   Now, I can, sort-of, get that goal, of having a full sweep pulse output, detecting a 'falling edge', of a light pulse, but the AMPLITUDE is always low; a dim and very brief light pulse.
It's a lot of 'figiting' and poking at it, as, for one thing, some of those little 'Light Pucks' don't barely emit enough light for causing triggering at the next (component in my edge detect).
   Ever had one of 'those' type stalemate, where everything seems muddied..., and even the failure parts don't express well, or vigorously! (No 'Chi' force, lol).
   At least, I've figured out, the optimum placements, for the 'sensor', vs 'output' (LED), are located in completely different places, relative to other components.
That's why I had to split up one of the yard lights, in the first place.
...more later, thanks.

[RJSV]

To show what I mean, by 'flakey' results...Even some of the 'failure modes', are flakey...like, for example, my trial edge detect circuit, currently exhibits a pulse output on BOTH edges, rising and falling.
..intermittently.
(See photo) That photocell 'splitter' allows for 2 inputs, while blocking any light leakage.  The items feeding the top half must not get any light, from the lower light output feed: that's why you can see the divider going across the cell (#3).
That (friggin) divider, had to push and pull that, just for having both light inputs be enough to trigger the #3 unit.  As in the classic edge detect, the upper signal (signals going left to right), the upper signal is the straight input, although inverted by gate unit #1.
The other half, is sent by way of gate #2, the solar sensor being #2A, there.  The purpose, via gate #2, is to provide a (very short) delay, before the delayed signal causes gate #3 inhibit (lower signal path).
This is all very solid, in theory. However, first of all, any light that leaks, forward through the logic, can cause a 'linear mode', where you have negative feedback, thru the solar voltaic cell, in the loop. That exhibits as a very dim lit LED...I'm not yet sure if that's oscillating, depending on phase, around 180 degrees, and other factors, as I'm not familiar with the 4 pin IC controller (inside each yard light).

[RJSV]

...here is view, of that separation wall, for the solar cell.

[RJSV]

Sorry, if the presentation is cryptic: those rectangles in the last 2 pictures, represent each individually operating solar light, with gate #1 being the input. Now, the circuit is called a falling edge detect, but input is buffered, so that, logically, the whole module acts on the RISING EDGE, of your ultimate input.
The gate #2 performs the logical AND using low going signals, so literally it's a NOR gate.  It's just that it's used (Thevinin Equiv.) so it needs both inputs low, to deliver the pulse (-P type) output, from gate #3.
For an NPN transistor, like a 2n2222, I could expect, maybe 100 nano seconds switching time.  There aren't any capacitors visible, inside the little lawn lights.
That means to expect, current delivered to LED output, will be interrupted soon after the #2 solar cell stops issue voltage. (That's why considered as an inverter).

   The two extra lawn lights, are options placed into the gate #2 path, in attempts to cause an increase, in the blink time, of the pulsed output.
Driving the input of unit #1, is a typical flashing LED.

[RJSV]

      On The Optical Circuits, Generally:
   Progress on some details, of the bi-stable bit latch, and on the pulse edge-detect dynamics.
A few more sketches on that Analog to Digital layout scheme, a favored aspect because of the somewhat close analogy with neurons (...if I got that right, lol).

   Due to the output weakness of LED light, for causing triggering, one method helps; by splitting a signal into 2 separate copies.  That way, no worries, about 'sharing' some output light, between a couple of different receiver (cells).

[RJSV]

Plus, adding to all this, those little Solar Light's LED for output, often are pointed, grossly, off somewhere very off-center, and the ones I'm testing generally use LED lense/housing. I estimated, those LED directionality is to take up approx 50 ° (degrees) horiz; and 50 ° degrees vertical, for about 1/25th of a full sphere.  So that comes to, estimated, a X 25 factor and a ÷ by 27 factor, for geometric 'R cubed'. That starts to fit my results, where the solar cell response has voltage dropping off, a bit slower than some 'R squared', but it's close to R squared.
   I find it a bit interesting, (and vexxing): here we have that large Solar Voltaic cell surface, ...acting like a summing node, in analog circuitry.
But yet, the LEDs 'sending' portion has those flakey directionality flaws, or at least inconsistencies.
   A newly built test lamp, has surface mounted 'green dot' LED emitters, already precisely positioned in reflector, so that's nice. 
Another variable in this process is the Solar Cell efficiency, relative to all these various LED emission color options.
(Those newly built lamps, are obtained by salvaging parts out of DOLLAR STORE flashlights, on sale).

[RJSV]

This photo shows: I'm having troubles, getting the screw terminal blocks to work, decent, with the delicate wires, often part of a separated, Solar Cell and nearby LED decorative light.
Problem with screw terminal block is the GAUGE; that light gauge wire does not 'squeeze' securely, underneath terminal, and, worse, those screw-down terminals can actually crush / break any soldered or tinned wire lead ends.
Best I'm going for now, is to solder a short (1 inch) piece of heavier solid wire, for direct insert into a regular IC solderless breadboard.

[RJSV]

Here is photo of some of the separated LED lamps, each with a fairly long lead set, for connection at that solderless breadboard or with a set of screw terminals.
By the way, using only one battery cell, at 1.3 V there is no external LED resistor, so any (future) testing that involves higher supply voltages (5V, or even 12 V), requires some resistor (range 220 ohms up to 1 k or so.)

[RJSV]

It's the analog aspects, of the Solar Light switching that is interesting.  That's why an example, Analog to Digital conversion, helps show the digital sequencing along with the analog response, and how they relate.
The scheme differs slightly, from conventional AtoD subsystems.
   Firstly, not much hope of going beyond about 4 bits of resolution just simply for mechanical reasons, too many components, in small spaces
Example includes a 3-bit layout, with maximum A/D count of '8'.  Each bit will contribute according to binary weight.  Now, it took a lot of thought, but I've set the A/D system up for 1 count = 200 mVolts.
The 'overflow' value used is '7', a little unusual, but at that scale, a resultant A to D voltage reading is 1.4 volts.  Readers may recall, the value, near 1.35 volts is where device switching occurs.
Conventionally, a different choice would have been, to use overflow (to '8', a binary boundary), and to assign each count as 160 mV each.
   The rationale for using '7', instead, for the overflow, has to do with so-called 'Two's Complement' representation:. Consider, an ambient (light) condition causing something around a quarter of total light, from natural and from (yard light LED) sources:
So, an ambient level, at count of 2, would require the REFERENCE Digital to Analog source to count up, reaching overflow status at count = 5.
Notice, that '5' is directly a complement, of value under measurement: level of '2'.  Otherwise, with more conventional overflow, at '8', will produce a result,..
.I.E. '6'; which would require 'Two's complement' additional process, so total process, for an AtoD answer would then require COMPLEMENT (easy), and then an INCREMENT (slightly tough, using all optical register logic).
   At any rate, the explanation is unconventional, but is mere conjecture anyway: The little light simply switches, nominal, near 1.35 volts, 1.40 volts being 'nicely' represented, by AtoD count of '7'.
   The other unconventional aspect, is that there are TWO analog sources, between the ambient light (about 2 out of the 7 total counts, and the Digital to Analog source, giving out '5' counts worth of light (that would be 5 X 200mV = 1.0 volts. ). Adding then, the ambient contribution, of 2 X 200mV and you reach the trigger level, of 1.4 Volts.
   There was concern, initially, that some A to D full counts are not there, thus some loss of already low, resolution.  However, when asked, to regurgitate an analog value, a Digital to Analog converter WILL produce, normally, all amplitude counts, 0 thru 7, even though original converter only utilized, up to count of five.  All this is normal, as also, when ambient light factor is 'zero', the system has to count up to '7', then invert, to show a correct value, (of 000 binary).
So you have full range and resolution, (within that, crappy counts 0 through 7 range), it's just that most Analog to Digital conversions only involve one single parameter, not two, that have been summed.

   It seemed perplexing for a second, as I contemplated, how to construct that Optical Logic A to D converter, how to bring analog values in, for summing (at the photo cell).  But THEN realirzed, NO, those signals are still digital (meaning rail to rail voltage swing), with analog process only at the destination; the analog weights tweaked by filters, reducing intensity, so that bit 2, for example, the MSB, is done with a '50%' blocking or partially obscure filter. That would be placed in front of the LED emitter for bit2.
Of course, distance to the 'comparator' gate is another potential manipulation method...having nothing to do with the very very very slight increased (light) propagation time, a couple extra inches...that's negligible.
   So there you have it: An intro to a digital gate system, having analog qualities, briefly or in one specific region (near to the switching input).
Reading, in biosciences book 'NeuroScience for Dummie', this is almost exactly similar to neurons, except one (interesting) aspect:
   Neurons do their job, having, sometimes HUNDREDs of little digital inputs (synapses).
I can't solder that fast, but interesting results to be had,
(If I can wrestle out all these variables.)

   "N cans, holding 'N' worms..."

--Rick B.

[RJSV]

More 'figiting and fussing'...  (Trials, for doing a pulse logic generator).
The incoming light (see photo, left side), goes through the series, along bottom, while also having a signal path, along the top; each signal path ending up as the inputs, to the final 'gate' (that's short-term for each separate 'lawn light').
Each separate experimental layout needs special attention, as the individual lights (Dollar Store discounted) are of limited quality, as in battery charge duration, LED pointing mis-align (path to next unit, for the feebled output), and potential for 'leakage', random,from one unit to (some) other, in the optical logic circuit.
   YUP; NOPE, this set-up does not even barely work, looking to see an output 'flash', as the inverting logic, of each gate, should create a 'rising edge' responding situation. 
   Also, the cheaper Solar Lights seem to have pretty marginal (AAA battery) running time, each evening.
The light's internal switching is done by way of a 4 pin IC, some are calling that a 'Buck Converter'...but I don't see any inductor, ...or capacitor, in the little circuits.
Found some other bloggers postings, for Yard Lights projects:. Big Clive.com has materials and actually does great job, very clear diagrams...(I should learn something, there).
Others do 'Art Projects', involving individual yard lights.  But I'm interested in the switching behavior (with analog parameters, as I've said).
   In my diagram, the upper signal path is the 'delay' line, operating a 'NOR' gate, essentially, along with the lower signal path.  Briefly, the final gate (on the right), will pulse, during the very brief interval, before the upper signal 'catches up', and supplies an 'inhibit' signal.  In theory, but it's not working. (Output stays blank).  I had been planning to attach Oscilloscope, to measure output pulse duration.
   I did realize, only recent, that the (single mh cell) likely is seen as a (large) capacitance, by the switching IC 'Buck Voltage circuit'...
   While viewing the diagram, it helps to view each 'gate', as a logical inverter, so the upper signal path (green units), is producing an inverted outcome, vs the lower signal path, which inverts twice and thus maintaining the original input state (coming off the very first buffer).

[RJSV]

More filling in the question areas, on the switching characteristics of those Solar Yard lights.
   Photo shows the little PC board, no caps or inductors; just a single resistor, for the LED output current limiting.  The 4-pin switcher, (sometimes called buck converter), is a bit small, there next to the yellow wire and white wire.  Several unfilled PADs seem to imply that manufacture had other options.  This is a step up in quality, over some Dollar Store lights, so perhaps the units sold had been 'downgraded', by process of eliminating (any) possible components, especially a coil for 'bucking' a higher LED drive voltage, than the 1.3 V nominal nicad battery (in other more expensive lights).
   Also, before I forget, a strange use was made, utilizing the SWITCH HOUSING solder terminals as a conductor, (if I'm to believe my eyes).  Only guess I can make, is that there might be other models of garden light, that leave out that on-off switch, while perhaps populating other PC board 'missing' items, L1 coil, and C1 capacitor.  The battery, being a nice (nicad) AA type
holds more promising run time, at night before it drains down.
   But, for the purposes of THIS light assembly the components seem to be bare minimum, for lower price points, and satisfying a growing consumer acceptance.  Ten years ago it was different: the batteries were all AA, and typical units had a centralized driver / Solar Panel, with LED power leads going out to each individual.
Also, earlier units used a CDS device (that's Cadmium Sulfide light dependant resistor).  Funny, those Cds light sensors sat right next to any solar power cell...
I wonder, if there was an 'AH HA' moment ?
(Being that a 'Solar Cell' actually IS a potential sensor.)
   That on-off switch looks like has an option, when in the OFF position, of a second resistor, R2, for trickle charge, even when Yard Light LED is shut off.  So, yes, money was saved, by leaving out the option, for charging (the customer's) battery, even when LED was switched off.  In this Dollar Store thrift version, that penny savings, at the factor, was a GREED option..., perhaps, and in 'the dark' (yeah, a Pun), for any customers, myself included.
There's a couple of other 'short-cuts' seen in some cheap units, such as glueing or even soldering that battery in place.
   But back to my project needs: I've figured out, the LED is essentially switched to ground, on the negative LED terminal, very similar to typical low-going NPN transistor switches.
But I bet...if done over, 2012 thru to now, that particular model would eliminate the switch, and go to AAA batt sizing...just to get into that Dirt Cheap / discounted product.
Nothing wrong with, some, of that 'quality down-grade', as I've heard of older landscape lighting (low Voltage AC) costing upwards of $100 per garden light!
The inductor, in this current style, probably allows for bigger, multi-LED units, while also perhaps a capacitor helped, in some situations, for avoiding flicker, in some situations ...(??)

[RJSV]

Here is photo, of the lower parts count yard light.

[RJSV]

   Just to be doubly sure, for reader clarity on the commonly known PULSE DETECT circuit, (here done with optical ON-OFF digital signals), pls see photo.
   Substituting an 'inverter' symbol for each Garden Light 'gate' (generic term for logic unit), shows the common electronics circuit symbols, adopted for my garden light collection, on the experiment bench.
Going to the right side of diagram you can see that the final 'gate' acts identical to a TTL setup, in an inverted 'Thevinin equivalent', to a NOR gate; that's all convention.

[RJSV]

A friend here had instructed me, on how to post multiple photos, but now, I can't find that basic instruction, in my PM messages received...
   That last photo posted, showing how a 3 gate line-up would exhibit a slightly longer delay, than the lower signal path shown, having 2 gates.
So, for a brief time, your output gate, doing negative logic AND function, will issue a pulse turn-on, that should (in theory,...sigh..), should last, perhaps 100 nano seconds, until that last upper path gate goes to 'ON' state...THAT should then disable the negative logic AND performed by the very last gate in the
line-up.  That's why I labeled the last delay gate as being a later rise (of led light output), supposedly allowing some short time, to issue a pulse, indicating that a positive or rising edge occured, at the left-side signal input.
   Failed theory, on my part, is OK here, as that's part of the whole learning process, for adapting those little yard lights to switch, like a TTL logic device could.
   One possible explanation, (I gotta get on the 'OSCOPE, in the landlord's electronics bench); it is possible, some extremely brief light pulse IS happening, ...just not visible !!
(I'll be checking for that, lol).
  Another possible switching action detail, is that the tiny increased spacing, gate to gate, creates some analog related delay, as perhaps electronic rise times in each light transmitting gate is increased, not due to distance related light propagation, but due to simple reductions in input intensity, to the solar cell used as light sensor.
Either way, just gonna take some time, and motion.  I have access to a very decent LAB and workbench, and rental (from a Mechanical Engineer, who does Electronic stuff).
Meanwhile, I'm investigating  the whole 'product quality' snaffoo, where those little garden lights got 'dumbed down', this year lasting only into about 9 pm, while older garden lights had more reasonable usefull run times (at least to 1 am).
   Please see photo, showing three 'generations' of these little solar light systems. The bigger unit on left in photo (circa 2010' ish) provided 3.6 volts, wired out to your various LED lamps around the garden.  Then, sometime after about 2015, those independently charged garden lights arrived on market: providing decent running hours, usually past 11 pm, (at least).
Please refer to photo.
Thanks for reading!

[RJSV]

...oh and some more detail, on the yard light switching circuit:
   That series 'resistor'...I've realized, in series with output LED, is actually an INDUCTOR, green colored, and ohm meter showing at '5' ohms...(I've been reluctant to trace the full circuit, until forced to, by the unanticipated switching. (Priority is more with subsystem exploration, such as that Ambient Light A to D conversion.
The digital aspects of that Analog to Digital converter are a simple challenge, to demonstrate ordinary logic processes, (like edge detection), and binary counters, etc, with commonly known Digital to Analog with comparator included.
   But I think, having that inductor in series, does do a voltage 'Buck convert', I'll have to pick at that later.
Big Clive video mentions the 4-pin 'Buck IC' as being:
   'ENA - 6182', the little transistor sized 4 pin package.
   Ultimately, with some work, I've got a nice, NEURON like set-up, for investigating various analog-weighted inputs, to digital switching subsystems.  But I'm willing to go the distance...
   It's the food cost issues, in this wartime, that bug me,
...I can handle engineering some instructional optically based subsystems.  Of course, there's lots of exciting work happening regarding optical physics, Fourier Transform, etc.   My stuff right now, is kinda like the early telegraph exploration, circa 1840's (!!).
Thanks.
Rick B. in Hayward, Ca

[RJSV]

Going gangbusters on some array stuff; I've settled on a kind of 'Ten Segment' arrangement, that has a hexagonal or 'close packed' alternating row, and having
4 rows.
I'm just thinking aloud at this point, but the structure allows flexibility to divide further, into a 5 + 5 where it would be, 2, 3, 2, 3 along the rows.
   For 'processing', there are 5 layers arranged as 'Plates', where each Plate contains 10 gates,...or at least gate positions

[RJSV]

In this view, it shows construction was using some e6000 glue, and a cardboard scrap, as a plate.
   The little lights are the lowest cost,...ONLY one dollar, at $1 .25 each, but I'm getting what I paid for...lowest possible quality.  Plus, they even SPAZZ, like some stupid Zombie movie (not you, Woody)!
Some of the lights go into a 'spastic' blinking, at late night...

[RJSV]

Front view, of a test plate, looks crude, but just checking what that '10 Segment' deal looking like.

[RJSV]

My first mistake, while attempting design, was trying to create stuff 'laterally', when what was needed, was a set of processes that move, in depth.  In this case, it is a set of 5 plates, each having 10 potential gates, or just left blank.
   One example involves a so-called 'Direction Latch', where a set of 4 optical latches will capture and hold the latest motion...that made by the sweep of a flashlight.  The logic is fairly simple. Assuming you've started down, left corner, that first, light responding disk will cause all to reset. Then, each of the 4 sensing angles have a dedicated latch
   An Optical Latch structure is a simple, in-line flip/flop, where layers 1 and 2 form an input chain, while layer 3 has the 'SET' gate, (in the cross-connect), and layer 4 has the 'RESET'gate.
Doing all functions, on each flip/flop, requires going with TWO columns, on the otherwise conventional R-S flipflop.  So, the 50 positions, of the (hypothetical) optical sub-system, are fairly well occupied, sensing and producing indicators, of direction, of flash sweep.

[RJSV]

Picture shows that application, using a generic array.
The application is to trigger on one of the 'sweep' directions, of a hand-held flashlight, and then hold that as an indicator, in a little display.
   The logic is pretty easy; for a start the flashlight (beam) hits the first light sensor, lower left corner.  That will clear all the other latches.
   Next, as the beam is moved, or swept across, each column will be a flip/flop,...responding to any light received, up top, layer #1.  Each of four different angles, of beam travel as the hand moves, are featured.  That is assigned according to the geometry of the placements, of each sensing yard light.
Notice you don't get a 'clean' 45 degrees; rather, that's going to be 41 degrees, approx, but you do get a clean basic 30 degrees and 60° degrees.
   I found that going to a 'depth' oriented logic, rather than wiring possible WITHIN each plate, the depth direction is a bit more challenge.  Generally, each flip/flop needs more than just the one in-line column, just simply for bringing in the SET and the RESET signals.
   Going to a partially wired, and electrically switched LEDs kinda eliminates the spirit of the 'all optical' approach, but...helps move everything along, towards some heavily optical stuff, hopefully.
The 'lateral' direction stuff, keeping within one plate, is very convenient, for including a couple toggle switches, and occasional 6-position rotary select.  Usually, an optical output section gets the most advantage and flexibility.

[RJSV]

This photo shows, schematic for one particular stack of sensing units, where the flip/flop is embedded as an in-line pair of gates, within stack of 5.
You only actually need two cross-connected gates; however another partial column is needed, for the various signals coming into the RS type flip/flop.

[MK14]

A friend here had instructed me, on how to post multiple photos, but now, I can't find that basic instruction, in my PM messages received...

Here is a link, to a post, I made about how to post multiple pictures, in the same post:

https://www.eevblog.com/forum/vintage-computing/cpu-clock-times-mechanical-computer-systems/msg3292962/#msg3292962

[RJSV]

There's a lot to explore, still, before the logic block gets my confidence, but it's interesting.  Biological systems, similar to this, encompass HUNDREDS of nerve cells and connections, and 'partial' weighted inputs. (I get stressed, at 'twenty'.)
   The start of some of this exploration, was with a 'random' sprawl of 15 or so 'gates' (yard lights), where I noticed some LEDs stayed on, but the pattern shifted, when I 'scanned' over the array, with a quick flashlight sweep.  Even more curious; some LEDs, in that random jumble, seemed to want to 'store' or latch and hold, according to what I did, with flashlight sweep.  A lot of that 'accidental' function, tracking direction, seems related to (various) deliberate 'edge detect' schemes.
   Now, a next action, after getting basic directional latching, would be some more logic added, (optically), that will shut down any subsequent latching, by inhibiting the other latches, in a one gate only strategy.
That, in itself, adds a lot of simple bulk, to a '10 by 5' logic block.
   Notice the '10' gates, making up one of the five plates in depth, the so-called '10 gate', refers to the X, Y array in the rough, being alternates, 2, 3, 2, 3 across, you could loosely say it's a '3 X 3' or even '3.1 X 3.1' as a reflection of an (X, Y, Z) structure, having a horizontal 'resolution' of about 2.5, so you could approximate as '2.5 by 4'... by 5 deep.
Sounds silly, maybe, but those numbers give an approximate feel to the (optical) logic block, and what kind of sending 'resolution' is available.

   Those separable plates, BTW, would typically be left out in daylight, for charging up (each individual).

[RJSV]

   This left-to-right ordered signal path has to have more, than just the straight line travel, of a light beam, for instance.  For doing the typical cross-connect, you need to have more options.  (One method just uses 4 gates, or even six gates, all around a circle).
Much of this concern is geometric, or mechanical spacing and positioning of elements.  The wired LED allows more flexibility, for separately doing optimum placements.  One option involves opening up the disk and 'pointing' the LED portion, back 180 degrees from arriving light, (that's hitting the solar cell sensor).
That way, your two LED units will 'point' at each other.
This same thing can be done, with one unit, to create a line up of units going the other way.  Essentially, you can 'take control' of what is 'up' and what is 'down'.  However, things can get complicated, geometrically!
And some configs will work, but detailed analysis might be missed, unless a 'copy' can be had, for a nice display, off to side of actual 'optical logic block', in a
 3-D format, perhaps.

[RJSV]

It's older news now, as signal flow emphasis is now in the 'DEPTH' direction, but here is the basis, as I had been designing 'laterally', or by wiring LEDs and switches within each particular 'plate'.
   I took the 'FPGA' route here, doing a few connections by default, having inverted copies right there, to use. and considering where to place those big, 6 position rotary selectors, for maximum flexibility, where most all things I need can be dialed in, while some extreme cases can be using full breadboard option.
The 6 position (by two layer!) rotary switch, actually, offers TOO MUCH selection variety, but...I won't complain.
   Most of what I'm interested in, along with some analog processing, is involved with edge detection, rising edge (optical signal) and all.

[RJSV]

Starting the day out, (self-employed), reading the various news...record breaking (worst) conditions in the U.S. of all sorts these days.
   But you have to start, simply that, in the face of every day (bad) news.  And there's a ton of good work to be done.  I hope my optical logic circuitry helps inform, and yes; entertain any readers out there!

   'Napkin Holders' make for great ART,...holding the various optical components, there, on the wire frames 'trackway'.  The paint helps reduce any glare reflection, of that chrome wire.

[RJSV]

This picture shows, the use of 7 'gates' for switching and creating a classic EDGE DETECT circuit.  Following the signal path, left to right, that first gate is merely a source, sending in split paths.  The upper path, is far off to the side, (but close), while that tricky arrangement barely works, and had to hand select for best first unit, to send fairly bright and pointed correct direction.  Most fidgety part, was the gate on far end, that acts as a logical AND gate, but both signals must be bright enough.  That is the upper, delayed, INHIBIT signal that will be soon arriving, after light pulse started into the first gate.  The lower signal must travel the 9 inches or so for triggering the final 'NOR' gate there, at right side output end.
   The whole arrangement needs to be indoors, of course, and supplements such as white board walls help.  The 'Output' pulse is very weak, but seems to work, reliably blinking but just only on the 'rising edge' of incoming light that you flash.
These yard lights are very low quality, however...(I don't trust them, beyond basic experimenting).  Plus, that forward operating Edge Detector needs a very precise and 'finicky' layout.  Some of that can be alleviated in doing a bit of re-packaging.

[RJSV]

   Picture shows, packaging option, with opened up units, there can be a 180° degree shift, of general signal path, for doing the 'cross connect' of typical R-S FlipFlop.  Those two opened up unit packages accomplish an entire FlipFlop, kinda amazing, although more is needed, to begin assembling a counter (for controlling an A to D converter, etc.)
   The counter is to use a 'T' type, or 'Toggle type' flipflop.  For the counting action, a logical 'Follower' stage makes a copy, which is then used, backwards or inverted, for the next counter bit state.  This logic is all helped along, by the use of edge-triggering pulses, (which is why so much emphasis, on getting that aspect of AtoD working.)
The split open housing allows direction changes, for layout simplicity.  In the FlipFlop shown, each state is obtained by a '-P' or positive pulse, so to 'SET' the flipflop, for example, you could flash a pulse of light, to the 'RESET' side, of the RS flipflop NOR gate.  That actually acting as a negative-input AND gate, in the flipflop.
   As far as packaging considerations, I'm already wanting to disassociate the LED, and led wires, as the flipflop output, so that a little, auxillary display can show in real time, the states of everything, inside that 3-D labranith of gates.  Idea is, also, to be able to easily pull the assembly of individual plates apart, for doing the daytime - daylight charging.
   Lol, I have to, literally, WALK my 'computer', every morning...oh geez...

[RJSV]

   As the picture shows, one way to implement the Toggle or 'T type' flipflop, the Main f/f is copied, with that simple little action done by 'phase 1' independent pulse, from a sequencer.  That copy, is then circulated around, to input pair, but with intent to reverse the binary value, simply to invert or 'toggle' to other state.
   That's gets me one bit, and that plus another  edge triggered sub-unit,  gets me into 'ripple counter' territory.  Getting into 3-D layout aspects; you get through the 5 layers pretty quick, and using in-line optical gates (seven, I counted), going to the in-line style of layout, is actually fun, like a cross word puzzle...
   I will post that, in a few, but looks like, first glance, would go (layers) 1, 2, 3, 4, and then turn-around at 5.
Then, coming back, other direction on next column, the optical circuit stretches layer 5, to 4, to 3, and to
layer 2.  That's actually perfect,  at least for one of the backwards running signals, as another 180° degree turn around gets you positioned, for the loop around of the 'Copy' bit, with inversion.
   The phase 1 and phase 2 clock pulses originate from 2 separate edge detectors, with square wave. One clock acts, on input 1 rising signal edge, while other will clock on falling edge, all done with light...at least externally.

[RJSV]

   Sure was off-base on this one:
   Picture shows, when yard light is ON, it's getting
plus and minus 1.5 volts, meaning 1.5 across LED forward, and at about 16 khz !
If I'm reading scope right, it is 9 X .5 usec, across one square'ish cycle.  BTW, having HORRIBLE lookin ring.
   Now, when that 'Edge Detect' was placed on scope, it was doing a burst, if those 16 khz cycles, looks like burst of about 5 milli seconds, ON period containing roughly 50% of each cycle.
   Now, I'm pretty convinced, that 4.7 ohm, green 'inductor' looking thing, (is one).

[RJSV]

Good morning!
   An interesting question comes up about sensors, involving LEDs being pulsed.  In the case of these yard and garden lights it is 60 / 40 square wave, 40 % ON, and at 22 khz.  I'm assuming that retains brightness, to human eye, but what about remote sensors, like a photodiode and LED combo, several inches apart.?
The sensor responds to photons, but surely any sensor arrangement would benefit, from a higher ratio of ON to off, or even just using 'DC' type flashlight, having just a simple resistor / switch, rather than pulsed.
   Some older type optical equipment utilized 'choppers' to artificially produce an AC waveform; that way an OP AMP could simply amplify any light input (before measurement or detection).  It could get crazy, though, out there (backyard garden, etc) full of those light sources, all 'vibrating' at 22 khz, while trying to amplify a single one, they would all interfere...?

   At any rate, I figure each 'gate' (yard light) runs at a switching delay equiv to 80 cycles or so, that number obtained from delay time approx 2 mSec.
That's 2 mSec over 5 gates, or 400 uSec per gate. equiv to some 80 cycles of the 60/40 square wave.
The flip flop arrangement works, as well as the (finicky) rising edge triggered circuit.  Probably, giving like 10,000 separate input pulses to it, when using one of the gates as a (hand held) flash, for testing things.
Other logic expected to work, also, generally, which is actually quite weird...

[RJSV]

(still) Massively surprised, at that oscillating / voltage buck circuitry: would maybe see such a circuit, in a more 'upscale' pricey outdoor lighting system, but NOT here, where even the battery has been downshifted, into cheapness...
  I can almost picture a scene, between Factory Production Engineers, and upper management:
   "Can I see (you) CUT another TWO components, for cost savings, across run of, say, 40,000 new units this week?"
   "...Or, how about a cheaper, or smaller battery?..."
   As photo shows, I'm thinking about 'upgrading' that crazy- 15 minutes of life- little battery.
I mean, analyzing the switching response, and speculating on useful ANALOG input properties,  I also generally feel, that the best yard lighting stuff is going to carry folks into the early evening, 9-10 pm, for those days in heat wave, or simple warm summer eve.  These current batch of lights, hardly make it to 8 pm.

[RJSV]

   I'm reviewing the switching details, on using that
 4-Pin IC (for switching control, in each yard light).
A bit mysterious (pls see diagram), as the LED appears to be constantly in series with the inductor, not switched there.  But I believe that's a BUCK CONVERTER, where the LED, on a constant 1.3 V is either a small, negligible leakage, through the otherwise dark (OFF) state, (being below FWD voltage).
Did I get that right ?  A GREEN color, is INDUCTOR,
right ?
   So, if you look to right of LED, is the 4-Pin control IC, and to activate some good light output the IC modulates the pin 1, this to alternate at 222 khz.  That way you get a Buck Voltage increase, each cycle that opens it's switch...Causing inductive surge down thru LED to circuit ground.
That waveform sure does RING...either that or I needed a better scope probe. (Nice old-school Tektronix).
So, (of course when dark), this circuit will keep the LED bright, by the 60% off / 40 % on square wave, at 222 khz.
   My assumption is, that in the setting for evening lighting, it's, maybe, a useit or lose-it scenario...if enough ambient light, from porch, house interior, etc. keeps the garden light OFF, it just leaks a little, through the dark LED, with the Buck Converter not running.
   A little strange, to try to scope out / use multimeter, as the LED seems to always get power.  Plus it seems; any light level to cause 'Switch Off' would, maybe, charge the nmh battery, a minor amount.
   Doesn't matter, if garden light drains out, each night, for the 1 dollar cost of the thing.

[RJSV]

   Great news about that 4-PIN IC Solar LED Driver:
Please also see YouTube, Chris's Workbench (2018).
The IC is called YX 8018 similar to YX 8050.
   The BUCK Voltage BOOSTER will produce approx. 3 V peak to peak or 1.7 V average.  Thanks to Chris's video.
He details some of the options and calculations.  Apparently, selection of different inductors will give you means for setting the LED current.
   Think of the possible uses,... There you have a voltage Dc to Dc converter, a Comparator, for switching at approx .5 volts solar cell output, and basically a logic inverter output, overall.
Great !

[RJSV]

   The example Toy Piano in combination with Solar Light's circuitry is a little wild, in the details.  Essentially put into the place, of one Dome (push button) Switch, you get action when a flashlight is taken away, from the Solar Cell, on the test bench, somewhat an expected result.  To detect any key switch closures there is a periodic scan, of each of the three rows, lasting about 1 mSec. and repeating around the 3 rows (repeats about every 5 mSec.).
The positive side of Solar Cell connects to that Row3 scan, as Row 3, Column 5 is the switch for 'Canned' Song examples to be played: Mary had a Little Lamb, etc.  This Row scan is connected to Solar Cell plus (+) while the Cell negative (-) connects to the Toy's processor input, for column 5.  That way, the Solar Cell negative output provides gnd, or even lower voltage, to the Toy's processor.  Maybe not best idea, but didn't break anything yet.
   The Piano function there is started when your flashlight is pulled away: causing the canned song to start playing (as if you had pressed the appropriate dome switch).  I'm assuming you had given (piano key input) a 'zero', which, when source (flashlight) is pulled, causes the function input to go high state.  This is consistent with original Toy logic, where each positive voltage scan can be switched...giving a positive rising edge, for activating the note or function.
   On Row3 scan output, you can even see a little 'spurious' glitch, in the time slots occupied by ROW 1 and by Row 2, within the 5 mSec. or so scan repetition period.
   But these behavioral things need to be noted on paper, as testing progresses, due to a few oddities:
   1).  If you've connected the Solar Cell 'backwards', and while illuminated (putting out DC voltage),  the mechanical wiggling can cause the function to start up.  (I've tried to visualize the input voltage resulting).
Then, flashing my light at the darn thing can cause one of the piano notes to sound...and this is while the 'canned' song runs, simultaneously!
   I'm not going to figure that part out so easy, maybe just note it in logbook.  But certainly does activate piano stuff, connected either way! 
   Leaving that aside, for a second, readers can appreciate; that's a Drug Store Toy device, that provides a set of 3 clock pulses, for other uses, at about 200 hz repetition rate of the typical type keyboard scan.
   Plus, if any readers wish, a good CD 4020 Ripple Counter can divide the 222 khz oscillator signal, I believe down by 14 divider stages, down to some 89 hz if I did the math correctly.
   Dividing the 200 hz keyboard scan would get even lower, some 200 hz ÷ by 16 k if I estimated that
 CD 4020 correctly.
You would want any addition circuit to have independent power supply, like 3 V etc.

   This description is, so far, only covering use of the dc Solar Cell...Wait till I describe using a full, Solar Light circuit, as drop-in replacement, for simple dome switch. (Later).
Thanks.

[RJSV]

Oops!
   I meant to say, you can harness the Keyboard Scan, to get 3 different periodic pulses, in sequence, at about 200 hz for the repetition rate, of the group.
That's off of the Toy Piano pc board.

[RJSV]

   For some analog fun, the diagram shows part of the Multiplying D to A Converter.
   In an example 4-bit size, the value '0101' is shown, a typical bit-weighted, shown here by area, adding up bit2 and bit0 (that's a binary '5').  To do the multiply, each of those 'ON' bits allows, instead of a constant value, allows a PWM signal, to be summed.
   This could all be done digitally, of course, (but with the garden lights as logic).
This analog method, doing a Multiplying DAC, does not mean that the PWM makes it through any of the gates, intact...it doesn't.  But it's helpful right there, at the instance, into an Optical Summing node.  In the diagram, the left side example has the PWM intensity level at approx. 30% while right side signal represents about a 50% PCM representation.
If that example is 0101b or '5' out of 15 max., then the result value, of the left side example is 1/3 of 30% or 10%.  Right side is 1/3 of 50% or about 17%.
The threshold is 0.5 Volts, in the comparator, so everything gets normalized at that kind of level.  One method, for doing small normalizing adjustments, would just simply pull the apparatus back a bit, that having a scaling and reduction effect.

[RJSV]

   This schematic includes a pad-down effect, implemented by simple distance, of emitting LED.
The digital PWM signal does make it through the enable gate, just before the attenuating, measured distance, the attenuated, or 'weighted' PWM can only have an additive effect right there, adding it's (photons)into the following optical input cell.
However, the ability to cross longer distances, without altering signal, is still available...just not in this schematic.

[RJSV]

   Here is a simple MOD; gets you an LED output pair.  In photo close-up you can see the LED was snipped out where that left a 2-pin 'header'...You can see, that 2 pin cable connector and wire, gets you a lot, for leaving the rest of the garden light intact as-is (although battery life sucks).
   LED leads actually too short to use, but it's only a few gates that get this EXT type interface.
It's convenient with FlipFlops, as the LED output can be extended around a circle type of layout.
Plus, some places need an extra, 2nd. LED.

[RJSV]

   It's a bit Ass-backwards, but the Schematic here shows the general scheme, for generating a (crude) PWM signal.  The 222 khz source on the left side of diagram providing a Charge Pump, to (right side) capacitor C1, while second gate, on right side, handles the typical voltage comparator.
The RC there, 0.1 uF X 1 kohm gives 100 uSec as a design starting point, idea being a cycle of timed pulse width every 100 uSec.
The third YX8018 'gate' module (not shown) is to provide output cut-off according to local light intensity...translated of course, by this third gate.
That's 3 compact assemblies, at a buck-20 price!
Those 3 'Garden Lights', plus a couple of 2N2222 NPN transistors for drivers.
   I might be able to share portions of this, in additional PWM generators, in other nearby logic.
   The schematic isn't finished, and, has the polarity of action probably reversed, as the circuit shown possibly gonna need a Flipflop, for start-stop control during each 100 uSec PWM interval.

[RJSV]

(Please See previous schematic diagram).
   Looking at the second gate, on the right, the usual Solar Cell has the timing CAP. replacing it; that way the little solar module is comparing for capacitor (timing ramp) voltage, for ending each 100 usec cycle period.
That will need some tweaking, and obviously the battery won't be getting (solar) charged automatically.

   Another concept: there is a way to provide an 'exponential' based ramp, by sequencing up through binary weighted values...a kind of digital generation that would sequence as 1, 2, 4, 8 etc. creating an exponential shaped output curve, (rather than integer counting linear ramp).  Actually, basic digital binary counting registers are VERY bulky, using the garden lights for optical digital functions.

[RJSV]

   I've shown parts of this before, diagram helps explain the role of conversion, analog (light intensity) to a crude PWM at 10 k samples per second.
   The upper expanded size (yellow) shows how each Flipflop is packaged as a cylinder...sometimes that could be a closed tube, having reflective inner surface.
The Flipflops each consist of 2 gates, plus that (extra) LED on the output end has been 'looped around', to face into the Flipflop cylinder input end.
   Below that slightly 'exploded' view, you can see a great big PURPLE arrow, indicating the ultimate output is the Summing Comparator (gate).  Purpose is, just like a classic style AtoD converter, to allow the sequencer to either keep or cancel the latest of the Bit weight being tested (for overflow).
   Of course, that sequencer mentioned is a whole subsystem in itself (bulky!).  The smaller view shows some of the components that might not always FIT, conveniently; that's the motivation for developing PWM methods, as that DIGITAL signal can be transported.
As I explore the practical aspects, of course that PWM excercise turns out to be pretty complex and bulky, itself.  But idea is to off-load any task that gets too bulky right in an immediate 'Analog Region' where distance and obstructions would cause uncontrolled attenuation.  The PWM channel, shown exiting that (lower right) region is thought of as a sort-of 'PWM HIGHWAY'.  It is supposed to carry an analog light intensity, over to the main comparator, without lossy issues to correct,...3-D geometry wise.
   You can also notice; (red color) the 'DtoA' portion shows 3 channels, a stronger higher bit, bit2, and another two bits, bit1 and bit0, where bit0 is the most distant, from comparator gate.
   It's fairly conventional A to D fundamentals, although the method is slightly different, in that the embedded DtoA conversion is ADDED to the value of light intensity being measured.  That way, the end result is a backwards, Two's Complement value.  That's due to using the (unmodified) fixed level sensing.

[RJSV]

   Frame and suspended rails make a cheap - stable 'wireless breadboard' (pun).
   The broadside view shows 4 channels, of an intended 8 channel Ring Counter Sequencer, for an AtoD converter.  The idea, for open frame, is for quick positioning, while having that structured approx. like I wanted; That is, having four Flipflops, in a 2 by 2 arrangement, and with 3rd layer of gates up top. 
   So the overall is 2 X 3 X 3, where the 3rd, top layer is providing a right to left signal path, then FOLDED over 180 ° (degrees) to come back, towards ultimate sequenced outputs, 1 thru 4.

[RJSV]

   Those yellow colored gates, (previous photo), are the sequencer outputs.
   In this photo, left side of gate assembly, the starting gate, of each of the 4 flipflops, is acted on, by upper layer, that is the two phases of clock needed, for the shift register, or ring counter.  Phase 1 will shift from gate 1 to copy bit to gate2.
Notice the direction change, as the upper layer shows LED outputs, phase 1 and phase 2, while lower (2X2) four are the inputs for those 'Phase clocks'.  That's via a wired extra connection, from layer3 LED Outputs.
   One main goal here, is to verify the 3-D placements.
A couple other advantages now, with frame and rails, is that a light blocking cloth towel can be easily placed over.  Also, (eventually), the gate's position can be stabilized enough...the whole apparatus can be placed in the sun, for recharging.

[RJSV]

This view, is the output array,...sorry if the frame cross member is blocking the view, of center layer of outputs, that, along with lower layer, are the 2 X 2 outputs, that go to the 4 bit example AtoD converter.  Each sequencer signal pair does first a SET, then a specific TEST, allowing gate comparator a chance to do immediate RESET, if overflow occured.
   That way, after the SAR sequence completes, the 4 bits Flipflops will hold the answer value,...a 'Two's Complement, of actual analog value, (being also added into the main summing gate.

[RJSV]

   Here is diagram, of the shifting portion, of the 4 bit shift register, used as a Ring Counter.

[RJSV]

   This 'thing' is as new, to me, as it is to READERS...
Breaking news, and all that.  The mechanicals, or the 'Fit and Function' design issues dominate the scene.
But that's OK, I have a 'keen sense' (lol), for industrial design and looks.
   That rectangular frame pops together fast, and the (red painted) 'hook rack' does OK, provides parallel rails, but I don't want all those hooks, so they will come off.  It's a bit of a test, and kind of like trying to see how many members of a BASKETBALL TEAM can you fit, into a single bed.  I'd like to see the job description for that...Something about 'fitting' a Tesla Convolution IC, into a, uh...I'm running out of descriptive language!
That's my zone,...good or bad.
   You may recall, in all this mess, that current sub-system is for doing the DtoA portion of Successive Approximation scheme; task is get eight bits all together in close proximity, and shoot that bundle of pixel-joy, into one 'Comparator' gate...along with whatever light beam is being measured.
   Odds are, I have no current competition, which can be good...or perhaps some, devious foreign or domestic SPY group is gathering up all this.
   Patent Office sees 'Novelty',...but novelty don't mow the grass.

[RJSV]

   Here is another camera angle.
Next, those unneeded hooks will be taken off, and more of the parallel rails to be added.
   The sides, of this frame, are where the outputs come out, and next module will have more logic.
Current test build, is actually an 8 output state machine style sequencer, but much of the logic looks similar, in long stringy runs, of components (gates).  But that uniformity helps here, as many of the frames can be built similar.

[RJSV]

  The enclosed photo showing, a total of 32 'gates',
just a first test, each rack lane can handle as many as eight serial-connected, (by light output).  Of course it's cheating, a bit, by relying on wires and LED extensions.
Most of the easy mods are, one is to split the two LED terminals, simply out to a pair, in parallel.
   The nice, and only moderately complicated, is the ANALOG (full, including carry) ADDER.  The left side, has output gate, in RED.

[RJSV]

   In this next, close-up (please see photo), most other gates cleared away so you can see, the extension that goes between two gates.  Right-side has yellow input gate, withe signal, plus portions of optical DtoA, also yellow.  (See also, the photo has a V shaped clip that indicates the '180° degree' turn, back to a normal right to left signal flow organization.

[RJSV]

   This photo, shows the empty segment, between two gates.  This is for the combination process, where the (next in line) rather than 'branching out' the process is analog addition, into the little solar cell itself.  Best done with wires coming in, as interior will be host to 5 LEDs, that is, an analog 'A', and analog 'B' plus a D to A  converter, equiv. to about 3 bits binary, or steps of
 12.5 % as the D to A is used, but that is usually figured as 'N-1' so 100 % is the comparator threshold, when switching happens.  Apparently, thats for a cell output voltage close to 0. 5 Volts.
   Of course, no giant expectation, of linearity there, possibly far from it.
   One thought, to maintain that 8 step intensity of LED light, in terms of resolution, is supplementing with a kind of hybrid ' upper digit'.  That would have same resolution, but in a separate analog channel, this upper digit represents, loosely, the (digital) 8 and 16 bit accumulators in 'vintage' processors.
At any rate, 3 LEDs for the Dtoa and you need 2 LEDs for the A + B, the 5 optical intensitys are summed.
If carry, then that immediate ADD is not valid, as the comparator was in 'saturation', above 100 %.
Also, a digital gate, like 3-input NOR, could use that connecting mid-way segment, as 2 or 3 signals merge into the gate's input section.

[RJSV]

Here is a better packaged Flipflop, a cross-connected standard Set /Reset.  It has fuller function, as (hope) those two intermediaries, the half-circles, should let in a lot of sunlight, while the two gates are obviously on-line, plus the photo shows signal flow is left to right and photo shows the F/f pointing into some more misc gates, (of a variety).
   These intermediate portions help continue that 'long and stringy' spaghetti structure, of the logic generally.
So the LEDs needed, would there, on the arcs, and pointing into the following gate's input (solar cell).
For the Flip/flop, the ON/OFF state reinforcing has the 2 wires from LED output, running backwards, to the back gate (red colored).

[RJSV]

This photo, of Flipflop package, shows the somewhat continuous cylinder, and then, to the right, the misc gate that gets the Flipflop output, is toppled over a bit to show the look of that half-arc piece.
Thanks

[RJSV]

   So while the openings help, while charging each little gate, in direct sunlight, that 'in-line' flip flop is Set or Reset by shining a light on either port, created by each half-circle opening, there...Red port being 'SET' while the other is 'RESET'.  The half arcs also help block a little cross-talk from nearby optical logic.

[RJSV]

Photo shows:
   That's 10 gates (signal goes left to right), with a simple frame, the straight portion has 6 gates, roughly a Flip-flop having 2 enable gates (4 total).
The round portion, maybe more 'theatrical', in this example that circular part could have the RESET getting distributed, as individual signals.  Notice, that circular portion is 1/2 up, in terms of vertical (gate) spacing.  Various options, but here I want Three vertical runs, of the open rails, going upward, stacked.
   And now, I'm facing the problem, when there's overflow, in analog adder...I'd like to move that 'Carry' out and over, with anything over 3 bits max value.
So, with Analog Full Adder, the light (intensity) could get high enough, at 0.5 Volts, to reach 150 % for example, and would lose the low value, resulting in a value of '1 ??'.  So, I need a way to subtract that 'high digit' portion, for determining the low digit.
   This High Digit channel is analog, and has typical DtoA converter, associated, at 3 bits or 8 discrete levels.  Bringing in a carry, is just a matter of introducing a '1' weight LED output, into the summing gate's square input cell.
   Having 3 levels, and also a twin structure behind this,
all total, is approx 32 gates, where a box-store 'flat' case has 48 Solar Lights.

[ebastler]

This is an interesting exploration of designing logic circuits from the ground up, using optical interactions as a different "medium" for the basic gate. Most importantly you seem to be having fun with it!

I can't see this having utility in "productive" technical applications, since obviously electronic gates offer so much higher integration, higher speed, lower power. But it could be used in a "logic building block" system for education, packaged in a similar way to the BRAUN Lectron system maybe?



It would be nice to directly see the state of each gate in a circuit one builds. But then again, you could provide the same functionality by using conventional electronic gates and putting an LED on each of the modules. Connecting the building blocks in a systematic, modular way is probably more easily achieved by electrical connections than optically?

When you mentioned that "the patent office sees novelty" in a recent post -- did you actually submit a patent application? Just curious...

[RJSV]

Thanks for question, Patent Office (in theory), can offer that bit of 'advice', as happened with myself, in so-called First Office Action.
Basically saying, examiner did a 'skim read', and found a catagory, (such as '710 Data Transfer Methods), and saw some potentially 'novel' idea(s).
   The main subject here, is to gain a 'region' I call it, meaning a 3-D space, for analog uses, where distance causes a particular 'attenuation', and electronic sensor surface becomes a 'summing node'.

Right now, photo showing, the DtoA portion, of any full adder system, where the light (going from right to left in photo) is summed, according to weight, the 3 bits being 1 of 8 levels.  Roughly representative of the built in weight network, is the distancing, first the RED LED, being the bit2, while further out is YELLOW LED, and GREEN LED, as bit1 and bit0.
For a 0.5 Volt equivalent, and linear, that's about 62 milliVolts, per step.
   You have to think in digital terms, to understand, a simple 'carry' condition, takes you to the next 'digit', but that's only an analog representation, again at 3 bits, you end up with 1 of 64, but only as a two channel analog, each at 0 to 0.5 volts range.  Point is, with a carry, into 'high digit', you simply add in another
(62 mV) worth of light, or a count of 1, in equivalent D to A terminology.

[RJSV]

To get around the parts ordering probs, I tried cutting short pieces, of regular, solderless  bread board...this being originally some 70 pins long, and with typical double-row, for IC placement, with 5 pin placements, or rather; sockets, that can take plug-in pins
So I get a set of possible 2 separate electronic circuits and battery set.  A snipped LED, and those 2 wires can act like a 2-pin header.  Then, 4 other socket pairs are avail.

[RJSV]

This photo shows paired up gates, in a cellophane wrap.

[ebastler]

Thanks for question, Patent Office (in theory), can offer that bit of 'advice', as happened with myself, in so-called First Office Action. Basically saying, examiner did a 'skim read', and found a catagory, (such as '710 Data Transfer Methods), and saw some potentially 'novel' idea(s).

But doesn't that mean filing a proper patent application, and then waiting for about 18 months or whatever the current "pendency" of a first USPTO office action is? Sure, filing an application is not expensive. But after 18 months your application will already be published, and you will also have to decide about international patent filings if it's an idea with serious promise.

  The main subject here, is to gain a 'region' I call it, meaning a 3-D space, for analog uses, where distance causes a particular 'attenuation', and electronic sensor surface becomes a 'summing node'.

Right now, photo showing, the DtoA portion, of any full adder system, where the light (going from right to left in photo) is summed, according to weight, the 3 bits being 1 of 8 levels.  Roughly representative of the built in weight network, is the distancing, first the RED LED, being the bit2, while further out is YELLOW LED, and GREEN LED, as bit1 and bit0.
For a 0.5 Volt equivalent, and linear, that's about 62 milliVolts, per step.
   You have to think in digital terms, to understand, a simple 'carry' condition, takes you to the next 'digit', but that's only an analog representation, again at 3 bits, you end up with 1 of 64, but only as a two channel analog, each at 0 to 0.5 volts range.  Point is, with a carry, into 'high digit', you simply add in another
(62 mV) worth of light, or a count of 1, in equivalent D to A terminology.

Again, it seems that for a practical implementation it would be much easier to do this with currents and voltages rather than light? Adders with current summing junctions have been used in analog computers forever, and have a much larger dynamic range than what you can achieve optically, I think. And if you want to obtain a reasonably well-working optical adder, you will have to put it into a dark box; so you even lose the didactic benefit of being able to directly see the states.

I still struggle to see the technical benefit. Doing it for your own education and entertainment is, of course, a perfectly viable reason for doing it! 

[RJSV]

Yeah, a 95¢ cent Processor IC could do everything that 'benchtop' maze could do...that's why I try not to get sucked in, to conventional electronics, like wired-in LEDs that, essentially make it more component wired to component.  (I'd like to be able to do some processes, in the spaces 'between').
Right now, working on specifics of accumulating larger values, having, for example, 3 channels, each having weighted value 8X the previous 'digit'.  At that point, those 3 separate analog channels don't have a direct link, to the physical (optical) intensity, but rather are more abstract 'just a number value', but at max would represent some 32 Volts !
That's figured as (D X 64) + (D X + D.
Edit: (D3 X 64) + (D2 X + D1
This editor keeps substituting emoji supposed to be X 8 'times 8'

That refers to having 3 bits worth of accuracy / resolution, for each 'digit''s channel.
   At any rate, I wanted some system that could do the long 'Multiply and Accumulate' terms, needed in convolution, in this case can easily sum up to 64 terms before overflowing the register.  This accumulation must be done in-line, as there is no on going storage.
I'm also hoping any PWM generation can have decent resolution, of signal output.

[RJSV]

   Making minor mods helps, the photo showing can use a tiny slice, taken off a solderless breadboard; that provides the LED Output with 4 pairs of pin-sockets right at place on housing that originally had it's LED.  That way, I've designated a 'Type M' gate, having output splits, usually two-way.  Meanwhile, a type M would also have at least one LED premounted to fire into the input (solar cell surface).  Eventually, all these MODs make for an IC with connectors interfacing, but of course, it's always been ELECTRO-optronics, so I can tolerate limited (wire) connections (some of which could be done with fiber optic cables.
The protoboard is remarkably easy to cut, using a old WOOD SAW...The row of 5 springy clips gets pulled up and out (the bottom) easily.  I've cut the little strips with having 3 lanes, for cases where LED resistor may be added in.

[RJSV]

This is my 'Chia PETs' moment...those little solar garden lights need feeding (sun) every day (or they go into SPAZZ mode.
   The LED output distributor helped packaging, by not requiring various twists and turns, creating a 'branch-like' or tree like split; and having one of the two (or more) inputs be a dedicated LED (wire pair input) helps keep the assemblies as 'in-line' and parallel housings.
   Photo shows, the one deviation, from direct 'in-line' placements, has the 2 gate pair as pointing slightly off-line, that way for placement in bright light, or SUN direct, to charge.
The 2/3 size 'AAA' batteries are limited; to 100 mA hrs.

[RJSV]

   I was going to take a sec, for tribute to the new Space Telescope...AWESOME!
   Forgot it was '6-sided' (mirrors).  But, (Pls see photo), the 5-sided variation does not lead to a flat assembly; the pentagon shapes, assembled, make for a curved upwards set of sides...plus, the top piece center of weight is NOT directly above, the center of the bottom piece.  The Chemistry / Chrystalography folks know about these things.
The Space Telescope, with 6-sided pieces, can be assembled into bigger shapes, flat, without being forced into a 3-D solid shape, like happens with 5-sided components.
   Notice, in my photo of 5-sided assembly, that a 6th piece can be added, to be a center, plus that gets things into 3-D territory, and looks nice.  Other up/down variations can be done, further out from center.

[RJSV]

   Adding gates, into existing indents, you can add another 5 gates, (notice how the original pentagon shape gets repeated, at larger scale).  That addition makes for 11 total gates; 1+5+5 = 11.
   Also, though, these 5-sided shapes will never go together, to solid plane, as there are always gaps.

[RJSV]

Placing yet another 5 gates, you get yet another pentagon, almost back where started; that's now
at 1+5+5+5= 16.  Etc etc, but this will never produce a gap free plane, like a 6-sided configuration would.
   Maybe NASA could fly this 'telescope' design...reminds me of the tiny satellites, as these could rely on solar energy, individually, (although not vacume-ready for the batteries, etc.).

[RJSV]

    For a two-stage flipflop, having input f/f separate from main f/f, that way any feedback actions are not actuated, until the COPY process completes, so any feedback won't cause a flakey response that might affect the input set/reset (until f/f has fully switched).
 
   Picture shows, this is getting into the shape needed, including that oval shaped clear plastic wrap, having 4 sets of pairs, in series order.  Notice, some bias 'lean' for capture of Sunlight, during recharge, while protected enough from nighttime moisture, if left outside.  This way, can avoid major dismantling efforts at end of each day. 
   This is 2 lanes wide, by 4 gates deep, and structured generally as 'SET' and 'RESET' corridors, meaning that usually can be activated, using a hand held flashlight, shining on either input.
   (Please also see schematic, posted next).  That schematic showing the 2-stage copy process, that also requires a 2-phase clock of separate phases acting to copy from input f/f to main f/f.

[RJSV]

   Here is approximate schematic, for that 'oval' or
 2-lanes clear enclosure.

[RJSV]

This view shows, the flipflop assembly SET and RESET output LEDs.

[RJSV]

ebastler, here is some more response, to your question(s), about Patent, and about motivation, for the optical gate organizing.

   You are exactly right, it was 18 months after initial filing and the examiner had done a few minutes 'skim' reading, to determine 'class and suitability, for publish the application.  I had spent, virtually 3 YEARS, up to the original mail-in date...September 9th, 2001.
   But with a couple more days prep, and it was September 11th, (2001), the morning of the attacks, on New York City.  I almost got that (big) mail packet, jumbo sized Application document (some 436 pages),
almost would have been mailed, like Sept. 10th...
   Big mess ensued, luckily I held off filing, until the whole scare with powder poisons in various government mail.  The application got published, on Jan. 11th, 2003, just like you said, at 18 months.
So, in my case, the prep time, and care, (some 88 drawings!), were huge, and that's not counting R&D time.  I'm fairly decent, at writing, and did all the spell-check and grammer, to the utmost quality. (Examiner can reject a crappy application; basically requesting a rewrite, by professional.). So I missed most of that, 911 stress / drama.  Actually, now that I'm reminding myself, the Examiner had made the comment about "Novelty likely present", on our brief phone consultation.
   My strategy, was to include literally everything, related to the 'Mechanical System', so to prevent some other party/industry player from filing, and thus frustrate (my) ability to operate (my own invention).
Kind of an amatuer lawyer dopey 'strategy'.  But you should hear my 'Lawyer Story', around that Patent.  Short story: My 'Patent Attorney' drank...er I mean, worked, from home...not so productive, always, I'm hearing lately...

   Now, back to motivations for this thread.  Stanford University's EE researcher is doing optical systems, that do, essentially a Fourier Transform, down thru layers, in a block of CMOS logic.  That way, the device can do some incredible parallel operations...some 1K by 1K block of pixels, for some 1 million operations, all with light beams as signal. Massively parallel, and plus that project illustrates the application right there.  Sorry, can't remember the Stanford Researcher's name.

[RJSV]

   Here is an example of using an 'inbetween' medium, useful to process some general signal, where the transmit section is essentially a discrete number line, and, in this example, a discrete receiver section takes the output value.  It's very similar to a look-up table.
   Kind of schetchy and general, but you can see, in diagram the yellow color highlighted area is a light diffracting element, prebuilt to perform division.  For better accuracy, an interpolation method can also be applied, to the 'receiver' array.
   The transmit and receive portions can be standardized (especially for what is considered full scale).  Of course you could get silly, and try putting a 'dead possum', into that medium processing space, but that comment really meant to indicate the processing method is all about what is placed there, such as a set of 'filters' that can perform AI 'Pooling', all in one big parallel step.
   For those kinds of processes, you might generally want the configuration to be 2-dimensional...where this example is a simpler 1-dimensional number line.
An example of 2-D filter could be a 2-axis SINC Filter, (useful in convolution)

[RJSV]

Working my way through various mechanical issues, right now playing 'herd Management', on that messy pile of gates (and internal AAA batteries).
Trying to weed out the flakes; you can see in picture, that 'Yellow #302' unit has been 'going spazz', (blinking or strobing), but yet battery checks out OK, at 1.26 V.
So today the strategy for tracking that, is to replace with another battery, (also starting out, in charged state at 1.26 V).  Let that sit in SUN and then go overnight, (for another 'spazz mode' trial...this time I will probably put the IC / PC board assembly on QC 'bad' status...(I have, approx 80 of these solar lights, so it helps to serialize for tracking).

   Eventually, as all this shakes out, I will have a (larger) set of 'gates', with many in sub-assembly forms that can be simply placed in sunlight, during the day, without disassembling (to excess).
Thanks.

[ebastler]

   Now, back to motivations for this thread.  Stanford University's EE researcher is doing optical systems, that do, essentially a Fourier Transform, down thru layers, in a block of CMOS logic.  That way, the device can do some incredible parallel operations...some 1K by 1K block of pixels, for some 1 million operations, all with light beams as signal. Massively parallel, and plus that project illustrates the application right there.  Sorry, can't remember the Stanford Researcher's name.

Hmm, not quite sure what you are describing there.

Multilayer, massively parallel FFT implementations have been done, of course, e.g. on FPGAs. To do an FFT on 2ⁿ points, you need n layers, each of them combining pairs of data via a "butterfly" operation. But I am only aware of purely electronic implementations, and don't see a benefit from using optical technology there.



On the other hand, the realization that optical imaging can be described by Fourier transformations has been around for a long time. (Joseph Goodman published a book about it in 1968, "Fourier Optics".) By simply imaging an object plane to infinity, with a single lens, you have a done a 2D Fourier transform -- massively parallel, no "multiple layers" neeed, just a single operation at light speed. I believe 1D arrangements have been implemented on CMOS chips, although probably as research projects only.



(Nice and simple illustration of a Fourier transform and then transforming back into real space. But they mislabelled it; should be "Fourier Plane" in the middle, not Focal Plane.)

In the latter case, using light obviously makes sense: The imaging operation does the whole FFT job. But you do not get a similar benefit in your concept, where light is just used to transport scalar analog or digital signals.

If you can find the Stanford reference, I'd be curious. Maybe it is a combination of the digital, multi-layer approach and an optical FFT "core"?

[RJSV]

   ebastler: I've been looking back, at my notes and previous videos, on that Stanford researcher who commented on using CMOS as a coincidence, because the material qualities were good.  I believe it was, maybe, at infrared wavelengths, a silicon 'disk' made good optical processing qualities, (not sure if it was diffraction grating structures, or whatever, sorry).
   So, by coincidence, CMOS manufacturing processes lent to good results...otherwise the researchers couldn't justify the 'millions' of dollars that have already been expended, for building CMOS electronics...
I believe it was a 'core', as you've surmised, put in between array of optical sending sources, and corresponding receiving sensors.  Their research in that aspect MIGHT have been less clear, if not for the fact that the various (micro) fabrication stuff has gone through such history, of progress.
  I'll keep trying various searches, but I did verify that it wasn't the 'CS-231' Computer Vision lectures, (although that in itself is fascinating).
Some of those video materials have also mentioned using Fourier transform, in some filters, as easier to code, vs full convolution.
   My Android smartphone doesn't maintain a full history, so not possible to go back, that 4 or 5 weeks, to that interesting material.
More persistence I'll find it...That kind of research helps frame the math, in a practical example, rather than simply stating that massively parallel computation is useful!

[RJSV]

   OK, found it! (Essentially).
   Found the reference, Stanford University E.E. Department doing research on (CMOS) Optical and Wave physics, as mass computational element, or 'core' as a flat disk.
The 10 inch diameter disk serves as a (X,Y) array doing implementation of Neural Networks, having more conventional electronics interfaces, in and out, but based on optical and wave physics in the (middle) 'core', which appears like a plastic disk, with clear surface.
   Still haven't found original video, but the following info is very likely the same Department:

   Stanford University 'Initiative for the Theoretical study of Neural Networks'  video, October 21, 2021.
Lecture presentation by Professor Shanhui Fan, of Ginzton Laboratory.  It's still very relevant to similar 'Deep Learning' methods being researched using FPGA logic, etc.
   The photo (video paused at approx 7:00 minute), shows the round silicon 'wafer' from foundry, that I'm assuming is the CMOS fab, mentioned here a few posts back.  They are calling that a fabrication of waveguide arrays.
Introduction by Professor Vnod Menon (sorry if mis-spelled the first name).
   Lecture starts by mention of energy footprint, of mass computation for Deep Learning networks, being problematic.
Sorry if cannot pin down the exact time (7:00), as YouTube format change doesn't give elapsed time, in video.  But, at any rate, got the right academic department there.  I've noticed that many universities today are CHOCKABLOCK FULL, of required social media, If you want any kind of reasonable communication...that means no published EMAIL contact(s), even....Ridiculous.
Thanks, - - Rick

[ebastler]

Thank you for digging that up! Here's the actual video you refer to, I think:


So they use a waveguide (interferometer) structure on a CMOS chip to perform matrix*vector multiplications. It's meant to be used in neural network (deep learning) systems, where one would typically have multiple stages of such multipliers on one chip.

The main selling point is that this is much more energy-efficient than an implementation in digital electronics. The fact that it's also faster, especially for larger matrices, is a nice extra benefit. 

By the way, there is also a renewed interest in analog computing, for much the same reasons: Fast due to fully parallel processing (more like an FPGA than a CPU), and using much less power at comparable computing speeds. Here's one startup company which aims to integrate analog computers on single chips, both for portable low-power uses and for high-power computing: https://anabrid.com/

[RJSV]

This 56 Gate monster (see photo), you could term as a crude pantomime of a neural network (visual processor).  It brings a general stack of gates into a form that can be re-charged in-place simply by placing the entire module in a sunny or bright spot.
   As configured, each stack of 7 gates has a sensor (layer 1), various inverters and flip/flops as 1 bit for each of the four corners.  Extended bit storage, to 12, is accomplished via shift register function.
   As in edge detection strategies, this 'cube' can be used to experiment.  For example, a moving light scanned across the top (layer 1) can cause an effect where 'old' status but was present, in older sample, but not now, while current sample (corner) signal is new. That gets to be quite a specific criteria!  (I think a simplified version, that sort of specific motion detection was one-of-seven variations, of conditions.

[RJSV]

This photo shows, the line-up from pixel sensing down, is organized in pairs, and further simplified by only doing half of the pixels, out of 16 array, (of 4 by 4).
Each pair is Logically OR'ed from 2 pixels, resulting in one bit per corner, in a 2 by 2 array.
After inverter (layer 2), and then Logical OR, (layer 3), that result is inverted, then used as a potential 'SET' signal, for Layer 5 flip/flop.
A first copy, at (t-1) time, is made, to layer 7 flip/flops.
With another layer (not shown), you get a current status, along with (t-1), and (t-2) histories,... at suggested variable rate, around 20 milliseconds per sample.
   (That's an 8-foot stack, of gates, if put all together!).

[RJSV]

This latest (photo) is the most advanced so far, as it simply allows for decent 'sunning', for charging up each (of 56) elements.
A helpful feature has the base come apart as two sections; each reinforced against weight of all those lawn lights. Plus I'm testing to assure that all those are getting full charge, each morning, enough to run normal at dusk.
   Free running, a signal quickly runs down a column, about 8 mSec.  This system is designed for synchronized operation, stage to stage.  Each pixel 'pair' is quickly combined, into a 'corner' signal, by Logical OR.  Then, this corner column has one latch, while adjacent column in the pair has another two bits latched, by synchronizing gates.  So all told this 'cube' module contains 8 pixel sensors, combined into 4, and has 3 stages latching those corner bits as older copies.  Very similar to bucket brigade logic, current state isn't latched until Q7 copies Q5, and Q5 copied current value, shift register clocked at 10 mSec per sample.  This info can then be interpreted for motion sensing, etc.

[RJSV]

This design has more open air, support columns reduced from 25 to just 5.  That wall of 28 gates
(4 by 7) contains the 4 pixels, for two corners, each of 3 bits storage.
  In front, you can see the partially stacked pixel pair for other corner in front.

[RJSV]

Here's an example, using various edge-detect methods, while keeping two 'history' copies.  The two copies, of the corner detect bits, are each timed at 10 mSec, so first copy at 10, and second copy is at 20 mSec. after current (4-bit) copy.
   An event, such as with a sweep of a flashlight,  can cause an 'ON' indication first on the left, then, moving rightward, a short pulse on the right side sensor.  Nothing this, just for the front two sensors, you have a bit sequence like; '00,10,01...' as that beam is swept rapidly across.
   While this perfect case seems practical, in use there would be, actually something like 4096 combinations, some that make sense, as to detecting direction of motion, many of the permutations or combinations of signal don't make sense, or represent a confused multiple sources.
   I'm figuring a simple, rapid hand movement in the range of 10 mSec, to cross a gate-sensor.

[RJSV]

Viewing that last diagram, representing stored samples of 1 bit for each corner (pixel pair).  That way you get into interesting territory, when discussing MOTION DETECTION mechanisms.  This set-up involves keeping a first and second (in time) copy, for the mainly 'edge-detect' type operations.
   So, with the 4 corners, the bit storage comes to 12 bits...; that's going to be 4096 different ways to express.  Labels are T0: (Current sample), T1 is (at 10 mSec. past), and T2 is (at 20 mSec.).

   Tried various light intensity weights, by simple distance from sensing cell: Consider T0 sample at
80 %, T1 at 40%, and, oldest, T2 at 20 % weight.
These being based on 100 % representing the internal comparator trigger (at PV cell=0.5 Volts).
You could have T0 and T1 'ON' and that would exceed the comparator threshold.  OR,... You have T0 'ON' (now), and T2 'was ON', for a total 100% this time, again exceeding threshold.
This way expresses how to approach using 'imperfect' or 'almost correct' data, for identifying simple motion directions.

[RJSV]

Thanks to ebastler (July 31) for digging up that video by Professor Shanhui Fan, of Oct 21, 2021.
(Ginzton Laboratory).
  Prof Fan talks a bit about edge detect mechanisms, which is part of the convolution and image recognition concepts for AI network.
My setup provides various copies, of single-bit status at each corner, or called 'Q1, Q2, 'etc as 'quarters' of the visual field. One point to make here is that, whether a full set of data points going back over (at least) several discrete time intervals.  Realize: those quarter portion corners simplify the data by logical 'OR'ing whatever pixels get active, so you are losing a bit of separation details, lumping all 4 pixel positions into one, per corner.
   But even that, simplified has a lot of permutations, which I have noted (see diagram showing 2 front corners and a single older copy that is 10 millisec older.). You could work through each possible state, of those 4 total bits, and 6 of them are clear to interpret.  Other combos not so much; consider the 'all bits ON' scenerio or the 'all off' variation, that make logical sense.  A couple of the variations are contradictory in interpretation so the whole set, of 16 possible combinations of present and past samples becomes burdensome.  This is the environment tackled by some 'deep AI', as trendy as that may sound (lol).
  In my musings here, I'm seeing some parallels with the 'Pooling' concepts, to reduce data to more 'symbolic' or 'stereotype', i.e
 identifying a mouth, nose or just a simple curve of some sort, in an image convolution.  Plus, here, with this 4 by 4 pixel array I'm encountering 'expansion' of data that needs to be analyzed due to inclusion of earlier bit copies.

[RJSV]

   In this picture, the columns lean a lot,...that's OK they will be secured as straight up.  You can see this 'first layer' (light sensing), having 8 gates, in capacity for 16 gates, if fully populated (a typical 4 by 4 array).
To reduce the data load, while experimenting, each pair of sensing elements gets 'ORed' into one pixel.  Spacing variations (non diagonal for this example), COULD be 1, 2, ,3, or 4 pixels apart...but choice is made to ultimately use just one separation variety, ending up with a smaller 2 by 2 array, (while experimenting with edge detect and with Pooling and Rectification.
That seems appropriate as this little 'network' has, also, some data bulk reduction, by crudely dropping or consolidating pixels (into 2 X 2, ultimately).
Then, similar (or, merely resembling) to neural nets, supplementing current (bit) states, by inclusion of 'older' copies, for edge detect; that dynamic causing expansion, of data needing to be analyzed.
   I think I have that correct (?)... That the neural system goes through expansions and contractions, along the paths from input to output, through the various layers.
   I'm wondering if in cases of contradictory inputs, if there is a mechanism for catagorizing in cases of 'Invalid input combination'.  One example of that, invalid case, could be with both front corners occupied (by user's flashlight beam), followed by NO pixels ON.  That does not indicate any kind of particular 'direction' resolved, while user sweeps the (top of array) with a flashlight.  Of course, there is, also, some valid results, but they just don't indicate a particular direction trend.

   By the way, the real-time action, of the digital portion, is to shift older samples over, (through 2 older copies), and then take current sample, of each of the corner 'Q' values.  When triggered, this continuous storage action, (every 10 milliSeconds seemed about right), the storage action will freeze or halt, allowing examination of each bit, ON our OFF.

[RJSV]

...AND, as appropriate for the base that opens up during component assembly, you can see; the right hand front pair (of sensing gates) can slide open and clear.  That's why that top plate is two pieces.

[RJSV]

   Picture here shows the top layer #1, (out of 7 layers).
I left a little space under that top layer, just for now to show the usual electrical interfacing is done in layers 2 to 7, by including an extra LED up top, actually piggy-back with the ordinary gate (#1) LED, so effectively the second gate receives light signal from both sources.
The way this works is for each rotary selector, user can dial in which source they wish; for a column (of sensor/gates).  While this only is the 4 'main' columns, of the 8, the other, 'Auxillary' column has other switches, for chaining both.  This way a user can dial in a 'CHAIN' Mode extending or encompassing ALL of the 56 gates.
   If you look at the top, see a wire pair protruding from the upright column; This brings voltage from the rotaries up, to cause the column top LED to be driven.
This electrical rotary selection is done for both LED lead wires, as many components are electrically separate; No ground or shared common (negative).

   One casual principal I like to employ, (especially when that's not a lot of extra work), is concept called:
   'MIB', which means 'Make It (your) Best', a simple marketing concept I've seen.  For that, I liked to spend a little extra time, cutting that plexiglass  top sheet, as neat and square as possible.  Heck, it's only a prototype, but...
  'Never underestimate the Marketing forces...they rule'.

[RJSV]

...it's a little hard to see, but if you look on left column near top, is wire pair emerging from hole in column pipe.  That is for the top driver LED.  Actually, there will be two of those wire pairs for top LED, for MAIN and for Auxillary columns.  That is considered one 'quarter' section, so it's one of four (corners).
Most combinations should be able to be dialed in, but straight and simple point to point (solderless) can be quickly done, also.

   This stuff shows a bit of the independence status of inventors;. Often an inventor has to delve into these areas, like packaging, or ease of use.  Actually, I enjoy those nasty MECHANICAL issues...especially with novel looking devices!  I've done a bunch of crude-rude adjustments, to life-style, as an Inventor!
Ever have to SUE, your own lawyer ?  (Yup, and he won).

[RJSV]

   There's been other views of this 'cube' and plexiglass top bracket (holding layer #1 of the gate stacks).
Hoping there is enough transparent, for daily battery charge-ups, in the sun.  Might be easier, just use a cardboard sheet, but then I'd have to dismantle things...before putting out in SUN to charge. (I'm waiting to see, if the gates, generally, get enough light, some indirect, for complete charge. Batteries are 2/3 size and at 100 mA-hr that's a pretty pathetic full-charge.
   The 8 stacks of gates taking over 1 hour to assemble, so I almost have more work in packaging improvements needed, VS. actual functional aspects, of DtoA converter, etc.

[RJSV]

   This current picture helps describe the situation;
   The whole 'series' network, of gate stacks, will eventually settle; to an alternating 'On, Off' pattern, (observing as signals going in downward direction, thru those Solar Garden Light modules.)
Currently, my recent re-assembly of 8 columns of 7 levels each, contains AT LEAST 4 gates 'spazzing', simply meaning the charge is so low that an individual gate gets into difficulty, switching on and off at a few cycles per second.
  Right now, it's 7:30 PM  California, just sundown, and a few more minutes gets fully dark. Then, all 8 columns are expected to settle out, into the On-Off-On-Off-On pattern in the 7 gate stack, of inverting gates.
   But NOW, (tomorrow morning), I've got to disassemble the stacks, and weed out the gates that underperform, in terms of chargeable 1.5 V battery.
Many years, patience, doing Mechanical logic, got me 'climate adjusted', to tricky apparatus, (Scotch Tape and rubber bands), so, I don't mind, following EDISON's phtolomy, on invention.
   99 .1 % persperation, in my view.  But, goody, that leaves (me) some territory, to reign over...
   King of the... (fill in the blank)...  It's not so bad, life in Silicon Valley.  Except food prices, skyrocketing lately...
Lol, (you gotta laugh).

  Anyway, the simple test, down through the gate stacks, is to shine flashlight and verify that the whole stack responds...by flipping state.
So, I note the bad spots, for the morning, disassemble the stacks.  Often, it's found that most failures are of battery ' falling' out from spring contacts (due to motion shock), so a quick fix to re-seat the internal 1.2 V battery.

[RJSV]

   Turns out; I took things too far, and package structure does not let in enough light..., except maybe for a couple gates up top of each column.  Had been wondering, if that pityfull 100 mA-hr chargeable niMh battery (2/3 AAA), was the limiting factor, for each daily Solar charge cycle.
Next, should also use better transparent 'loops', in the gate stacks, for better solar gain, as each gate already hampered, by taking direct light in very slanted angle.
I'm thinking adding approx another cm to each gate to gate spacing, plus getting rid of those clear plastic loops.

[RJSV]

   Some of this project maybe better in 'Projects' section, but it's all, mostly Dodgy...
Picture showing the array of column posts; these can pass wires, up through (pipe) interior.  Right now, I've had to shorten that whole mass.  The whole package, mechanically speaking, is looking pretty good.  Those columns support the components (garden light modules), that I've termed as 'gates', plus they block some portion of unwanted direct light, going sideways from a nearby assembly.
   Expansion of the stack size gets things up to about 17 inches, (1/2 Meter) height (was ~ 14 inches).

[RJSV]

   I really would recommend the Prof. Shanlei Fan lecture (thanks ebastler):
Please see post on July 31.  Especially interesting, (at video 44:00 minutes out of 49:00), Professor Fan brings up the situation, that computer scientists DON'T KNOW, exactly, how the whole process works; it's almost like attention is on, generally, how to construct a 'problem solving' network...but without direct reference to the problem material, directly.
Almost like, by analogy, a bulldozer built to move dirt, where the designers don't, actually, move dirt themselves.

[RJSV]

Picture showing Base Unit improvements:. Idea is to have a 6-position rotary switch selecting sources, for driving a column top LED.  Various modes of series connections can be dialed in, as in Column 3 output drives Column 4 TOP.
   Picture of (Terrier) puppy included.
   Picture of Optical 'SuperComputer' base included with puppy...
  A couple of places, along each 7-segment column, has some misc. cross-over, or other inter-gate wire connections, for having flip/flop or other customized variations, such as optical logical 'OR' gate function.

[RJSV]

   I have 'half' of an idea, regarding Optical computing elements.  In this case, needing an (entirely) optically resolved Multiply and accumulate, using light beams for either digital or also analog encoding types.
An 'Accordian Bus' (or; Piano Bus), is not a new idea.
But, for non-binary encoded logic, the idea is to use a long, 100 channel bus,... that being just in empty air, with 10 copies, of the Multiply's Multicand, which is a
'5' in this example 3 X 5.  Idea is to 'bogus out' or make invalid each of the terms, 9, 7, 6, 5, 4, and 3, while leaving untouched the transmission of  2, 1, and 0'th for a valid addition, of the 5 term, three times, in this case.
The assessment of that valid/not valid stream or linear array, is done at the end, with conventional electro-optics.  My idea is to (figure out) get a way to get one beam to influence another, and without the obviously useful electronics.

[RJSV]

Keeping in mind; there's no active components until the terminus, of hopefully a long string of multiplied...that way it's still efficient to revert to electronics, or at least some active optical element.
The method uses a third parameter, in the multiply of Multiplicand and Multiplier, I'm calling the 'Facilitator'.
It's actually, functionally the opposite as each facilitator 'ON' bit will invalidate that bit position.  Each bit, in a TEN bit word, has equal weight, (uncoded), but still notated from right to left.
   So a first multiply would involve a Multiplicand, '5', that is sent into the optical network by electronics, and looks like:.  '00001 00000'.  The other number, the Multiplier '3', is originally supplied in combination, with the 'Facilitator' bits, that de-legitimize the upper bits:
So, Multiplier X 3 is input as: '11111 10000', to be added in analog form.
   Functionally, it's as if the device is ready to stamp down '9' copies, even if this instance needs only three.
So, it's a tentative addition, but also one that collects the valid / not-valid states.  Each of the copies are kept separate, as the whole set propogates (at speed of light).  At end, there needs to be an electro-optic device, that will block, or discard the 'bogus' channel-ways, before actually physical addition, or analog Summation occurs.
   For second stage, in a string or chain of multiplies, the first stage answer is in the proper format, that being a '15' with upper bits flagging bogus spots (Facilitator).
One problem is, answer consists of 100 parallel channels.  In conventional hand-multiply, the answer must get split up, with some sort of method to deal with separate digits and overflow Carey's.
   The 'Zero' term, or bus position is needed for assertive logic, but must be separated out before the analog summing (node).
So, you can see, the overall Bus effect is analog, but can be sent piece-wise, in those separate channels.  Of course, there also is (optical) decay effects, mostly in diffusers, and also a need to normalize signal strengths (actually packets of photons).

[RJSV]

The optical processing thing, here, has an interesting quality, in that you can't actually KNOW what you have...but you can keep on adding to it!
   Considered in columns, where the structure is vertical, top-down signal direction.  So the 'bogus' or non-valid columns are marked, either by higher intensity coded, or by way of parallel tracks or pathways.
Asute readers may wonder...there is no there, there as far as hard-coded answers, like how 3 X 5 gets to '15' as an answer?  The answer isn't resolved, but you CAN apply the valid terms, as analog quantities.  For absolute conversion, an A to D conversion is needed, (electronics).
   When doing most mid-range calculations, a two digit or 0-99 range works out. The qualifying 'Facilitator' flag there, applies to a whole word, in the piano-bus of ten signals.

[RJSV]

(Diagram showing partial term Summation):

   Reading as a signal set that propagates top-downward on the diagram page, is an earlier multiply;
   3 X 5.  The free-space 'BUS', or vertical lanes are read,
right-to-left, with the inhibited lanes shown also.
(Those inhibited lanes are 'permanently' there, until electronic shutter (LCD) blocks each bogus signal).

   Next, a new signal is brought into the stream, that being the result of multiply of 3 X 2 (=6).  That additional set of lumens is special case, having a same Multiplier, being also then with same column structure, of non-valid signals.
   The total then, in the analog stack, is 21 lumens, with 6 of the columns blocked.  Obviously, such an accumulator in digital form needs a range up to 200 counts, when doing a total after 2 multiplies.  The maximum would be:
   9 X 9 = 81 plus another 81, for a digital total 162, literally.  That being with using somewhat arbitrary 1 lumen 'weight' per digital count.

[RJSV]

   Here is my suggestion, for optical BUS actions:
(Also, see diagram).  The input electronics could be doing set-up, for having floating point related, partial multiplies.  For example, a 'stack' that, in series, performs     200 + (5 X 1) + (5 X2) + (5 X 3)...as for the number 1234 X 5, where you have a partial sum.
As shown in diagram, the electronics drives LEDs for each lane, in the 'facilitator' BUS format.  That is the input for the decimal Multiplier; '5'.
   The Multiplicand, and any stages of new Multiplicands, should be in the positive-logic format, being occupying 5 of the BUS conduits, by simple count (not binary coded).
   Also included in the diagram; is shown how a value like '5' can just simply be spread across the 5 different conduits, simultaneously an analog value, weight 5 (lumens) total, if consider each light flow channel as having '1 Lumen'.

   I'm thinking perhaps could fit (one) of these passive adders into 1 mm., or less?
For the column qualifying signal (BUS), that will be an associated paired, with each data term (column).  Result is a Parallel Adder, in passive optics, with conditional blocking of non-valid accumulator columns.

[RJSV]

I'm thinking something like, 10,000 separate multipliers, which could be 100 by 100 mm.
Diagram shows, a BUS having 5 lumen, and is only shown right-justified for convenience.
   The diffuser (hopefully) spreads the light out, and evenly, across 10 new 'Laneways' or light conduits or paths...
Then, that re-build word can be subject to blocking, of specific terms, mapped one-to-one.  So, for example, it is 3 X 5, then the Multiplier, '3' gets a Facilitator word:
   '1 1 1 1 1 1 0 0 0' and that flags as not-valid, the columns coorespond with; '9, 8, 7, 6, 5, and 4'.
   The re-build word, is ready to apply that, so the end result is that the full Adder occurs, but only after the electronics activates (LCD) blocking of column.
Full-Scale is 0 - 999 or 3 decimal digits.

[RJSV]

   Working with the passive computing structures is interesting and fun...
Sometimes it is useful to be able to 'recover' an ordered set of BUS signals, although when input is from LEDs you can have the driver electronics do the heavy lifting (to provide diffuse weights, across the word).
   Result is diffused across entire word ; and that way provides the input needed for a multiply.
While the amplitude value of the light beam is reduced by a factor of 10 for each piece, this variable is only introduced once, (each), in the chain of many calculations (multiply/accumulate).  So the reductions there (are not cumulative).

   Diagram rt. side shows a system of reflective 'tabs' in the BUS channel, resulting, again, in the Word-Diffuse format needed as input to passive multiply (structure).

And...Bottom of diagram shows a single conduit feeding a divergent and varied area (conduit), that results in an even response across all elements of the BUS Signal. Showing 5 elements for simplicity.

[RJSV]

   Still chewing on this latest 'improvement', gaining the ability to drop off those bad columns, and go ahead with the full summation, BEFORE resolving the valid / not-valid flagging of columns.
   It's possible to get the lateral or cross-column summation(s) done, but as a set of ten potentially valid results; each of the 10 possible final multiplications can be done, in parallel.  The signals must be split up, into 10 copies,...of course with reduced amplitude, then can be added.
Out of the 10 possible outcomes, the correct result can be distinguished, by the stack terminus electronics, and that electronic section is not required to perform the lateral additions, column to column, as the optical pathway gets to add everything, in-line.
That way the electronics function is reduced, to shutter control, or light deflector control.
In that example multiply, of 3 X 5, the 3 valid columns, col 1, 2 and 3 each contain '5' lumens (of photons flow per second), so the addition result is 15, ignoring any issues with decimal points.  The other columns in this example, do not get into the (optical) summation.
   AND, by the way, this functional gain comes with high price, as ANY structures following will need to be duplicated TEN TIMES!, to cover all contingencies.
   It's an interesting project; Digital Multiply where the words used can also be analog: An analog multiplication result, but that has synchronized or one to one mapping, with a digital signal 'Facilitator' word.
And also with unchecked analog Summation (no set word size).
Very interesting.

[RJSV]

   An electronically shuttered column set could make for a fast digit multiplier,...that is a hybrid, digital addition, but of some analog value.  I've got a somewhat arbitrary range in mind; that is zero to 1 volt.
( 3 digit decimal 000 through 999).
Suppose a fast multiply, could do X 7, on a sensor input value, with some more terms added in, to the analog total (columns merged in summation).
That could be; '(7 X 3) + (7 X 4)', where that '4' came from some brief memory device, but then a larger stream that could include; '(4 X above result of 49) for a subtotal 196.
Then, perhaps, a constant of 149 gets input, from some other nearby calculating subsection.  It has topology similar to river structure.  The electronic portion sets up the LCD shutters, ( or other, faster options), then leaves that 'transient' structure for a time, to process.
   One advantage, of the blistering optical speed, to resolve a multiply- accumulate outcome, is that any sensor signal going through separated portions, won't have any significant issues with being different (slightly) valued, and thus eliminating need for a sample and hold front end.
   Using the thousand counts range, any comparator would best be at 1/2 Volt, or 500 mV., I figure..., out of the full, 1 Volt range.
Of course, the steps are 'linear', 1 mV each, but actual optical hardware maybe only (sometimes) close.
The 1000 step range does pretty well, when accumulating up to ten multiplies (that's 810), and the subsystem allows for 'constants', like '149' to be tossed into the mix (summation, to the AtoD.)
Output would be created quite rapidly, at light speeds, for each AtoD convert, at the column set terminus.
That apparatus expected to be on order of 50 cm (tall).

[RJSV]

   Filters as sensor front-ends can illustrate the set of multiply and accumulate actions:
  This first diagram shows a typical air bourne sound being translated to light beam angle. A partial obstruction before any conversion might help provide modulation of the constant light beam.
The first cone is to concentrate the air pressure waves of the sound, onto the cone or diaphragm for variably reflecting some light beam.

[RJSV]

   The diagram shows an audio filter front end, skipping completely any electronics based parts, a typical filter or low-pass relationship can be using a short delay line technique.
   First receiving cone, directs sound pressure waves into that tube...; 12 feet long for about an audio delay of 40 milli-seconds.  The other 'signal', direct, then travels to the multiply unit, along with the 40 mSec delayed sound (that's also decayed quite a bit).

[RJSV]

   Of course, there are other, easier ways to get some ratio, like here it's 1 TO 0.5 ratio.  But here, to illustrate, the starting and ending Lumins are close enough, to allow chaining, some.
The values are input direct (currently, no delay), multiplied by 6, and a 10 mSec delayed signal, at 5 X.
Because of the divide by ten side-effect, those become
times 0.6 and 0.5...
   But the whole point is, a total 16 Lums comes in, and total 9 Lums gets output, so the chaining of stages hopefully won't bring the signal down, excessively (like ÷ by 10 would, if at each stage).
   Those values shown, cartoon style, are valid, and ready to be summed, (laterally), as the LCD shutters are blocking the columns that aren't part of the conditional addition (summation).

[RJSV]

   Going to a system, 3 by 3 dot format, allows for a 'shutter' that admits 1 through 9 total little squares of light, (or none, for zero).  It starts to look like a light diminishing filter, in various ratios of signal decay.
For multiplication, you've got a pattern, the Multiplicand, and that gets transmitted thru the tailored decay, as a ratio to 100, such as 24 / 100.
Experimenting with concept of analog BUS style, having a high digit, and a low digit, roughly equivalent to decimal digit structures, and having 'interpreted' weights, for summing purposes, while each 'digit' or decade position has similar, or non- heiracical relations...That means the actual average level of an analog channel might be same or close to other channels, while interpreted 'weight' might be as 'small character/ big character' similar to decimal 'ones/tens / hundreds' stacking
That way, the most feeble channel has strong signal, along with larger represented values, from mid-level channel.

[RJSV]

Picture Shows:
   It's ackward to get last, tenth LCD shutter element in,  that 3 by 3 array makes a nice square shape, of active 'light valve' elements.  A 'tenth' little square allows for doing a '99' output, but also a number like '52' would have a two worth of light admitting opening, supplementing the higher-weight 'tens' digit (channel).
If 10 actual pixel locations are used, then that's going to use 30 pixels across, to do the 3 squares, plus any spacing...
   One key, is that the lower represented digit is still strong; being 10 X too big, by weight.  So conversion to actual template involves reducing that, before all is merged.  That '52' being '5 regular squares', plus 2 of the little (ten times less).  Actual filter performance, for light intensity or amplitude, would be 52 out of 100 as a ratio of input to output light

[RJSV]

...This other picture features an older light panel, salvage bin now, but was inside a nice portable TV, vintage 2010.  The TV Screen back light panel is approx 8 inches wide by 3 inches high

[RJSV]

   At any rate, doing things like this, mostly motivated by the advantage of having more resolution, you could have something like;
   (Instead of just '6' X '7' type of one-digit resolution),
   149 X 52 (that's approx 7500)
For that, in a binary range of 0 thru 8196 (or 8 k), that's going to be 13 bits AtoD conversion.  So, by keeping 10 bits, converting as 0 thru 1023, or better thought of as 0 thru 999, decimal, you've got the better accuracy, 13 bits, in your accumulating light beam, with a 'truncation' of 3 bits at the final, AtoD after summation.
That helps keep rounding errors out, as the Multiply-Accumulate 'stack' has many terms, for efficiency (hopefully).

[RJSV]

Oops, sorry I jumped the gun there; it was supposed to be limited to 0-99 each,...; so that '149' is too big.

   The format cannot be sustained down the stack, but rather it is an input format.  After input, and summation that is allowed due to the shutters being closed and only open on valid columns (in the conditional summations), after that summation the BUS format must revert, to a zero through 99 type 'wide bus'.  Ironically, you can manipulate the number, sending it through yet another process...But you cannot know the value...; It's just some pile of weights, that's all been blurred and re-compartmentalized, into 10 pieces..., for any further multiply and accumulate steps.
   So, the 3-digit 000 thru 999 in the form of 'Hundreds/ Decades/ Ones', is really a format for input; as a DtoA production.

[RJSV]

   Picture features a 'wanna-be' BUS style, perhaps...if I can figure out some coherent approach.
   Idea is to have separate analog channels, one for each decade, staged much like conventional decimal numbers, X 10 for each next column.
   That 3 by 3 configuration gets you up to nine...and then you might also need another '9' set of loose digits, meaning that you would be combining 9 (X10) + small digit X1.
   It's pretty vague, right now, but has a 'Self-Similar' structure, when going down into lower weight digits / columns.

[RJSV]

   Going to the bigger value, like '52' for example, allows for pushing the limits on resolution and accuracy (of some very very fast multiplies).
You can see, in diagram, the basic light 'valve' blocking or admitting light elements can be all arranged in a line, like the 10 piece BUS was, but starts to get unwieldy packaged that way...
That's why the emphasis on a more square or round shape, all condensed together.
   You might notice; this particular structure would be for a constant...A constant multiplier, like '52' in this case.

[RJSV]

This third diagram, today, starts to show the type of game to be played:
   Idea is to pre-position as many BUS signal blocking flaps as possible, so that the column of multiply and accumulate actions are as deep as possible...(so that only the fast calculation, of multiple conditional adds takes place).  That part is fine...but only with condition that the 'lateral' summations only include valid columns.  Funny thing is, you can still proceed, down that column, even when not knowing or resolving what you have.  In this case now, you've got a 2-digit multiplier, going against a totally wide-open analog value, as the multiplicand. Some preliminary thoughts there are to use, perhaps, 14 bits worth of analog value, but use a 10 but converter.
That way you've got some extra capacity, in the two numbers to be multiplied.
   Oh, and at the finish, of any progress down the calculation column, you might have something like;
   5, 5, 5 in columns 1,2 and 3, in some other multiply, plus a '149' constant added in, to column #1.
What this means is you will see:
   '5', '5', '154', ...which of course is unbalanced, or not evenly distributed across the analog columns.  The process that I have (attempted) been describing, would lateral sum every valid column, and that ends up as '164', which should be dividwd up into ten element pieces, of approx. 16.4 each.  That way the vertical summations can proceed, down the remaining elements in columns.
   Confused yet ?
Welcome to Rick's world...

[MK14]

Bold and font size change made by me, to highlight the bit, I'm responding to.

Here is a view of one particular 'switch', or Optical 'Gate', I like to call it. Takes time, but making secure fixtures eliminates some of the distraction, placing various light-operated pieces in relation.
This piece has only the IC, battery, and LED / reflector, while another table-mount piece contains the little square solar photo-voltaic cell, also glued for upright operation.  All this takes dedication, over stretches of days, so I try to make sure that's worth (the extra trouble).
   Main problem is, there is some mechanism, not a capacitor, but something is creating a delay time...maybe could be the solar cell itself.
(Whenever I try Google 'Solar Panel Impulse Delay Time'...I get some results like:
   'Three months lead time, for Solar Installations, in Midwest...'.
(That's useless).
   But in the edge detect optical circuit, it was supposed to trigger on (just) the falling edge, of light beam input.
So I have to figure out, what's going on with the switching action, as it appears there's a delay, before a new surge of light will create a response, from the circuitry. Since it acts in invert fashion, the newly ON light input causes the circuit to flash it's LED ON.
But if that response is delayed, then my circuit will flash on that (rising) edge, of the input.

I'm NOT sure if you already got an answer to your solar cell response delay time querry.

The following seems to say that less light, causes the delays to increase.  It also seems to hint that it can easily take 250ms for a solar cell to respond (acually it seems to mention 4 Hz).

Source:
https://www.nrel.gov/docs/legosti/fy98/23878.pdf

The response time of PV devices to chopped light can
be a problem for electrochemical cells. Similar to results
reported elsewhere, chopping frequencies below 4 Hz are
required to keep the waveform from changing with frequency
[14]. This effect is more pronounced at low light levels and
in the infrared.

Modern solar cells, are somewhat different types, which may or may not, affect the characteristics, that paper seems to mention.

[RJSV]

   Here (please see photo), is some glimpse, of design considerations for a practical optically operated analog BUS.  While doing a wide bus; of 100 signal partitions (I.E. uncoded bits).  It lends itself as a better shaped format, keeping the 10 BUS lines in a centralized or circular - square organization, better to use while diffusing or making signal (cross section) uniform.
I'm not confident, exactly, yet, but making progress on this whole summation column method.
   Notice, I've simply tried methods to obtain 10 signals, for a decimal BUS read, and various size adjustments put each individual element on equal footing, in regards to an even (as possible) diffusion of total light, into a 'portion' for each conditional addition column.
I did the 5 decades, in the number '52', while the 2 'units' value also are included.  Actually I don't like that; as it mixes between the weights, so that format is a little 'shakey', but readers should be able to realize and follow the function...(whew!).

   It can be disorienting, doing inventing / building inventions.  There is no obvious  set pattern, in the novel stuff...(but that's by definition).
I believe that one of the helpful qualities of a technology involved inventor is TOLERANCE, ...tolerance for unpleasant conditions, (hopefully transient!).

[RJSV]

   So, taking that input BUS, the format has to be changed, some, for the column oriented conditional additions.  Diffusing and even spreading, followed by introduction into a 10 portion light conduit would the number, like 52, to be split down into ten pieces, 5.2 each, or as close as practical.
   The end result 'square' might necessarily have uneven looking divisions, in order to deliver same amount to each of the 10 conduits.

[RJSV]

Mk14: Regarding a delay time.
  Thanks for that ref., I believe the switching time, as inverter, was for the (solar cell with switching IC, and battery.). That way, (maybe) the real switching being done is by way of using the solar ev cell voltage, at some comparator level, 0.5 or half-volt, I believe.
   That's why, using a series string of those little, dollar store type lights, can, actually pass MUSIC... Although wildly exaggerated,...but it does work, to some semblance; The sound passed consists of punctuating 'Hiss' sounds, to the 'beat and cadence', of the music.  Plus, some of the mid-range sounds make it through, down a series line-up of those 'gates', that being the inverting action of the solar lamps, each sending light to the next, in a series string, (of 8 separate solar lamps, acting each as a logic inverter).

[RJSV]

Also, wanted to mention, that it is believable that the little round solar cell / battery Garden Light,...that the PV Cell could take some 250 milliSec to toddle it's way up to saturation.  But I'm no expert, don't misunderstand.
That's PV Cell volts ramping up, while under load, charging the AAA battery.  So, you have some kind of ramp up time, to full peak...( ?).

[RJSV]

   I figure to have a thousand multiplying processors in 32 by 32 Array, and here's the numbers outline;
   Using a basic 4 pixel wide LCD square (4 by 3), that could fit into 10 pixels, including border.  So, a 3 char by 3 char array, covering unit weights of 1 through weight '9', (in light intensity), would be 3 X 10, or about 30 pixels across, to implement a light emitting 'square', (or at least a light valve, for whatever light source.)
For that, an array of 32 across would use 1000 basic pixel spaces,...about right for implementing an experimental passive processing structure

   For a signal processing 'session', lasting 100 mSec, an electronic CPU or GPU will pre-arrange the configuration, for a burst of utilization, doing fast bundle-jobs, of multiply-add nature.
Envisioning up to 10 multiplies, each, for example;
   '21 X 56 = ' and being accumulated, into 14 bits equivalent, for example.  That being a total AtoD count of 16 k, and (estimate) using 10 bit Ato d, at high speed.
Excess range is really just an analog accumulation, of light intensity, but rough equiv. voltage estimate range of 1000 counts, representing 0, 1 mV through 1 volt (0 thru 0.999 V).

[RJSV]

   The really interesting part, from here, is that, after multiply and accumulate, of 10 separate numbers, such as an example of direct sensor inputs, that number rapidly accumulated can then simply be continued, as 'summed' appropriately for a multiply of the whole result...in a continuation, at optical speeds, into some more process stuff, meaning in this case that you don't need to use the AtoD process, as a terminus, yet, but rather, it is possible to re-format, as long as non-valid columns have been blocked, by the set-up process, or pre-process.

[RJSV]

   Looking at various BUS formats, the 'Harmonica', or Piano BUS style encodes as binary-looking 'bits', but it's a one and only one, exclusive type of code..., or actually an 'uncoded' signal.
The right-justified variation is just about right, for doing outputs, although zero gets a little strange.  That's when you'd like an active zero form, of the raw signal, for clocking or pulse recognition.
   But, doing weights-only, this system produces 'Stamps', very reminiscent of video or graphics stamp blocks.  Each of those little squares contains an even amount (of light lumens) and thus the multiplication action happens...by way of multiple addition right there in the 9 squares of the 3 by 3 array.
   (Reminds of the Pop-art Warhol photo art, where the face of Marylyn Monroe gets repeated, in little cells, across the art-poster.)

[RJSV]

   It's easy to read the diagram, (incorrectly), by seeing 'bits',...Rather, it helps to view as multiple copies, in video or raster outputs, or as a set or 'sprites' that come into the big addition going on.
   Looking at a 3 digit number, each can be with separate analog channel. That way the 3 channels, being to separately convey 'ones', 'tens', and 'hundreds' as typical decimal, but with some 'extra' help by using better, higher amplitude, in the lower analog level conveyance.  So, the lowest digit is actually 100 times too strong.  That way that individual signal channel has enough to work with, making multiple copies.

[MK14]

Those patterns, remind me of gray code.

https://en.wikipedia.org/wiki/Gray_code

Even though, they are not really related, to what you are discussing.

[RJSV]

(Thanks for replies).
   The method to read all this, is to separate out a 'Digital mode' for the multiplier digit, fairly standard on-off, at least the signals.  For the other half, the multiplicand value; that's the part that's going to be analog.
So seamlessly intertwined that it's very easy to get confused...But the 'weights' of the multiplier are a set that EXCLUDES zero; no weight means no actual conditional additions, but the whole business of a zero weight signal is messy.
Actual, literal meaning, is like a set of windows, where a number like '4' means that an input value, like '7', will get repeated, each place it is enabled, in that 3 by 3 square shown.  So the multiplier is like a mask, in graphical terms, allowing equal portions of light through, being the light from the multiplicand, (split into 10 equal portions).
Like an old stamp and ink set, but the image being repeated is actually blurred or smeared so as to be in a format that can be further used as a multiplicand, very similar to a fully formatted multiplicand might look.  That is, with right-justified 'origins'.  Doesn't matter, (I think, lol), as either way, a conditional multiply will involve mixing EVERYTHING together, then (evenly!) dividing back to 10 separated columns...
   Down a bit, on a fuller computational column, would be set of LCD 'flaps', closed for the transient duration, of a session, like 100 milliSec. and that feature would keep any summation as valid.  So for that case, is an advantage, that the optical-speed computational 'column' could further proceed (down) through more action, such as multiply everything by 4. 
It's when the designer has run out of the fixed / predictible multiplier(s) that the electronics must resolve thru AtoD convert.

[MK14]

would be set of LCD 'flaps', closed for the transient duration, of a session, like 100 milliSec. and that feature would keep any summation as valid.

You might find that LCD 'flaps', have a fair bit of (light) attenuation, when they are supposed to be fully open (off).  Also, you may find that the LCD 'flaps/squares', pass through some light, even when they are supposed to be fully 'Black'/Opaque (on).

Additionally, LCDs tend to be somewhat (relatively) slow, so 100 milliseconds, may not give (especially a low cost, simple, non-optimized version, salvaged from something version), brilliant (ignore the pun), results.  Finally, the LCD screens polarizer, may also worsen your results/success, in various ways.  Such as reduced brightness/contrast (compared to something which is genuinely fully open or fully opaque).

Faster/fast LCD panels, are possible.  But harder to source, and possibly more expensive.  Even then, they tend to be fundamentally, relatively slow, compared to many other things (in electronics).

[RJSV]

   The method, of splitting '10' pieces, equally, and then keeping or blocking each, has a 'circular' feel to it, (as if any progress, from the multiply has been lost), it does have a useful looking quality of sticking near to some moderation.  That way a string of multiplies doesn't grow out of hand, in hugeness.
   In this, suggested OPTICAL analog the form of 3 digits is also adopted; each analog range channel has same value range, actually.  That helps any signal to noise ratio, but more importantly the fact that a signal will be further split up, by X10 factor, makes for the helpful suggestion, to start at 10 times 'too high', in the representation...but that fits the use very well.
Of course, the method(s) require a lot of excess, or unused 'light', and so disapate more power.
   The investigation, of how to do 'carry', after decimal multiply...(in this case, multiply against an analog value)...one way is to always, unconditionally 'carry' over a one tenth portion, which is actually hilarious, because (I've been) search for what to do, with the extra tenth, left over from multiply. !
So, a multiply like '9 X 9' is 81, which would 'carry' enough to function.
Problem there, though, is to always leave the former column with LESS, as you've moved some of that, up to the tens column...gets confusing !
For now, calling the 'next' column over, a
'Macro-Column', to distinguish.
   Tossing 1/10 unconditionally, over to next lower column, gets you (either) a carry-over, or, just an analog value that contributes, at correct value for the setting.
Result works, but is not in a usually expected format.  Some of an analog value, for instance, could be reduced, and then placed into a higher value column. That's because each lower decade column is 'too big' in amplitude.
   Another detail: might need to accommodate more than '81', might be some more overflow-carry, (to need '99' carry-over.)

[RJSV]

   I think you were trying to say, (Mk14, thanks), is that this conversation is reminiscent of 'Grey Code';  mildly suggestive, that serial data experts HATE long stretches, of 'dead' line time... That's instinctive from radio operating days.
   The optical equivalent, involves how to, effectively transmit a 'zero', in an active way, preferably.
In a (hypothetical) weighted word, on a BUS,  the zero case has no analog weight, but is very important, as a digital token.  This means, that, for example a '20' has that zero symbol, but it is as a place holder, which is different from a 'count'. A very subtle point, but ..
   Another fine sticking point has been the appearance of 'nine' squares of light, to represent values, in a decimal system...No end of confusion there !!!
But it must always be back to a X 10 relation, your x1 symbol must be X 10 across each column.
Of course, the '3' is '3/9' ... of that set I've shown, of a 3 by 3 array, but that is, further a block meant to represent ' 9/10' of a decimal number.
So, combining that math, it still works out:
   '3/9 th X 9/10 ths, is = 3/10'
So the point is; that array can represent in terms of tenths, not 'ninths', as long as carefully about use of area.

[RJSV]

   So there the delightful feature, that the digital summation can proceed, but on the next column.  This means that no data is lost, only that the data, or 'lumens' is accounted for, in the next column over.  This is possible because the format, of the lessor column, is with having 10X too big a quantity, relatively, but in a separated BUS system.
View it as an alternate way, to express that 'weight', into the system.... usually we just do it, but this way, you can hold off..., depositing the same amount, (of light), but just into the next, higher column...
If a lateral sum is OK then, then that subsystem can assemble and sum (addition) everything, to one big analog value (12 bits).

[RJSV]

   You can't SUBTRACT the analog light values, but you can take a 'proportion', or split off a ratio proportion.
So, with an amplitude value of '142' as example, that arriving light could be split, into ten paths, each being
'14.2', as evenly as possible, and 1 of those paths diverted, over (laterally, or X10) into the next power of ten column, or 'macro-column'.
This action gives a multi-digit multiply approach resembling regular 'carry-over' as the early school math teaches, to carry a 'tens digit' over, after a partial multiply. Doing, say, 9 X 9 = 81 suggests sending the '8' portion over...; over to the left to be tabulated in that 'tens' column.
   In this case, optical BUS, the carry-over could be 10 %
 and unconditional, but would also do carry-over of a number like '8', where the action is to carry over a '0.8' to the next higher macro-column, while leaving 7.2 n the one's column.
   Did I mention this shii can be confusing
   The expected actions would have been, to keep all of the (light quantity) in the first, lowest column, the 'ones' column.  But the total quantity is not lost, it is just moved over and gets totaled in next column over
   Now, as to magnitudes, the lowest weight column is physically separate, and does not match, physically, being 10X too big, in magnitude.  The consequence of this is that a carry-over, like the '8.1' in '81' can be easily put through a divide-down, by 10.
Actual is 0.9 X 0.9 = 0.81 and so the actual carry-over is 1/10 or 10%, and that's = 0. 081 literally.  That sizing fits perfect into next column ACTUAL amplitude, as a carry, albeit a little different from a purely single digit, it's expected to be, '0. 08'.
   Not really that confusing, just new...The total light quantity is simply done differently, but result or 'summation', across laterally, across the bottom of column, should always be same.
This method is shown, in a few recent posts, where a number like '0. 184' is expressed as '0.1', '0.8', '0.4'.
That's an amusing variation, of course needing to keep the three separate, and need to attenuate the low digit, when doing any full summation.

[RJSV]

...I'm not even sure, if not fooling myself, here; The 3 macro-columns absorb and carry any light downward, each column in simplicity is just a defined 'lane', pointing downwards.
   The attempt being, to operate a fairly normal looking multiply, of multi-digits against each other. Thus the thought, to 'RELIEVE' any overload, of a digit (column), by doing conventional pencil and paper 'carry', to left, thus keeping your current digit limited to 0 through 9.
But in this situation; Who cares ? ...Since any of those 3 decimal columns will carry, who knows how much light quantity...?
But at least that option is possible, and does do some relief or control, on max. light capacity, for converting, etc.
Ultimately, all those summations, down each column, and then laterally (close proximity mixing in downward direction along BUS path), will create a decimal total, like '184' lumens, for Atod convert.
Likely actual numbers more like 0.184 Lumens when all the amplitude numbers are run, with more certainty.

   Viewing picture, a more 'conventional' paper and pencil method, keeps the columns separate, but also only 'carries' the high digit portion (like the '2' in '27').
Interesting, this (equivalent) method brings over enough to avoid overflow,...but who cares as you can't even know what's there...until AtoD converter finishes.

[RJSV]

Here is view of that unconventional carry-over.

[RJSV]

   I've attempted to run some numbers; the propagation delays, down that stack of individual transactions (multiply and accumulate).
   Getting on the order of 500 pico-seconds, ranging up to around 1.6 nano-seconds, which is loose ballpark for apparatus with 50 cm path lengths.
I've estimated, 7 multiplies, with then being blocked from further progress, until (electronics) control CPU can get the proper 'flaps' into place, for blocking unwanted columns.
After that, moving further down the stack, I've put another 3 processing stages, each doing a multiply and accumulate (addition).  When flaps are effectively in place, the lateral or horizontal summation is considered valid.  Keep in mind, optically that process starts right away, or at least very soon, compared to the time it takes to 'close a flap' which just means an LCD pixel cluster.  Suggesting a 4 by 3 pixel block, for a little more light amounts, per element.

[RJSV]

   Picture shows a stack with 2 bursts of the multiply and add series of calculations.  The design goal is to get as many stages included as possible, for the very rapid optical process...in order to exceed that speed conventional electronics ALU is capable of.  So, the more of those, example, multiply by '5' digit multiplier, the more the better, as the LCD liquid crystal takes time to close or open, in preparation for AtoD reading, as the light beams perform the calculating (see also prev. explanation, on the conditionally used columns).
   You can see, I've tried to imagine / illustrate that stack timing performance.  Other folks, apparently (Professor Fan at Stanford Univ.), are examining the technology from an energy use point of view.
   In the picture, the green line, traveling down the page, is to represent how the older method was intended to track the validity, down the columns, but it's simpler to just write directly to the LCD light blocking, as CPU already knows which summation columns are not valid.  The older idea was as a 'live' bus signal...I.E. the Facilitator word, which could be set by misc. processes moving down the whole stack.

[RJSV]

   Apologies, to any of you experienced in
 Opto-Electronics, as I'm somewhat a newbie...so I'm not pretending to be expert, here.

   I've been self-labling some of this as a
'HILL-BILLY SUPERCOMPUTER'; which is about the behavior (of light) in simple gross or bulk 'beams' and usually without much heavy physics.  (Prof. Fan of Stanford Univ. does the heavy physics lifting & math, according to the YouTube videos I've seen.)
I've got limits on capabilities in physics, but lots of experience with various parallel BUS set-ups.  Industry is almost invariably binary logic.

[RJSV]

   I was pleased to realize that it IS possible to get close to 'SUBTRACTION', while doing math with controlled light beam's amplitude.  That is, a ratio like
' 9 to 10 ' or ' 1 to 100 ' can be set up, similar to the preceding example of using unconditional separation, evenly, using light guiding conduit walls.
   The Stanford researcher, Professor Shanhui Fan uses the term of 'Processing using physics, such as diffraction effects'.
I like to use a similar action descriptor, of 'Processing by BUS' which mainly refers to structurally modified bus lines, such as a rightward shift, among BUS columns, to get a value change, of amplitude value.  That's a tantalizing functional advantage, as compared to contemplating subtraction of light intensity.
   By doing ratio-based, and unconditional amplitude reduction, it's possible to 'count' those ratio portions down, while possibly using the set of values as it 'decrements' the number.  Can't conceive any way to detect a zero ending, in typical FOR-NEXT loop style, but existing techniques for coding an 'un-raveled loop', by simple listing each iteration explicitly, can be used, in a stack of optical manipulation elements.
That is, in cases where you'd like to use the iteration count as part of some calculation, on each loop iteration.  The way to do that would be to split off some light for the current processing element, from the 'iteration count stack lane'; use that in the current element, meanwhile the main light conducting lane continues down, to the element, in your unraveled For/Next line of processing element stations.
For example the structure could 'process' each in a series of '9, 8, 7, 6, ' etc and all of it unconditional, where that iteration count is sent over to some other module, as input.
   Doing that requires a simple series of reflectors and partial reflectors, for manipulating your light column.
By analogy, very much resembles the bit-shift instruction enabling complex operations like divide by 4, or multiply by 8.  This applies to whatever BUS type, but here the 'unit weight' BUS is favored (over typical binary weighted).

[RJSV]

   Here is a view of that optical BUS shifter, (although decimal BUS has ten lines), that moves each column over, changing positional coded notation..., as cannot change a simple 'amplitude', by subtracting light from the bundle, in perfect integer form.
   Of course, here the units weight BUS is used, rather than binary weighted columns.

[RJSV]

   Implementing a FOR-NEXT LOOP is holy grail in passive computational structures.  One helpful method is using the 'unraveled' loop code analogy.  But even the decrement and test is only partially obtained, where the individual BUS line shift-overs used as substitutes for (active logic) decrements are the first part of any conventional looking FOR-NEXT.  It's the active test for zero, or for some other end point, that's the problem.
   One possible solution is to let the (unrolled) loop repeat regardless, or unconditionally, and exert control on a parameter, like the For-Next step; decimating on each iteration, until it's just an 'empty' set of operations.  That could be, for example, a parameter that ends up zero, added to the light beam, ...effectively being that the loop functions are expired, even though the unconditional loop keeps circulating.
   A design could utilize small mirrors, for having one column, 'folded' over itself for compactness, but that extends the effective length.  I'm thinking, 15 cm long each, and with perhaps 20 runs like that. Something like 100 individual 'loop' like iterations could be done that way, but please note THIS AIN'T a micro-scale!

[RJSV]

   The program step manipulation in any FOR-NEXT loop is the stickler, as there really is no program step address (register), it's all just physical progress through each series item, in turn.  Any other, separate function would be integrated with the FOR NEXT structure (just described), as a serial series of 'stacked' lines of elements, stacked or folded, for packaging convienince.

   What's going to be super-helpful is obtaining some expertise on a Solely Optical output function.  If some physical output or device can receive  control while skipping any electronics AtoD then that makes for some real speed / power savings.

[RJSV]

   It's really a challenge, to attempt as close to an integer decrement as possible.  Certainly, with the multiplier in this suggested style of analog 'stamps', with the multiplier being digital as a discrete integer, I.E. whole, discreet quantities of the Multiplicand are transfered.
   Then, you have the multiplicand, a wide open analog quantity.  Exploration of substituting the modifying function that IS possible, (vs. integer decrement), one choice could be:
   Multiply by 8/10: The downward steps would be:
   { 9, 7.2, 5.76, 4.608...} which could be considered as too little, compared with goal, to closely look like an integer decrement; { 9, 8, 7, 6, etc.}.
  Using multiply by 9/10 each, the sequence w/be:
   { 9, 8.1, 7.29, 6.561, 5.90} which you can see, gets down to '5.9' whereas a straight integer decrement would get you down to 5.0 (integer).  So, that choice of
   ÷10 and X9  could be deemed as 'too much', while the former choice of ÷10 and X8 could be deemed as 'too little' of an approximation, of integer count-down.

   All this is fascinating and confusing territory, and at the same time !

   In order to do a finer multiply, could next try X.85, remembering it's DISCRETE, not analog.  So, you need a scale using 2 decimal digits. That would be an apparatus having 100 'flaps', closing 15 of them to get that 0.85 ratio.
I'll have to work out those numbers, but point is, trying to get best closest match, as substitute function for the discrete subtraction, of each 'i' step in a FOR-NEXT
structure (unwound loop).  You still won't be able to use that 'step' parameter directly in integer form, such as to read 'memory' at $4010 + 'i' offset.  Discrete means all or nothing, of the multiplicand copies stamped out.
   Of course, any 'copy' of the light beam amplitude is made by splitting the beam, proportionally, and downgrading the 'value' scale. So, for example, having a beam at 100 lumens, split in two, the 'new' standard full signal would be downgraded to 50 lumens, that being the case for either new 'sub-beam' , as they proceed on their way, into next appropriate passive logic section.

[RJSV]

There are two ways for this to happen;
   One method, discrete rightward BUS shifting,  eventually emptying to the BUS lanes, after 10 rightward shifts, each individual shift will drop one signal beam.
   Method #2 using ratiometric reduction, could result in a classic infinite sequence, like for example, a divide by two (that's done by ÷10 with X5, for X 5/10).
That infinite sequence never gets to zero, but a ratio reduced series like; {0.5, 0.25, 0.125, 0.0625...etc.} could get down where it's essentially 'done', or so negligable amount as to be harmless, (as the loop keeps trudging on ...and on)
You might have the device execute 2000 'loop equivalents',  at a fast 200 pico-seconds each, but with only the first 100 repetitions matter, as doing anything.  That way, at finish, get similar action results, as compared with a classic 'FOR NEXT'.

Confusion dept. 483, floor 13
Thanks,
Rick-Jack

[RJSV]

   Here is a good referral;
YouTube University of Illinois Nanophotonics (1hr:08)
  That lecture Professor is very listenable and clear, including slow repeats when summerizing difficult parts.  Mentions refractive index and other optics from EE perspective, and bio-sciences perspective.
Site search says something, about 'Nano-Bio Node' ?

[RJSV]

   This latest diagram really sets the stage, for presenting the essence of my title,. involving data transfer, in novel ways;

   "...has both Analog and Digital aspects and functions..."

   The 'confusion' in the picture is somewhat deliberate.
Notice; the two BUS formats illustrated, inside that big blue circle, have a look that is, well..., identical.
The digital and the analog characteristics are equally expressed.  For the 'digital', I figured using basic signal from 0 to 1 volts (0.999 max.) and with the comparator level using 0.5 V, to signal a digital 'ONEs' state, similar to TTL thresholds.
   Of course that's the voltage equivalent for any light intensity discussion.  A glance at the BUS representations, there, inside the blue highlighting circle, shows the 'compartmentalized' version is re-drawn, as a distributed set, once for the digital set, to be used in fully digital settings, conventionally, and the same '5' value is also expressed, drawn as the analog word, in a special form, of right-justified fill.
Either of those BUS formats can almost be used interchangeably, with some care.
   There's still some conflict, as I would tend to limit that '5' value shown, to more like '0.5' in actuality.
It's the 'zero' value handeling that's not resolved here
Notice sometimes the BUS lanes or columns are
 1 thru 10, sometimes 0 thru 9...But it's all eventually going to be structured consistently.  Notice, while reading some of the methodology for BUS encoding, that the 'Multiplicand'  gets split into 10 pieces, one of which doesn't ever get used, at least not in a decimal multiply, using up to '9' separate additions.  You can see the hints on that, down at diagram bottom, where it is showing the Multiplicand after analog weights have been re-distributed, in preparation for the multiply function to do the conditional additions, for each column,.in that decimal BUS.
   Ironically, the most conventional looking BUS format, ((please see the positional weighted word, 4th down from top of illustration), is the least useful!

[RJSV]

   For more clarity, and to correct error, the light beam amplitude, '5', was supposed to be split up, 10% into each separated path, (last diagram incorrectly showed that 5 ÷ 10 as being 0.2 for each confined path or conduit).  One aspect, the full diffuser, I have not yet detailed.
   Diffuser action creates a smoothly distributed amount of light going down the machine column.  Starting from top (electronic light emitters, like LEDs), will drive the proper columns.  Another permitted input set could also be one of the 'right justified fill' BUS format styles...let's just assume a previously acting processing element has produced 'answer = 5' and is sending it into our diffusing 'cone', shown in schetch.
First, the internally reflective cone mixes everything, so each individual signal gets all merged.
Now, being 'bosons', that type doesn't react or repel each other (each beam).
   Once mixed and compressed, in the reflective cone's neck-down, the whole beam is re-enlarged and sent on the way, into the 10 conduit channel, shown at bottom of diagram.  Also, not shown is various light diffusing or 'milky white' plastic or glass diffuser(s).  Trivial to describe, but that even light intensity is a crucial aspect, of the 'Conditional Adder' function, for best accuracy and repeatability.
   You can also imagine, many types of optical BUS feeds can alternate with this specific right-justified fill, as long as total '5' gets mixed down, into cone neck for re-distribution.
   With a 3X multiplication, you've gotten 3 columns of light, each being a 10% portion, and so with result being conditional adding, on each of the 3 enabled columns.  The actual gating of the light, via LCD element, is being called a 'flap' or light flap.
   Result, for the 3 X 5 = 15 multiplication,  comes out, at bottom of diagram, as a '1.5' which can be used accordingly, assumed to be simply expressed in fractional form, but you've still got a  useful multiply.

[RJSV]

   I'm asking if someone can answer question about generic Multiply-Accumulate coding forms, (although much of that info is published in YouTube lectures etc).
The trial and error test 'code' or sequence model would be along the lines of 8-bit integer multiplies that get summed...along the methodology of convolution.
Likely, that could be 16 bit binary accumulation, having each element summed being an 8 by 8 bit Signed multiply...That's the big-picture model, for the do-over in optical logic arrangements.  Performing Convolution is the speed-up custom accelerator's main purpose.
   So, that means optimizing the generic FOR-NEXT structures, and focus on convolution, of, say 200 by 200 elements in moderate resolution imaging.
Meanwhile, of course, plenty of course material out there.
   YouTube, heavily accented and hastily delivered technical jargon, could use improvement, as truly near-impossible to 'grasp' what the guy is even saying...never mind a difficult math-heavy topic to start with.
Often, I can't continue watching (deciphering) some heavy physics discussion, might be best to stick to native tongue...let some others translate.
In those cases, I often think "...Smart guy...I'm not sitting thru this marble-mouthed lecture..."

[RJSV]

   My idea for a fast switch exploits a blocking or denial of the re-emission widely known, in outer shell electrons...a statistical 'cloud' of probability, if I got that right.  The process is to pump in (photons), essentially saturating the absorption.  But, alas, perhaps
 re-emission occur still.
I'm thinking, maybe there is a delay,
900 Femto-seconds, before re-emission grow, on the extreme start of bell curve.
That means another beam and path could get disrupted, during that tiny window, before absorbtion and re-emission repetitive actions.  I had noticed, from Colleqeum lecture concerning 'refractive index', being associated with uptake-re-emit dynamics.
   The affected beam, would be at extreme folded or flattened 'X' shape.  'Leaky Gate' means that contraption still leaks to output, to negligable effect.
   Another possibly needed component might be heavy use of timing (square shaped waveforms).  That way, the regular setting, with all the re-emissions, would not be during a short, regular window.

[RJSV]

   One limited use Subtraction is one case where mods to the light beam, or actually modified copies, are made.  An un-signed value comparison, on the BUS type shown, (a couple figures back), it's taking the rt. justified, filled word and, 1 for 1, having an active gate close anywhere that column has a '1' to subtract.  Actually, this case is more like digital 'AND logical'.
   End result the output word has 4 places with '1', and so has implemented 7 - 3 = 4.
Taking it graphically helps, and also note that the output isn't rt. justified, so going from there won't be in the format, for column-identifed usability of the rt. justified and filled BUS word form.
   The optical logic is somewhat 'negative logic' in that the logical AND is done via an equiv negative input OR.
A tiny time window, 800 Femto-seconds, is supplied periodically, and unconditionally, and that low-going light pulse allows for a trigger situation.  It is during that and during the absence of clock signal 'ON', that a low going inverter input would cause a short dark period, to inverter input(s).  That then gives rise to a positive going inverter output pulse.

[RJSV]

   A brief glimpse at the higher speed switch, it is active but not with power supply, but has device delay.
The thing does a pump up of absorption, in that central region, with (only) an aside to the material. Thinking crystal embedded CO2 or silicon, but having usable bell curve, for the resumption if spontaneous emissions, in any quantity.
   The partial diagram shows the 'CONTROL' beam enters from lower right, and causes saturation, at the center of the big 'X' shaped switch.  Then, with or without good timing, the upright beam is the re-emission, from the original control beam at the different angle.
   Drop the control beam, and there could be a bit of a window, before the spontaneous re-emissions build up to normal statistical equilibrium...whatever that means in detail.
   Lower curve is simply an extreme shirt time after cessation of the saturating control signal ...implying a very short time interval.

[RJSV]

   In the full view, the optical switch has signal 'B.' (please see diagram), where the output contains both the original beam signal, and plus it contains a mix of the re-emtted light from electrons (effect).  I'm speculating a more encircularing pattern for re-emissions, maybe also going 'backwards, up the control conduits. (?...).
   The real time curve shows a brief dip in output, that would then go, side by side, with some static or slow variable.  When the 'A.' dip occurs, then the static (input) device will influence the 'circuit'...taking the place of the light emitting 'clock'.
So, when clock output 'falters', for 800 Femto seconds (10 - 15 seconds), if the other input is 'ON' the logical OR of the 2 beams, will not signal anything...Is when the slow or static 'B' input is 'OFF' that the 'negative true signal happens.

[RJSV]

   Oops, sorry I was a little sloppy / inaccurate there:
The 'A' input is an always there, periodic pulse, very fast, but avoids having to control it.  That clock signal generation is a story in itself, (120 Thz with 800 FS
or 0.800 pico-Seconds.)
  Input 'B' is the beam you want to affect; the main aspect is the inverting effect, that gives ability to implement various logic.  For easy example is the 'disruptive' effect being described, at the very start of the re-emission build-up, but a 'conditional' disruption, so that some, if crude, control is gained.


   

[RJSV]

   Here are some more 'napkin notes', concerning the art of simple subtraction.  And please note; the 'un-signed integer subtraction omits about half the range, stopping at '0'.  But, some signal proc functions want that.
   To do a subtract, '56 minus 8':
   Sounds maybe silly, but;
   Doing Minus 1, 8 times,
   56 minus (56/56) = 55,
  Or, 56 - (56 X 0.0178) ...ahem.

   Then, another round :
   To do '55' - 1 is minus (55/55)
   Or - (55 X 0.0181)...

And, next round will be;
   - ( 54 X 0.0185)...
Etc etc, until 8 of those happen.
That, naturally, would be slightly off, from pure digital results, but getting accuracy is the challenge.

[RJSV]

   Graph shows the ratio substitute for doing (perfect) digital subtraction.  The integer subtraction would be nice but you literally don't know what's there.  Owing to the fact that each real number, or a 2 digit digital set, has a count that varies in proportion to size, you cannot predict the exact size, for example, to subtract from '50' by way of ratio multiplying, vs size reduction to '30'.  In those cases, when using RATIO = .8 the 50 value goes, exactly correct, to =40.  The '30' with same ratio, .8, goes to =24, which is high by 4 counts.
The curve matching trials work good at ratio =0.8 X or at ratio of 0.7 for better low end match-up with ideal. That has bigger error percentage but in the bigger size numbers, range 80 to 99.
   The result is very similar to integer decrement, although with analog values, or real number smooth.

[RJSV]

   I'm pleased to see a way to decrement, as near to integer style as possible, and using simple ratiometric (multiply by 0. that's multiply by zero point eight.
Why can't text entry show that, without emojis ?

method. Each time in turn, a decrement is done, on the integer subtrahend (to be subtracted) and, one for one 'subtraction' from the minuend, to obtain answer.
It helps, to assume EVERY number digit, for subtraction, is '5' (not entirely true, lol).  In this example (please see diagram), I've tried to left-right 'FLIP' the word for taking off from the top end (left side of number) to see if that tactic helps the answer word format, that is, if the ending format can be 'right justified' filled, (it does, but only for the case of minuend being a '9'...others don't work).
   The procedure, assuming subtrahend in proper, right justified filled, is to diminish the subtrahend by way of physically shifting (to the right), while diminishing the minuend coresponding column, usually doing that via masking as logical (bit-wise) AND digital.
   It's very analogous to the previously described multiply actions, where the 'mask' indicated places to conditional add.

[RJSV]

   The idea behind the high speed switch is to create a timing of the statistical delay, of emissions.  That's a pain in the ass!  With a (first) timed event, such as pulse firing a laser LED, I'm thinking that would depend on INPUT, light, and would be timed for a bit later, while the device, or excited/depleted atoms is suppressed. That might only be 900 Femto-seconds!
   This way, feeding a non-conditional clock, negative logic, any 'conditional' input state, on or off, would be inverted, in a sense, (not statically).
If, clock arrives, falling edge, and that saturating or statistically delayed signal is also low, that can trigger the following logical AND stage.

[RJSV]

   The input must be equisitely timed, and lands in a window.  That input gating is a chore for subsystem design.  Would need a short window, 800 femto-sec. that is issued periodically, as a clock.
Any resulting short light impulse, would, usually be low going or a brief pause.
When the two signals are merged, the path would be of content of regular clock, (very brief), and an inverted pulse, or short low-going.  That's, in total still dark or '0' so the gate output does not get 'disrupted'.   Outputs operate, as the incoming pulse, is negative logic AND.
   Then, for a positive pulse light output, just simply send to a next inverter.

[RJSV]

   The diagram is not completely right, but shows the so-called 'Clocked Inverter'... or synchronous pick-up.
Input being active, that's a '1' encoded. Then, that light input flow abruptly stopping; I'm hoping that the device, a light pumped laser, similar to LED type, see 2nd waveform.
   The 2nd wave is statistical time to 'mean' recovery, of the very brief stoppage.  That's on order of
1200 Femto-seconds, at 10 to -15.  Third graph, lower, is the 'Inverted' pulse output.

[MK14]

!  !  !  !  !  !  !  !  !  !  !  !  !
My earlier post, seemed to get missed.
So I put this in, to make it more likely to get noticed.
Sorry . . . . ...          
!  !  !  !  !  !  !  !  !  !  !  !  !

   The diagram is not completely right, but shows the so-called 'Clocked Inverter'... or synchronous pick-up.
Input being active, that's a '1' encoded. Then, that light input flow abruptly stopping; I'm hoping that the device, a light pumped laser, similar to LED type, see 2nd waveform.
   The 2nd wave is statistical time to 'mean' recovery, of the very brief stoppage.  That's on order of
1200 Femto-seconds, at 10 to -15.  Third graph, lower, is the 'Inverted' pulse output.

Given that modern chips, can have billions of transistors on them, operating at rather high speeds, and then produced in mass production, for sale at reasonable prices.

Or even 5.3 Trillion Transistors!           

See here:

Micron's 2 terabyte (3D-stacked) 16-die, 232-layer V-NAND flash memory chip, with 5.3 trillion floating-gate MOSFETs (3 bits per transistor).

Source:
https://en.wikipedia.org/wiki/Transistor_count


How can a light based logic system, made out of individual components, such as laser sources.  Attempt to compete with that.

E.g. You make your device, with 5 transistor like, light gate things.

But these latest chips, can have 5.3 Trillion transistors.

So, a ratio of a Trillion to 1, which is mindbogglingly difficult to comprehend.

[RJSV]

   Here's a glimpse of a 'code loop', or what you might see with Basic.  Thanks, Mk14, folks are saying they want, some semblance to existing processing, but mostly, like you say, at massively small scales.

   The optical For-Next structure would start at 2000 loops, however that would be done in 50 runs, at 40 code steps each run.  That's considered 'vertical', downward, just a convention, while a recirculating path going upward is, again, more just conveinient language to describe circulation.
   It's whimsical, but wondering if a short light impulse could be shorter than the stack or code stack.
Each 'for-next run would decrement the loop count, but only that one time.  Using the active fast gate...
   The right hand side of circulation diagram has upward paths, of each BUS element, as possibly undergoing a simple amplification stage, for recirculation maintainance.

[RJSV]

   I was figuring 300 pico-seconds per frame...that is per 10 cm.
   But that includes '40' structures, vertically, so it's more close to 300/40 = 7.5 pico-seconds per processing element (path).  That could be something like 'X - 201' in that case having maybe an 'X' and a 'Y' register,...all starting to look like a simple programmable processor.
   Standardized full size would be '000' thru '999' with various decimal pt. locations.  One problem, with using such primative logic, is the BUS amplitude issue, when any computational outcome involves more weight.
Take, for example, '2 minus 4 = 8' as a low digit generator, needing 8 places having '1' or digital 'ON'.
That issue has solutions, rather unpleasant.
   The For-Next example, there is no explicit PC or line number, it is by location.  An example would be doing 3 different things, repeating during the 40 code steps or loop pass.
   One function is the usual decrement and test, at end of loop downward pass.  That is a 2 digit number, decrementing, while handling any of the underflow 'borrow' type signal, to the next higher digit.  So, 50 loops to start, then each bottom of pass will decrement using fairly simple shift right, but the underflow, borrow is the hassle.
   A second function example, would be a generator, that calculates 'triangular numbers', up to 15, where each is added, rather than factorial style multiply.
Each result then added, into the 'X' number virtual register (light path column).
   Then, example 3, the optical 'code' stack or list, could input some sensor, gated to virtual register 'Y'.
Each of these heavy pathed BUS sets are 10 wide,...so miniaturizing might be the ONLY way.
An example processing, on the sensor, say at 2 digits or '00' thru '99', could pre-process by multiply the immediate sensor input by (digital) set value(s).
All very fast, if maybe sloppy.
   Each if those 3 examples would be interleaved into the 40 available slots, so maybe flexible assignments could be 'coded' which just means slang for building that particular function step, in reflective or other elements, for example.

[RJSV]

   Please excuse the numbers, but comes up to
  12, 500, 000 individual BUS paths...Any questions ?
   Some recent matrix organization is going upwards, from 100 by 100.  So suggested is (250 X 250), which is about 62 K or 62,500.
That's close, also, to binary (256 X 256).
So, with 4 registers, each having 3 digits X 10 lines or paths, it gets up there; 140 individual optical paths when you've also included a loop iteration counter.
So, the figure is 62 thousand processing BUS elements times 140 getting 8 or 9 million,...headed to 12 M soon!

   Not actually that intimidating, when I read some Quadrillion nerve related connecting elements ...which sounds farcical, in the face of it, but apparently the biological systems account for huge numbers of functioning connective elements.

[RJSV]

(Please see attached diagram),. The 100 data lines, or paths aren't so bad when organized square. The 10 by ten square naturally holds 10 data BUS sets
Diagram shows highlight on the 'B' register, Low, or 'BL' for short ID of the digit.
 

[RJSV]

   Looks maybe odd, at first, but this next diagram features a 'code step'...really a 'load value' type instruction, although not some code step you could type in.  In Basic, that might be 'Let BL = 3' or for microprocessor might be transfer from elsewhere in the little processing sub-unit.
   The light wave conduits block the 'old' BUS value, completely, then substitute the new constant value, into the flow, so to speak, or the 'virtual BUS'.

[RJSV]

   Doing things in decimal form maybe looks old fashioned, but it's just a handy smaller size.  For doing the fairly standard carry flag, as in many microprocessors, it's a mess to attempt, directly in optical and multi-digit BUS format.
   Doing a two-digit capable BUS, at 100 individual lines or optical paths, has a counting depth of 100, while the Loop or segment replacing a small loop pass, has a depth of 40.  That way, as long as a counting variable is limited to 40 it will not overflow.  Then, at the bottom of the full pass, the active components (hopefully fast) can do the limit checking using conditional test.
Many cases, a programmer knows where some count is, down through the stack or list, implicitly.  But, for demo purposes let's assume we don't have complete control or predictability, on a count, just only that it won't exceed '40'.
   Those 40 bubbles are not 1 line, but represent a simple run, say less than 10 lines, although could just be 1 line of function.  (Please also see the diagram, having macro-run of 40 little bubble runs, back a few).

[RJSV]

   Doing the way way down functional actions, a 100 line BUS is huge, but the continuous format is interesting and similarly mirrors analog, in positional image view.
   For a Fast Preview, try compress the BUS sizes, to a 'guesstimating' capacity, say at 5 states per BUS word.
Then implement that as co-processing look-ahead, of course using some care with much reduced number capacity.  But might be useful, as super-fast look-ahead at '00' thru '24' range, base 5 radix and all.

[RJSV]

   The fit is not too bad, estimates are a 'cube' at
100 by 100 mm.  Has 250 individual processing elements,...those each being a primitive single digit, and that's on 2 axis, so it's 250 x 250 = 62,500.
   Vertically, it's 40 'bubbles', or they represent the 'Jth' iteration, in a FOR-NEXT LOOP pass
Now, with implicit positioning, the low digit of your iteration count can be left implicit.  The high digit, or 'JH', loop digit, can be decremented, every 10 bubbles, or more informal, is to decrement 4 times, each 'code pass' where that is being done at 40 bubbles per.
   The diagram shows, 4 slices, each can be doing up to approx. 10 lines worth of code.  So...that's an estimate of 400 lines of function, going down thru the 100 layer stack, (likely silicon, at 1 mm thick each).

[RJSV]

A good simple set, for single digit functioning, is shown, having 5 registers, plus another 5 second set.  That way, small routines or segments of code can do roughly 2 moderate tasks, or several simpler
   Often, the upper digit, JH of the loop count 'J', is in right-justified and filled BUS format, ready to go for any analog related use.
As shown, the 2 half's or segments, of processor, can communicate with other 'squares' surrounding, forming crude parallel data network, at least to short distance neighbors (bordering processors).

[RJSV]

   Getting all this to show some function, suppose class 'assignment' is to show the (optical multi-processor), steps, or 'j' iterations, as an analog ramp.
   So, using a Silicon Compiler, the 'Looping' inner code loop, is actually unwound, into 40 separate bubbles, each being 10 lines max , without any real strict reason to be completely repetitive.  Much of that is imposed artificially.
   Looking at diagram, of BUS merging, signal by signal, there is an ideal ratio, about 1 to 10, if horizontal conduit width vs vertical run.  You can see approx that, in one conduit, while when viewing as a whole, from ten line BUS, or at least 9 line, the signal 'run' ratio is closer to 1 to 2...; with the wide, decimal BUS
   BUS Formats, you have to be very flexible, in application of the many.  Some BUS formats wish to self-identity, as 'Base 12, center fill',...so be it.
   Now, those 'j for NEXT' segments have the value incremented virtually, but only in the compiler.  So, for the 'homework' assignment, the low digit implied count value is reversed, for counting downward, in a real register having ten positions (9 for analog weight purposes).
You start at '9', for repetitive ramp outputs, each count value.  So, that happens in every burst or bubble, of up to ten instructions, by compiler inserting the shift-right model, as decrement.
Knowing that value, but still only implicitly, allows you to put a code line, to periodically update the high or second digit.  That saves a ton of hassle, essentially doing the digit to digit carry, explicitly instead of relying on a conditional operation.
Even more of a bonus; the little 1/10 portion split off from upper or 2nd. digit can be used as the light source for the (periodic) reload, of low digit value.  That means laterally transfer, to lower macro-column, and re-define of a lower amplitude standard there.
Picture shows diagram, of Load instruction and vertical to horizontal ratios.

[RJSV]

Diagram of 'Load R with 3'.

[RJSV]

The details, in shifting to do counting ..multi-digit can get lost, between the weeds and alligators, but it's design details like:
   The high or second 'TENS' column digit is decremented first, upon arrival at a roll-over point. That way, that's a count-worth of light amplitude being 'thrown away' that instead can supply, at 10X reduction, the light for the LOAD constant = 9 that initializes the small or 'ONES' digit.
   Diagram showing, how each shift, of the high digit, 'JH', results in that carry or borrow actually, coming out for re-use initializing the lower column

[RJSV]

   More details, on the process of generating a two-digit ramp, counting down (digitally) by way of shifting 'bit flags' so-called because it's not a binary organized BUS.
   (Please also see diagram).  The Fuller view, having a messy set of two BUS passive structure runs, has featured that combiner-redistributer that will produce or source a set of 9 equal-weighted lines, for reinitializing the lower digit, each cycle of decades.
That way, as shown, you go from 31, to 30, to 29; all while properly handling the result to reflect an underflow or borrow, from the 2-digit lower reg. ('JL', held in A1 register, for example).  Upper digit register or virtual register column, is 'JH'.
The separator and diffuser had been mentioned, a while back, for analog.  But...with care, the re-created BUS word can be 'interpreted' in digital terms, by the sensing switches.

[RJSV]

   I figure on the order of 3 pico-seconds, to do the action to shift the BUS, to then compress and redistribute, and finally, to re-enclose or separate the 9 signals...allowing for the re-use by initializing the next set of decrements (shifts), of low digit.
   Full 40 station run, is going to be approx. 2 Ghz rate, of circular calculation sessions.  That's about
500 pico-seconds per loop.  For the case of nesting loops, the For-Next i= 1 to 50, that's a pretty typical outer loop...It's the " j'th " or For-Next j= 1 to 40, that is not really a loop, but a linear bunch of repetitive blocks.
   So, anyway, taking 40 bubbles x 10 lines each, the 500 pico-seconds gets to 500 / 400 or 1.25 pico-seconds per line of 'code'...not bad.
Or, could look at it as, 2 Ghz x 400 lines per pass, or 800 Ghz equiv. doing single integer manipulations.
   That's before accounting for the 62,500 independent processing elements, each with 10 registers.

[RJSV]

   To show the (estimated) run, through a single, 1 mm wafer, perhaps having 100 mm per side, in usable silicon, see diagram.
   Four runs, of ten each will cover the territory, albeit backwards in real registers.  The diagram indicates 4 of those mockup slices, seen in middle rt., the 4 are in series, thru the depth (of the 1 mm wafer).
   You can, at least get a sense for how the count
 run-down, on the larger digit, is sparse, or less frequent, than the low digit, that counts out every 'bubble' there

[RJSV]

   Close-up shows the one bubble, having (up to) ten functional 'code lines', primitives like
   ' Multiply Y1 = Y1 x X1 '.
...or some kind of addition, some diffuser , or BUS splitter of all sorts.
   Notice, this bubble has a decrement, 10 steps out of the 40 available, so in this special case that ramp is getting higher priority, at 25 % of total.

[RJSV]

   Oops, sorry, not quite described right. (This is many new things, at once).
   In the 100 silicon wafers (stacked and aligned), the '40' bubbles of code bursts are interspersed; firstly they have every-other (wafer) but also there is a 'Utility' slice or wafer, every decade, so it turns out there are 4 wafers in every 10 layers, that have the passive BUS manipulating structures (like the shifting).
It's each of those, 40 throughout, but at each burst of ten should be 1 shift (I showed all ten at once, but that's not correct !).
So, with attention to that lower digit 'j' in the For-Next type approach, I had been attempting to show how convoluted or extensive the element count gets,...just to decrement a represented (2 - digit) number.
The decrement is then using 10% or 1 in ten of each bubble.  It got super tedius / boring to draw each if the ten iterations. Actually, in reality those code lines are stretched out, interspersed out into 10X the run shown, (while other functions 'time share'.

[RJSV]

   To employ a little drama, picture shows 10 slices in a wafer, each at 100 microns.
All stretched out, but just one of those, the first paper slip, has a decrement, shown next, but it takes a '39' down to '38', as a first action, in that run of 10.

[RJSV]

Next, here; Picture shows the head of those ten slips, after all ten wafers have been encountered, (at the tenth), this time, the first slot, for the 'j' count-down, is doing a roll-over, '20' down to '19', by explicitly creating a new '9' set of BUS signals, all on.
All this just to show the scale, of having 40 of the wafers giving 10 'instructions' space each.  That's at 100 micrometers per 'instruction', thru the wafer thickness or depth.

[RJSV]

Actually, that last slide bleeds into a couple more slots, in the 10 vertical slots available, owing to the diffuser and re-separator needing another two program steps.

[RJSV]

   For an easy, but fast sawtooth generator, having analog output, this thing does 2 Ghz repetition rate, shown in about 3 full sawtooth waveforms, each completing a cycle in 30 counts, over the 500 picosecond optical loop.  That's 40 samples x 2 Ghz or equiv to 80 Giga samples / sec. counting the extended time the sawtooth stays at zero amplitude, as part of the repeated cycle.
  For questions about speed, consider the two-signal bus line 'reverser' that will create an opposing copy, ON or OFF, each bubble, or (average) at 80 Ghz.  That would actually be at 40 Ghz, as it takes 2 reversals.

[RJSV]

   The time, coursing down thru stack of 100 Silicon wafers, apparently will be:
   400 Terra-hz (Thz), for infra-red 760 nm.
   Then 1,000 cycles of that light spans 760 um, or almost a mm.  So, 1400 cycles gets close, to the
 full 1 mm of a wafer thickness, at IR 760 nm.
Then, at 2.5 Femto-seconds per cycle, (1.0 / 400 x 10 to the 15.), that's:
   2.5 10(-15) X 1400 = 3.5 10(-12) ,
or 3.5 pico-seconds per wafer thickness.

Or, 350 pico-seconds for whole pass, plus 150 for loop recovery, so total is 500 pico-seconds, 10 (-12).
Around a circle shaped path, that's about 3/4 calculating element area and 1/4 is for the recovery and preparation.

[RJSV]

   Happy Holiday!
   Enormous challenge, primitive computational logic, and data transfer layout.  Dentist office chitchat, speculation,...we (self included) had NO CLUE what that's about, aside from visualizing some 'beams crossing'...
   But now, 'enough' engagement to at least be able to vocalize problem (areas) and flesh out some performance limits on the gross or non-quantum effects available.
Currently, examining 'partial rollover' or carry / borrow dynamic, on a 2-digit number, as that is key to effective 'blind' calculating.  (Never making intentional puns, here).  But first, a couple waveform glitches.

   The fast waveform RAMP generation has irregular timed outputs, doing 4 outputs and another 5th time slot without.  Fix for that is to run all the 500 picosecond 'code loops' with regular spaced outputs, instead of skipping.
But a bigger problem showing itself, (viewing slightly older diagram), the 'un-rolled' code loops (using 'j') are rolled out in SPACE,...not time; so you see the repetitions stretched out before you.  Now, with a closed calculation that just spits out one answer at the end, that will work, somehow.  But an analog waveform is a continuous (periodic) output process.
It's as it the 'observer' needs to ride along, at light speed, obtaining each answer on the 'breaking wave', of TIME...(no puns or drama, that's just what it is, today).

[RJSV]

Optical Illusion Teaser, at end, (see photo also).
   Putting out this summary, progress and problems so far.   THEN,...it will be Wednesday,
   PLANES, TRAINS and AUTOMOBILES.
Fun friends, and famulilly !

   The Dividing and multiplying, with various mixing of analog with digital formats, makes interesting tool set, but it was the 'DECREMENT' or integer counting that had surprising results, or partial realizations.
So, in cases of single digit, a multiply, (by 0.8 or by 0.85), serves as substitute for (blind) subtraction, as ratio to 56-1 vs 98-1 as 1 to 50 vs 1 to 100 change.
But a consistent multiply factor (applied blindly to a single digit, 0 thru 9, ) can be optimized for best 'curve' match.
   Using ratiometric (multiply by number between 00 and 99) has a 'residue' that persists, going smaller and smaller.  Another, similar option, uses similar looking operation, but ends up, discrete shifting, completely shifting all empty, due to the physical right shift, of the ten partitioned BUS defined lines.

   But the 'integer' subtraction method gets interesting; instead of usual, roll-over with higher digits that occurs once each ten times, the method, blindly without clue where/when rollover should precisely occur, routine will do, constantly, a '1/10th' rollover, and that is literally done by 'rolling' a one value, every repetition.  That way you still get 10 every 10 times you (decrement).
And while you must 'borrow' from the 'tens' column, a one, and then subtract that, it makes sense to 'JUST DO NOTHING', with low digit, and work on the rest of the task, which is to complete a subtract, of 'one' from the high digit, which represents '10' being moved over, in traditional paper-pencil subtraction protocol.
   The error, however, or mean random error, for a ratio related subtraction, is about in order of one of those (low digit) decrement (virtual decrement).
That's what I've termed an 'Eye for an Eye' type of one for one subtract, by decrement in turn, usually with a zero test for 'j= 0'.  Still not sure about that test, speed wise.
   An alternate way, if For-Next repetitions use a parameter that becomes ineffective, I.E. goes to zero (by discrete shifting), even while the 'loop' continues on, unchecked but also not doing harm...

   A mess, but have to admit; there is enough progress, to be presenting some real snags, areas of frustration (integer-like decrementing), and even an OPTICAL ILLUSION QUESTION:
(PLEASE SEE PHOTO, ENCLOSED).
   Why, when moving head, are those after-images tracked out, from the little light ?  At 232 khz those images, when eyeball 'flicks' around rapidly, those images aren't spaced right, for the speed they supposedly oscillate.

[RJSV]

   The 2-digit format, in a SUBTRACT, or decrement, has some customized features, mainly that the high digit has special limits, (that can't be used in general case, of multiple digits, or floating point style.
So, wishing to avoid any underflow or borrow on case of a 'ones' digit rollover, an actual subtract is done essentially on the high digit,...that being another order of magnitude less than the actual 'tens' column digit.
The usual subtract 1 at once per 10 times is replaced by subtract 0.1 but every time.  That means every time the 2-digit number has to subtract 1.
   It can be confusing, doing this non-standard method, but it helps avoid an underflow situation, on the low digit.  It's all done 'blindly', not knowing which cycle of decrement has an actual low-digit rollover
(from 0 to 9).  The high-digit is only going to really roll-over (underflow borrow) at the very end, of the 2-digit count-down.
Readers can wonder, what about the 'phasing', of roll-overs, where the code running doesn't know, or even worse; actually 'knows' that 9 out of 10 decrements DON'T roll over, but that's O.K.  The subtraction is simply done in different place (high digit), and at ten times less value.  The low-digit, meanwhile, is left untouched...essentially adding a one, each time, as the partial move-over from tens digit, but also then immediately subtracting a one, as the desired function.
Result is just to ignore the low digit, as it is adding 1 and then subtracting 1.
Please also see photo diagram showing the high digit decrement method...in bigger picture meant as portion of a whole complete Word subtracting another Word, like 40-5 = 35 for example.

[RJSV]

  Revisiting for a sec, the light guide conduits, or paths, (pls see diagram) the size of one gate or processing element compares nicely with some wavelengths used.
   Roughly 100 microns across, and approx twice that in run length, you can observe; each of the ten conduits is on order of 10 microns.  That compares with 760 nm wavelength at about 15 full wavelengths; hopefully that's enough to, barely, get up out of heavier quantum or diffraction effects, and more in just simple bulk light mode.

[RJSV]

   O.K. Team,...Listen up:
   We need, (put on your 'M.I.G.A.' hats) we gonna need a re-integerize or re-quantize electronic / optical function.  Something to clear the residue or residual analog error, after a modest sweep doing some increments or decrements.  Right now, it's basically real numbers on each iteration (loop count).
   Arriving at loop 'bottom', after a modest number of decrements, (like 50 decrements of real number), the idea is to trim or clear the residual value, perhaps using a flash compare, rather than full AtoD.
   So a pseudo-integer, like " 41.13 " would be adjusted, to the correct integer form; " 41 ".
A digitally processed integer can be, conventionally, maintained forever, in continuously applied functions as the discrete nature allows for 'perfect' real world continuity.  For example, add + 4 followed by
subtract 4, repeating, is never going to 'drift'.
   So, analog / optical design Engineers; put on your
  'M.I.G.A.' hats; we need a set of terminus processors, very fast, to restore the loop integers, to prepare for another, fast, optical journey, down the 'code stack'.

-- Thanks for reading.
--Rick

[RJSV]

Ah shit, forgot to say;
   M.I.G.A.  (hats) stands for
   'Make Integers Great Again'

[MK14]

Maga Hats:

Make
Autonomous
Gyro-light Optical Digital switchers, Great
Again

[RJSV]

   I like your hat better, mine is too obscure, for general consumption.

   How's about some more criticism, seriously, this thread needs some more reality checking.
From a project management standpoint, I never would have thought the theoretical development would make it THIS FAR, let alone the hurdles ahead.

   MORE criticism, pleaaze. Thanks

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

[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,

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

[RJSV]

Still thinking about that 'Stack of Multiplies' thingy (reply #232, December 17, 2022).
I mean...is there even another similar structure, in existence, (for doing study) ?
  By 'Basham's Principal', you cannot (easily) obtain same results using, for example, BASE 8, or other base smaller than decimal 10.  That means, that one or the other, of the base or radix used is going to have superior performance...(?? I think).
I'm betting on Base8, vs decimal, simply due to the reduction of 'reach', when trying out some single value or size. (As in one size fits all).

   However, when going to a Base8 scheme, the reach of maximum value is then reduced; from 9 to a 7, thus causing (I think) a need to have more digits; and thus more error producing function.
As Base8 would need 3 digits, ones, eights, sixtyfours,
as covering a range of 512 counts total.  Whereas a two-digit decimal would give max. of 999.

   I might have to resort to hand-scrawn table, at octal base8, to fully evaluate that.  (Lol, base8 involves more than just 'skipping' from using '8' s or '9' s.)!

[RJSV]

   Plus there is yet another MATH question:
   Looking at floating point routines, IEEE 754 the 32 bit floating point, signed.
   Seems like, the very first multiply, of 23 bits by 23 bits, will produce 46 bits of answer result...Aren't those bits, past a couple of number groundings, isn't most of those last 23 lower bits getting thrown away ? By rounding ?

[RJSV]

Here is an interesting hybrid, bringing together 3 different stacks, of multipliers or shifting steps.
   Calling it 'Decimal coded Binary', or DCB, ...a play on words, from 'BCD' or standard binary-coded decimal.

   Ratiometric  function (multiply stack having 8 or 10 outputs), starts out ok, but doesn't end with good 'finality', rather it lingers.  For an interesting  biased encoding style, is going to an 8-state, or octal-ready word, embedded into a ten column, decimal word.
That's a whole bunch of eye-watering jargon, right there, but there are numerous practical advantageous to getting back to a decent 32-bit type microprocessor word size and format.

The encoded word is just simply (2 thru 9) as the offset by 2 for an octal or 8 state binary word.
   Now, shifting is very sane and accurate...at 100 %  (or 90 % roughly), and shifting rightward as decrement makes very definitive 'zero' in columns where that index has gone down.

[RJSV]

Now, a weak point, of using a diffused light source, is that, while ratio reducing 10%, ideally, of 10,  but when doing 10% of a count of 5, that only comes to 0.5 each, or half of the correct value.
   Searching for an offset, or function that has imperfection complementary (to ratio multiplies like 0., the shifting type process does not have the same problems, down at 0 or at 1, so it can be used, in column 'two', or second column, and further, act as an offset, to the problems of the ratiometric by itself.

   A third column is also doing shifting, but only acts during the first 3 processing elements sets.  But that 3rd. column is also un-encoded octal, ranging 0-7.

[RJSV]

So, to tie things together, an average is taken, where a signal, weighted light beam, is split three ways; two doing value shifting, and another doing ratiometric reduction, as decrement substitute.
Then, for an average, those three values are added up, correct or not, with the hope that, dividing total by three, can give some stable results, looking closer like a real, integer, decrement.
For example, starting with '9', and doing X8, gives 7.2, a bit low there, but 'matching', uncoded '7' under shift goes down, quite well, to '6', or, for complex reasons, about so...
That's 7+7+9 or 23, going down to 6+6+7.2, or 19.2.
Those averages are then 7 2/3 and 6.2.
A change similar to proper integer decrement, albeit a neck stretcher, for sure.

[RJSV]

   One mistake I made was thinking that for a simple shift, rightward, of bits or bit flags in a word, the proportion is 10%, which would only have been true in the case of reduction of 100 %, purely to 90%.
Thinking, with example the maximum digit value, '9', thinking that by simply grabbing one box, or path conduit that it would be '10%'...it isn't.
   If a diffuse-light '9' is put on the BUS, it should properly be a ten partitioned deal; otherwise being part of the whole meaning of 'decimal'.
So, the result is to have 0.9 counts, in each of ten conduits, and that should most properly be termed as a 'weight' conveying BUS, rather than a more convention resembling data transfer BUS, of 0 thru 9.

   What would occur, by a single shift-right, is that a '9' would get reduced, by 0.9, to result in '.81' or 'zero point eight one', as the approximation, to decrement.
For accuracy, you want to shift out a full 1.0, and that would be some '11.1' odd percent.  That figure changes with every digit, needing more, when transitioning down from '8' (eight) to '7' (seven).
For that, you need 7/8 or 0.875 to be shifted out.
Kind of wrecks the sense, of definitiveness that shifting brings

[RJSV]

   (Slightly blurry photo, sorry).
Enclosed picture of diagram shows a functional sequence, typical of what I've been discussing.  Readers note: don't worry if the methods being discussed seem a bit, well...; Wacky...some are a bit.  But it's 'technology' nevertheless, and actually bringing up some valid and interesting points, regarding methods for getting clear data, in absence of full logic functions being available!

   Enclosed diagram shows a shifting 'blank' or increasing dark stretch, over the iterations.  That is somewhat a guideline, rather than imposed, but makes clear that those data columns get blocked down, having no 'residue' or tiny values left, getting reduced by RATIO each time.
   The shifts, instead, take things definitely to zero, in each of the columns, in a gradual blocking, until, after 8 iterations, that 'index' word, as part of a 'FOR-NEXT' type of structure, index gets all the way down, and so can be more clearly used as such (total 0).
Things are so novel, here, that a diagram like that will go a long way, to establishing a valid methodology.

[RJSV]

Second diagram showing weight shifter, of real values (0 thru 7).

[RJSV]

Notice this second diagram has a more conventional range, as an OCTAL or 8-state binary based word.
Without the 1-count bias from before.  These shifting values are added to the other method results (the ratiometric derived values), as method to 'water-down' the deficiencies of purely doing one or the other method, (by ratio or by shifting).
   I think what happens, is more of a softening effect, rather than directly opposing error values, (with opposing errors in the other function).
But idea is to have one function deficiency area be covered or compensated for, by the other different function, as it has weakness or deficiency at other points in the curve (of the low digit ranges 0 thru 9.

[RJSV]

A bit hard to conceptualize, but the ratiometric method should be 'depositing' it's resulting light amplitude, a a diffuse spread out over a WORD width that is continually decreasing.  Almost like that rightward shifting blank area is 'keeping the ratios honest' by following in and putting blanks, or 0 values in, as meanwhile the active routine calculates the new (ratiometric) result.
So, while ratio multiplying doesn't ever bring things down, to zero, all the way, the combination does do that, although only fully after a complete pass, down 8 times from starting value.

[RJSV]

Picture shows various options, for the multiplying stack.  When your maximum is a '9' for regular decimal, you end up with 1/9th. of total, per each 'conduit' or signal path for the light amplitude.
That's approx 11 percent each (separated division).
   Fooling myself a bit, while examining options regarding ratiometric VS. sliding or (conventional) shifting of bit flags.  While not differing ultimately, each of those two options has differences.

   The bit flag shifting option has less flexible applications, vs the ratio method.  For example, the basic setup for ratios assumes that the light (amplitude) is spread out, evenly diffused, into TEN conduits, meanwhile, for an example '7', there will be 3 conduits, of the ten, 3 will be blocked, so that a 7/10 ratio multiplier exists.  Mostly, those will be at the decade boundaries; at 50, 60, 70, 80, etc.
A special ratio can also happen, such as the useful 0.75 or '3/4' ratio.  Note that a '4' gets transformed, that way, into an exact '3.0' to represent a good integer decrement.
   Diagram in photo shows the 67 % point, or 2/3 multiplier that is used in the critical, first decrement (in the stack), so that you've obtained some decent 'decrement like' behavior; in taking an incoming '3' down one count.  That's the worst of it, as we've avoided any lower values, by the offset bias.  The 8 counts of that 'OCTAL' counting will always be using 2 through 9 as the 'coded' octal number in range (unbiased) of 0 through 7.

[RJSV]

   Picture helps to illustrate my point.  At this point in sequence of count-down, suppose you need an approximation that uses ratio reduction at 67%;
You could either use shift, taking away another 11 % as photo shows there are two instances of shifting available (before number is decremented fully to end point).
   If the ratio method is preferred, then those last two conduit boxes there will get 70% of the amplitude retained, and then procedure would be to re-difuse everything, but now into reduced to one conduit.  Note that using 70 % when needing 67% as better solution.
Shifting those two remaining boxes, into only one, will get you that 67 % and into one remaining box.

[RJSV]

Diagram now has important RATIO added to it, to show a functional phenomenon related to GOLDEN RATIO math, where each new multiplier, on that stack of multipliers, each new multiplier is then set to a steady '0.833' or 83 percent, to result in 7
decrement-mimicking  reductions, in range of '8' down to '2'.

[RJSV]

Now, a couple of points, about the decrement mimick;
   First of all, readers might notice, that a fully standard integer decrement, of '1.0' is going to need another count, if doing 7 decrements, from 9 down to a 2.  BUT, that attempt is doomed from the start, anyway, as far as keeping a purely '1.0' subtractive form, and it will help to use the reduction in 'reach', mentioned previously.
   So,...the playfield for doing the counting, the OCTAL count-down, can be an ANALOG range, now, spanning from '2' to '8'.  The multipliers actually go above an integer '1.0' for a bit, (at the beginning of the stack), and then the real result starts reductions of less than a '1.0'.

[RJSV]

   So DECIMAL BUS has 9 active signals (beams of light amplitude), not 10.  So it's ninths for each conduit, when doing an amplitude transfer, 1 thru 9.
Seems unnatural, somehow, but starting at a decimal max digit at '9' implies odd-ball fractions, working with that.  For example (also see previous diagram), say you take the digit 'weight' value simply as =9, then divide that by (9 conduits total), for an even 1.0 weight, in each of the 9 columns, a good start on obtaining integer-similar functionality.

   Setting aside the shifting function for a moment, the ratiometric function needs to always reconcile, to a 10 part (or wide) BUS.  Then, a multiple like 'X0.7' can work by way of blocking 3 conduits, out of the ten, that the light is evenly distributed, or diffuse, thus performing a '7/10' ratio on the function input.

   In the diagram the 9 active conduits needed for decimal need to reconcile to 10 active conduits by redistributing and diffusing the light, back to a uniform density, each time.
Similarly, the function output, a weight of '7' in this example, needs to be reconciled back to a 10-wide BUS.

[RJSV]

Diagram helps to illustrate my point, showing packaging for 9 parts and 10 parts types.

[RJSV]

As seen in previous diagram, options can be for a typical 9-part plus zero, for conventional looking decimal words (10 columns total).  Also, you could, optionally, do some proportional stuff...requiring that you have 'parts or portions' of tenths or 10 % each, and having 10 columns.
   Very confusing, in some settings, but usually get things right, after careful checking.  Tried placing a tenth 'zero' column, but then have a decision to make, and gets into ridiculous when pondering; Do I need a One' s flag, or digital 'ON', flag to indicate the (digital off) 'zero' state is present ? Gets ridiculous, partly due to the passive nature, of doing a data transfer of 'nothing', which is generally a format needing some kind of active clocking, while that 'ZERO' is present, or, err, 'not present'.

   On the encoded OCTAL here, I've coded in a bias, of '2', to avoid that 'zero passive' case handling

[RJSV]

In this enclosed diagram, is using the Golden Ratio related factor, of 6/7 or '0.833'.

[RJSV]

...You can see the real number count-down are anything but linear, but still can be useful, doing a distorted decrement.
   Reminds me of Piano, music theory, where each note or piano key, has a frequency that is a set constant ratio, each to the next.  In that case, each next piano note frequency is higher by the '12th root' of '2', for a total 'octave' that doubles in frequency, across it's range.  Somewhat by analogy, here, could be the 'notes' or OCTAL range values, within the decimal WORD, each seeming to be using the Golden Ratio, term to term, as the constant multiplier.  By exception, it was needed to try using two shifts, for reduction of incoming value, to the multiplier stack.  That way, in case of the lowest number needing a decrement, (3 as code for a '1'), that value '3' can be reduced by 2/3, in the very first multiply step, to, actually, a 'perfect' 2.0 !

[RJSV]

   Photo shows a fairly accurate multiplier stack, after much adjusting / fudging, for best compromise action.

[RJSV]

   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.

[RJSV]

   ENTER THE BIT-WISE SLIDER
   Viewing the enclosed diagram, here is yet another novel tool, originated in combination of both worlds, digital and analogue. (I love this).
Conceived as possible solution, in an optical data oriented microprocessor, for a vexing bit-shift problem.
Difficult, or probably impossible, to do a function / (computational) operation that will take off the latest but, meaning the most leftward, in a rightward bit-packed word (decimal, 10 signals).
   Actually, and this is one point, I don't have a completely clear and defined sense of this BIT-WISE manipulation...we'll see.
In the diagram, is shown the diffuse type format, that had started out with a 0.4 value, in each conduit or path.  Then, in order to 'Shift in Split Format', that digital / analogue WORD, gets split,...but in unexpected orientation, horizontally moving one half of the BUS itself, in relation to the upper, stationary half.

   What does it do, then, exactly?  Don't know that, immediately, but one opportunity is to have fractional relationships, as the upper and lower 'holding portions' have opportunity to 'slide' in either (preferred) form.
Digital slides, after that unconventional BUS-split, can be of whole widths, or by discrete integers, a function fairly familiar...but a partial or real number type of shift is an apparent novel twist, on some basic, legacy operations.

[RJSV]

Diagram enclosed

[RJSV]

Embedded Zero problem:

[MK14]

Embedded Zero problem:

I don't think I understand what this thread is about, nor your last post.

[RJSV]

   The embedded problem helps show the 'packed' format and one of the problem areas in the function.
For example, with a 'properly' rightward packed data word you've got an advantage in that a rightward shift can reliably get rid of a single column, by way of a conventional looking shift, in discrete columns.

   But with those two 'zero value's bubbles shown, you could take a viewpoint that the data WORD shown at top isn't correctly formatted to do that.  So, the diagram today is to show that dilemma.

   Looking at the second data WORD shown in figure that is a very similar situation, only shown more loosely resembling (conventional) discrete partitions, but with analog value contents...just that the ultimate interpretation there, can STILL be very close to the usual zeros and ones.  Readers may appreciate, the fuller world, of formats that cross boundaries, (between traditional practices) and thus the call for a more varied approach, but having more possible solutions.
   Usually, such formats on traditional platforms could do these bit-shift resembling functions within existing instruction sets.

   The formatted 'double mid-shifter' is one of these new-looking functions, that, in speculation, could possibly turn out to solve that specific problem discussed, of trying to remove or 'purge' those zero values from the packed word.
   The price of such speculation, meanwhile not really showing DIRECT promise in this example, is not that extreme;. A few minutes examination and, 'YUP, no help on that one'...Not a big deal, and possibly helps support some other, wild or less wild speculation.
   Besides, having (this) very wide open and novel 'art', of instruction behaviour can be enjoyable and entertaining (up to a point of course).

[RJSV]

Yes, sorry MK14, I've been meaning to place a running summary, of about 4 or 5 issues current.

   The whole thread is dealing with partially implemented instruction sets or functions, where the processor can't easily 'see' the data getting worked on, thus becomes a bit of detective style work.

   Similar to the 'card counting' methods, (in casinos), the overall application might (only) be of use until some additional 'FAST' optical switching gets developed.  So it's a speculative tool, possibly only valuable as a place-holder, so that developers can focus on other aspects of development.
Maybe they (researchers) end up obtaining a DECREMENT INSTRUCTION that has wrong answer value, in 5 % of the time, causing a much more restricted value, vs 'perfect' digital results.

   The timing (of my post) vs the diagrams posted, I think now is happening due to the limitations (Dave knows) the limitations of using a smart-phone having flakey results.  Some of that is new, relating to other upgrades on the whole website, here.
But Dave is right, ultimately, as (my) smartphone functionality shouldn't dictate the whole bug-fixing agenda.  (I'm a pretty unsophisticated user, for sure, lol).
Thanks

[MK14]

Yes, sorry MK14, I've been meaning to place a running summary, of about 4 or 5 issues current.

   The whole thread is dealing with partially implemented instruction sets or functions, where the processor can't easily 'see' the data getting worked on, thus becomes a bit of detective style work.

   Similar to the 'card counting' methods, (in casinos), the overall application might (only) be of use until some additional 'FAST' optical switching gets developed.  So it's a speculative tool, possibly only valuable as a place-holder, so that developers can focus on other aspects of development.
Maybe they (researchers) end up obtaining a DECREMENT INSTRUCTION that has wrong answer value, in 5 % of the time, causing a much more restricted value, vs 'perfect' digital results.

   The timing (of my post) vs the diagrams posted, I think now is happening due to the limitations (Dave knows) the limitations of using a smart-phone having flakey results.  Some of that is new, relating to other upgrades on the whole website, here.
But Dave is right, ultimately, as (my) smartphone functionality shouldn't dictate the whole bug-fixing agenda.  (I'm a pretty unsophisticated user, for sure, lol).
Thanks

Thanks for the reply.

It sounds a bit like, some of the advanced AI algorithms and things, going on these days.  A bit like what use to be called 'fuzzy-logic', a rather long time ago.

I can understand any difficulties, that attempting to use a smart-phone, to make posts on this forum, creates.

[RJSV]

   Yes it's a fairly simple and existing technique, intro into CARD COUNTING:
   Suppose, (at a party), I announce that "I have a card, here, and can anyone tell me which card, 1 through 9 that I'm holding ?"
   Someone guesses, '9', and I say no.
Now, the odds are now changed, better, at 1 in 8 choices left,...ultimately near the end, you've got maybe TWO choices (50 % likely correct guess).    With gambling you could perhaps tolerate this uncertainty by way of your betting strategy, which is functionally valid. Best proof of that, in a casino, is that management doesn't like (your) self-tracking counting for that purpose.
   Such a strategy still might be useful in something like audio playback, having a 'glitchy' sound but infrequently.  Bank accounts would be too risky, to tolerate such predictable errors.  Still, I was surprised and amused, at how far one could go, as a 'number detective's.
   The biggest plus, for me, has been a more working contact with all the parameters needed for physical engaging the optical realm:. Now, I know, a little better, the difference between, say, a MICRON and a NANO-METER, in everyday terms, vs light beam wavelengths.

Two buggabos bothering me, these days are, these increment / decrement functions, and, the holy grail; Being able to do a test, or conditional processing.
So far, can only barely anticipate, doing an end-test, for zero valued numbers.  That's a much bigger hill to die on, than simple decrements.

   A good goal, maybe obtainable by 2040 (at my rate), is to be able to operate 'just like' a common 32 bit processor, around 2005 vintage.  Scheme here looks like several modules (optical), each doing 3 bits, out of total 32 binary bits.

[RJSV]

   Here is a super-stuupid example, but a method that can be valid:
   In your implementation, at equiv. rate something like 500 giga-hz, suppose you, still, can't respond directly to a calculated value set, but your answer is down to one or the other, out of two possible.  It's still possible to proceed through a whole bunch of subsequent calculations, at high rate of speed as long as it's only one answer, or the other. But you would be required to BUILD TWO SETS of 'identical' calculating logic, and thus the IC size is the impacted.
Maybe that's a waste, maybe not.  I could imagine doing your speed-up method that way, perhaps a couple of times (max.) but it gets very kludgey and using too much IC die space (for near-duplicate logic paths).
Of course, using the wide decimal data word, vs 2 signals for base2, makes any multi-duplicative scheme very costly, in terms of inefficient use of IC die space, where usually, one structure handles all of the possible data values, in a single computation path.

[RJSV]

...and, at the end of 'terminus' of the stack of optical functions, your (slowish) electronics takes over, by polling a simple flag, for knowing which developed numerical answer should be used (validated), and which was the 'provisional' that isn't valid, that being after those two parallel and very fast processes finished.  The estimate is that the electronic portion is down more close to a 2 Ghz rate,...comparatively slower.

[RJSV]

   Black (Android) Smoke dept.
   Anyone else notice?  I see my TEXT SIZE, got pushed, in back a couple of posts !  That's my Alcatel smart-phone, excuse for a sec.,...LOL, lol, that's the phone losing's it's operating system mind!
Yesterday, when opened up a new EEVBLOG post the text screen took me to...a YouTube video I had been watching the previous night!  Jimi Hendrix at Monterey Pop, but that wasn't a text-entry screen.  !
   Android and chrome or whatever has been degrading visibly....laptop soon ! Yay

[RJSV]

Enclosed diagram showing the FULL range process.

[RJSV]

Splitting the range, into two sections.

[RJSV]

Out of those last two diagrams, the FORMER, (back two) of the diagrams shows the discussed physical range and the slight reduction in the range, or 'reach' as has been discussed.  That slight compromise, by reducing the span, down to a maximum of 8.5 allows for the compromise to use a slightly different multipliers, in the so-called multiplying stack, as been discussed.  That's the compromise, between the span size and the first multiplier.
   As discussed, in the first step, in the multiply stack, your multiplier can then be a bit higher in value, as it is not charged with need to reduce the first value so drastically.
   Now by operating this in two processing paths (see the latter or last diagram) we've now gained the ability to process in two ranges, upper and lower, thus no need for the (small) reduction in 'reach', previous method.
However, of course this then DOUBLES all subsequent processing, until an answer is obtained,...that being an OCTAL or 0 thru 7 value.  One of those processing lineups is good, the other is not.  They both function, and that's at full speed, I figure at around 500 Ghertz or even higher.
Then, at the hardware run terminus...the 'bottom' of the run of fast optical function, an electronic section interprets result; one path is your good, valid output, and the other is using the wrong (multipliers).

   The actual generation of these sets of numerical results is tedious, take some time, but expectation is that the 'incorrect' provisional processing path will output numbers slightly or moderately too big.
This is because, in my example in last figure, that number, '3' needed more reduction in the range it's in.
Processing that '3' value, as if it was in the upper decimal range of 4,5,6, or 7 will not reduce enough.  That's because another example, like '7', does not need so much reduction, in order to land on a '6.0' result.
By mis-applying the upper range process, to the lower range input (3), it is then up to the electronics interpretation to reject that alternate, and accept the proper processing path.
   Complex and tortuous explanation,...(but I'll live).

[RJSV]

   More on the DECREMENT actions:
   Part of what I wished to show today is the advantage obtained, by using the two ranges, in separated processes, (rather than compromising over the whole single digit range.)
   You can see, first, how the smallish range reduction, of max 9.0 to max 8.5 enables, (barely) compromise by allowing the first (stack) multiplier to be slightly different.  With that in mind, obviously the currently shown complete split, of range (into 2 ranges) gives a break, from such extreme compromise.  Downside is, of course, you need one structure for each set of values...with such structure continued all the way down, to the terminus with it's electronic pick-up.
   Note that the original range, of 0 thru 9, is still the case.  On the other hand, with a base5 or modulo5 structure, you escape the large compromise (of base10) but would need multiple digits, for same range.

[RJSV]

Success ! Wow, (feels anti-climatic).
  It was just a matter of applying linear function to the warped gizzymo that is number lineups.
By going with a bias, up to 4.0, with a FS range of eight counting up to '7.5' , that will do an eight step range, every 1/2 count per step.

   So you would use, encoded, 0 thru 7, at 4.0, 4.5, 5.0,5.5, 6.0,6.5, and 7.0, 7.5 lastly.

[RJSV]

At four through eight, that's a doubling or 2X from start to finish, compared with a nine X rate when using a full 0 thru 9.  So that helps keep things moderated.

[RJSV]

Here's how a quick napkin-jotted set of numbers outlines:
   Going with an optimum close to 0.9 X a brief hand multiply gives '6.9' as result, from '7.5'.  Now, that would be rounded, confirmed, would be rounded between '6.75 and 7.0'. That rounds to '7' as all rounding is now at the +0.25 points, being as that's the physical layer (of encoding).
On the bottom end, checking against a 'single size' multiplier of, again, '0.92 X', the result, from '4.5' is reduction down to a '4.14', and again rounded correct to an integer-like '4'.
Eventually, a couple of spots get error, out one way or another...but nothing like before, where a '9' couldn't even hit an '8' when decrement took that value down, to a '7.2'.  Also, same situation, before, when decrement an '8', by ratio, but would miss '7' integer, count completely.

[RJSV]

So part of this is a two-part deal; first to get a decent workable decrement, for typical code looping, or as close to a typical 'FOR - NEXT' structure as can get.
Maybe entertaining at the least, during times when more suitable optical switching and sensing come on line.
   The other big task being the detection and response, in any loop structure, to the ending point, usually by detection of some index ending value...that's often at zero.  For that end point detect, I'm needing some type of 'Sigma' function, I think it's called:
   A math analog function that 'switches' by exaggerating a value near to a '1.0'.  For example, a squaring function, applied repeatedly to a number like '0.9' will start to decrease, more and more, while a number like '1.1' will, when squared (repeatedly) will increase, eventually exceeding 2X after a few multiples.
   That's one way, of exaggerating a value, around '1.0', as a means of detecting or comparing, in absence of many of the typical microprocessor instructions (but of very high speed).
   The 'hokey' structured response is a bit amusing, but still seriously interesting, as mentioned (back a month or so, in these posts);  Response (to loop count or index decrements) response can be prefaced by an unconditional decrement 'function', which is then conditionally 'CANCELLED' next, by a conditional addition.  That, is to take the place of a typical test and branch (microprocessor) as the conditional add, of some amount of light beam amplitude, is trivial...you just simply 'dump' it in, to the existing beam.  THAT, you can control.
Ironically, doing things this way, would need a practical, working decrement, for accomplishing the process ...surprise surprise (got that!).

[RJSV]

   Subtraction, here, is so difficult to conceptualize that it's been worth the time...obtaining a (partially) decent decrement, in general sense.

[RJSV]

...That last diagram shows a nice compromise, having a large BIAS, (so 4.0 counts is the new 'zero' logical).
The diagram also shows the step sizes, at 1/2 count each, so that 7 steps, in an OCTAL setup, has reduced 'reach', that being from a physical '4.0', counting up on the eight steps, to physical '7.5' count.
   As is the case when two differing formats or scales have been employed, as similarly with temperature readings...where a 'minus 65' degree reading in Fahrenheit is also same reading, in Celsius, just a coincidence.  So, here, a physical value, '8' is also the coded, octal value, '8'.

[RJSV]

Second diagram today, features a manual spreadsheet style table, for each multiplier and column.

[RJSV]

   In that last diagram, I've shown an incomplete view, so readers can see more clearly the stair-steps downward, as each integer values, in turn, gets a decrement.  It's a one-size-fits all deal, so that whichever value is current, in the OCTAL range,
 0 thru 7, that there should be a one by one drop off or drop out of relevance,...meaning that the value has been decremented to and below the 'zero' encoded physical value.
Another bit of detail there is that the rounding is done, now, for 1/2 integers, (4.0, 4.5, 5.0, 5
T etc.), so the actual rounding mechanism is done at value (integer+0.25 counts).  This would mean, for example, the value '4.25' will be rounded upwards, to '4.5.'.
   That part of it is very similar to conventional integer rounding, usually done at '4.5' for example.

   Readers can see the qualities of the spreadsheet page, as having a definitive STAIR-STEP quality, as each integer count, in turn, gets decremented down and past the logical 'zero' which is the physical 4.0 value...(or less).  You can see, in the third row there, that last decrement (pseudo) did not take the result value down enough, reduced to below 4.25, for a valid, coded, zero logical.  That's a problem, to be subject to some additional 'tweaks', otherwise the decrements, overall, aren't going to produce 'perfect' (I.E. digital) results.
My excuse: you shoulda seen the errors, BEFORE, with my older method...

[RJSV]

   Looking at the varieties, of context, for single decrement actions, using ratiometric multiply by
 (X 0.92), it's a one size fits all multiplier, and that function works partially due to the limits of operation placed on the incoming variable; that must be (0 through 7) in the main view, although in cases of underflow, a starting value of eight is used.
This is to initialize for count-down by the decrements, as it is easier to follow the usual decrement structure, so that 'eight' value gets brought down to a '7', right away, in the structure which decrements logical ( 7 to 6, to 5, 4, 3, 2, 1 and, lastly, to 0).  Any routine or code that involks this decrement, can't be entering with a value of 'zero' to decrement, as that won't produce a valid, usable result. (Result just sits, at minimum of 'zero' logical, while actual physical analog value just keeps getting reduced, while already inside 'zero' territory.
Clear as muddy waters, so far. But sorry, this shii, a bit difficult to document !

[RJSV]

...and while this current explanation is in limits, for an OCTAL count output, the same applies, generally, in a full decimal format, (0 - 9).  That is, a separate process must, upon 'underflow' of digit counting, (coordinated elsewhere in the process of counting down), must supply the full-loaded '9', or even a '10' for the immediate count-down to a 'nine' state. 
   Only difference, with OCTAL use is that the upper limit is skipping the last two integers, (9 and , that are not used in OCTAL count-downs.

[RJSV]

   Chaining a few decrements can be done, in absence of any rounding action in between each.  About like predicted, any 'un-rounded' attempts should only last a few trials, at best.  Earlier methods had been using such a sloppy multiplication factor that some would 'skip' such as going '9' down to a '7'.  That particular instance had the multiplier bringing the '9.0' down, to '7.2',...(which could be rounded down to a '7').
   Keep in mind, I hadn't even really expected a single decrement-style action to work...but this should work and in complete absence of any active components or substantial complexity...just a (fast) light 'beam' coded by amplitude and subject to a couple of attenuating steps, (usually done by simple dropping off of portions  of the data BUS).

[RJSV]

   Of course, in this set of schemes there's going to be construction errors / tolerances, initially guessed or gauged at somewhat near to +/- 5 %.  In that sense, a physical encoded count, of '5.0' could be offset by equivalent actual error of +/- 0.25 which is half the step size, when using this 1/2 counts per step, (in the
OCTAL 8 counts from 0 to 7 logical).
Or, in other words, an error of a half-step, plus or minus.

   Other considerations include noise immunity, which relies on keeping out of lower (physical) levels, in the representative 'coded' values.

   Readers might have noticed, earlier; that while the current 'universal' multiplier is around near '0.92' X, when using 1/2 count sized steps...restricting the range to be from 4.0 (code for zero logical), up to '7.5' as the code for logical '7'.
   The older methods used multipliers anywhere from about '0.633' to '0.833', and operating on 8 steps F.S. at one full count each.

[RJSV]

   One structural aspect here that I've not explicitly mentioned is that some of the analog functions have been tailored specifically to do the (limited) job performed for integer math, digit by digit.  The main limitation is the segmentation of ranges (I.E. digital numerical 'macro' columns in base ten), where each separate logical logical range keeps a same or similar physical range:
   What this means is, a multi-digits number like '241', for instance, has each 'macro-column' separate and, likely, same range values.  Then, in that case, if you could consider that 'ones' column as analog 0 thru 1, (such as in a lumen scaled calc), then the 'TENS' column is represented at one-tenth the real or expected amplitude, (and the 'hundreds' column is even worse, at another 10X too small).

   That's not so bad, when processing that example '241', in three separate, distinct actions, while ignoring any needed CARRY or BORROW process.  For a decent BORROW action, though, digit down to lower macro column, you've got to have the expected 10 X relation.
That way, a borrow of a 'one', from upper column, will result in 'ten' units being deposited.

[RJSV]

   To help illustrate my point, the diagram shows how the scope or domain of an analog value is actually only for the immediate purpose, of representing DIGITAL values, or integers, as closely as permits.  Aside from the more simple decrements, (or pseudo), a fully analog computer would have shown that example number in full; that is as value '1234'.
Instead, showing a single analog value as one instance of a full, digital multiplication.  So, a more fully expressed multiply would look like '1234 X 7', as a single operation.  Still the methods used in doing a decrement, ratiometrically, are interesting and can be applied elsewhere, as things develop.

   One nice aspect, I've discovered, in doing that kind of 4 by 1 multiply is that any multiply, with '9999 X 9' being the maximum, there isn't any need for carry propagation in that limited case.  Nice as the carry or borrow situation needs to act across columns and thus, as mentioned, you've really got to have the conventional 10X relation, column to column, for carry to be proper amplitude.
   (You can see, at bottom of enclosed diagram, the case for the maximum four digit multiply).

[RJSV]

   What I've indicated, is that, while a partial multiply, like '4 X 7' DOES extend over one column, with the '2' in the result of '28' the point is that the adding up of all the values, from partial multiplies, does not exceed '9' and thus there is no carry propagation caused there.
Worst case, you get a '9' from adding the partials (please also see previous diagram, bottom), so, while you do have to add up the two partials, you can be confident that no carry handler is needed.

[RJSV]

   For management purposes, a project tracking graph displays a couple of goals:

[RJSV]

 In that graph, (last post), a management tool or project tracking for schedules, the first goal looks good, while the other two have promise...albeit a distant one.
   Doing a single decrement is nicely done, although more simply within the bounds of ' normal rounding'.
Perhaps be said as 'analog that closely tries to follow digital form, or step-wise form.

   So, graph shows lower bounds, where there isn't really any functional benefit, or promise of that.
Upper dotted-line bound is where function gets pretty good, maybe ALMOST as good, as something like binary TTL electronics.

[RJSV]

   Lots of speculation on how to get a decent level compare operation.
   Enclosed graph shows typical number squared, with unity point matching...that being '1 X 1' = 1.
   If you've multiplies out, at various points, it nicely separates, where any input above 1 gets increased, (when squared) while inputs lower than '1' get diminished (when any squaring action gets repeated).
Firstly, you could (somehow) use this to separate out, finely, anything even the slightest bit above a '1.0' will get 'blown upwards' to grow large, by way of repeated squaring.
Similarly, any number, just a bit under a '1.0', like '0.93' will also, quickly, move; this time downwards from the '1.0' inflection point.  In both those cases it takes about four iterations, to obtain a '2X' or a '1/2 X' result, from original value being tested.

   Now, having those 'exagerated' values in hand, I would next need to have a 'digitizing' action.  That would turn an extremely large number, like '42', into just a one... a digital '1' to be used as an 'enable'.  So there's that.
On the low side, would want anything less than '1.0' to be (thresholded) to a 'zero', actually difficult to impossible, with these passive optical components.
But, to enable/disable it might be possible to use the parameter (being tested) in an exponent.  That way, instead of AVOIDING some multiply or some addition, conditionally, the optical set-up simply performs the function, thus unconditionally.  Then, adding some very small factor can be almost the same as conditionally doing nothing. (Edit)

   On the high side, of that, any variable that goes ABOVE a '1.0' would, or could potentially, act as an enable by way of setting the exponent (to a '1').

The whole methodology is, as been presented, a 'blind' functional, having no practical 'compare' or 'zero test', (or even explicit PC or program counter).

Passive/Aggressive; I should call it !

[RJSV]

Graph.

[RJSV]

   So the idea is, that even if you can't do a typical test, (for loop ending or finished), like;
   DO WHILE Index>0

   ...you can avoid the testing, directly, but incorporate the variable (loop index in this case) incorporate into some number being manipulated, unconditionally.

   But leaving THAT bugaboo aside, for minute, (and turning back to the diagram of squared number), you can notice that the (starting) values below that '1.0' inflection point will decrease, exponentially, you would get:
   '1/2 squared to 1/4, then 1/4 squared to 1/16...etc',
Noticing that, in my case it would be '0.9' squared to '0.81', then squared to '0.65', then to '0.42'...You can use a rule of thumb, that about 4 operations will get your value reduced by about half.
Now since (I haven't) developer here doesn't have answer for even the basic action of a fully general number by number multiply, there can be a substitute, for general number squaring(!)
Just, simply multiply by '0.9' repeatedly...THAT simple substitute function will ALSO cause an approximate value reduction by one-half.  That's the sort of crude, out of the box thinking required.
Free and loose with the math.

   However, looking at the high end, of the X squared results, those values would not conform to what I want, as the graph, above the '1.0' inflection would not increase, each step, from any substitution of 'X 0.9' over a straight up square, of the value.


At any rate the behaviour I seek can be shown, when starting at '1.05', a number barely above '1.0', when squared gives '1.1', and subsequent '1.21', '1.44', and value '2.07', giving you that doubling effect, every four operations.


   Several missing pieces, but my COMPETITION is hot on my tail...
pretty sure.
--Rick B.

[RJSV]

Oh, and don't forget, this aspect of an optical data BUS is ENCODED, with special offset and ranges.  That being a '4.0' as coded representative, for 'zero' logical.
Your '1.0' logical value being discussed in past few posts, actually will be, physically, at '4.5' being as each integer logical count is size '0.5' realistically.
Since the physical counts are 1/2 sized, then your rounding value, of a one vs. a zero, is at
   '4.25', meaning that anything below '4.25' is considered a logical 'zero'.

   Now, taking this and running with it, I've (intuitively) hit upon a suggestive formula, by way of multiply, by '0.9', a typically seen multiplier, in this thread, but then a 'replacement' or restoration, back to 100% , and that's done by adding back in: a '0.45'.
   This is going to seem cryptic, if lack of explanation, but that '0.45' is from the '4.5', that is the coded version, of a 'one' logical value.
So, if at the inflection point, you do an 'X 0.9' and then put it back by adding '0.45', thus you could say, any input of a 'one logical' will just end up not moving, staying at a 'one'.
   At another number, though, such as (coded) '5', which is representing a logical 'two', then that '0.45' being added back in (after diminishing by X .9), that '0.45' is going to be a bit too low, giving a result of '0.495'.
THAT isn't good, as I seek DIVERGENCE, from inflection, not closer each time.
Similar problem, on lower end, where a coded 'zero' logical, at physical '4.0' or nearby, will be increased, slightly, but again, does not diverge.

   That looks like: '4.0 X 0.9 = 3.6'
        Then '3.6 + .45 = '4.05' so you can see the slight little 'creep', towards inflection at '1.0' (coded at 4.5), rather than the needed 'crawl' downward.  That way, you could get the 2X change, after about four reductions, the needed change that (would have) gotten that value below significance, (and thus you would have had conditional-like action).

"Conditional pseudo functions, CODED analog doing (octal) or near-octal logical...This shiit is making 'blind pseudo-decrements look like a cake-walk.
Competition is heating up, I feel.

[RJSV]

Might be a little sloppy, but happened upon a substitute for general multiplying.  That is, a multiply where it's not one 'permanent' channel or attenuator against a beam amplitude
   Substituting a 2X of factorial gives an excitingly close valued set of numbers,...for instance 7 squared is going to show as '28+28= 56' or 7 too high over 49.

Using input '9', gives '45+45' or 90,...a value a little too high, at 9 above the correct value, '81'.

   For purposes here, it's the divergent properties, but that doesn't stop the use for other, possibly inexact processes.

[RJSV]

Now doing a spot-check, on some multiplies, that aren't squares;
   Trying '5 X 3', you get 5! = 15, with 3!= 6.  So that appears as '21',...at 6 above correct value.   Still not real bad, and possibly correctable.

   Trying '2 X 7', you get '31',...obviously way too far off to be practible.  But most multiplications get closer.
   Trying '7 X 5' gives '43' which isn't far from the correct value of '35'.  Or at least within an order of magnitude.

[RJSV]

Graph shows three curves, doing squares of three starting points:

[RJSV]

(Sorry, that graph needed to go asymptote to zero).

   Graph shows after a few runs, squaring a starting number, you can see; at '1.0', exact, it's unstable but would (continue) producing same new value...if it weren't for a little noise, up or down, in total amplitude.
But starting slightly above an exact '1.0', like at '1.1' will soon go up, approx double, in 3 repeats.
In similar fashion, a start of '0.9' will, after 3 repeats, get you to approx '0.42', or a 1/2 of start.

   Hopefully, a group of repeats can exaggerate this result.  You can see how, after a bunch of repeats, the lower start, of '0.9' will get diminished, more and more.

[RJSV]

   The lower curve, on the squares graph, will go small, fairly quickly, and so it could be used in a conditional test...as a multiplier.     Err; that is, to say my multiplier function don't work, with 2 variables generally.
One of the multiply parameters has to be built-in, structural.

   The other curve, upper curve, takes you nicely upwards, from integer '1.0' but I'm not sure how to get it to saturate, to a consistent form.

Multiply functionality needs a usable, testable decrement, while a COMPLETE decrement functionality needs...a multiply.  That is for doing the squares, in the conditional test.

[RJSV]

Also,...whilst I confessing my sins, that FACTORIAL function mentioned has same flaw / barrier to properly working, having to include a 'counted' addition (same as any multiply would).  That is, any multiply or squaring can be done by way of repeated additions, but still (haven't) solved the methodology for end-of-loop testing (for a zero result).

   As BOSS might say: First try to implement these things (microprocessor instructions), but in absence of progress there, AT LEAST document the effort...That way you can account for time spent (minimal anyway).
You've got a pretty decent estimating decrement, but no real way to test that status.

[RJSV]

Of course, need to update the encoded version, when adding, it's not so simple and primitive, as the (former) physical combining.

   For example, resembling doing any heavy binary math notation, it's just different, some.  Example of doing addition of '3 + 2' where the numbers encoded would now be:
    '4.0 + 3/2' or '5.5' plus '4.0 + 2/2' or '5.0'.
Doing that encoded addition gives result of '10.5' which contains TWO of the base offsets, so subtract a four will give you the answer, encoded with the usual base of '4.0' and at 1/2 scale.  That would be '6.5' result, which is an encoded '5' or the correct answer in uncoded or 'logical' vs physical terms.
   Or, another approach could be to use the answer 'low bits' so to speak; That is if you are using encoded OCTAL, that way can just ignore the upper order, and use the lower 3 bits, encoded.

[RJSV]

   If you take a look at photo, that's a decorative optical fiber 'tree', although I'm not sure if in this case the type of fiber useful in longer distance digital links.   The communication type will have a fiber core that has different refraction index.

   Obviously, predictably, some of the various approaches to passive optical logic (here) have stalled a bit.  Still worth the time (a modest amount).  Lately the problems have revolved around getting suitable video materials, for continued study.

   I'm finding yt videos where approx. 80 % have language and/or basic audio troubles, in comprehending halting language barriers; with a sense that many of these presentations are not taking coherence into account.  I tend to select those yt videos that run for more than 15 minutes, and 'click out' when/if the presentation is, well, continuously indiscernible as to coherence!

   Anyway, some plans are to continue experiments on the bench, using fibers and various optical sensing diodes.

[MK14]

   If you take a look at photo, that's a decorative optical fiber 'tree', although I'm not sure if in this case the type of fiber useful in longer distance digital links.   The communication type will have a fiber core that has different refraction index.

Yes, it would be interesting to know (no sarcasm is either intended or implied here, I'm just illustrating a point), the difference between a circa (I don't know the price, so only guessing), $1 budget set of decorative tree, optical fibres, and a full on research team/company, with a $50 million dollar, annual research budget, and using the latest, high tech (possibly early prototypes, not available for sale, anywhere), optical fibres, of just about the highest available quality, anywhere in the known universe (except dreams and star trek, or similar).

[RJSV]

   I've shown this method before (please see photo).  By snipping off the garden light's LED those two leads, from that little circuit board, can be conveniently plugged straight into a proto board.  Here, I've just simply added in a RED LED from parts bin, but various other items, such as a transistor can utilize the garden light output (from the simple buck circuit).
   That voltage multiplying buck circuit runs at some 220 khz, producing around +3volts for the LED.

   Now, for my purposes that garden light isn't any where near to being switched due to light from a few strands of the fibers (or even the whole bunch), as the intensity is just too low.  But still, I'm curious as to what voltage (changes) happen...A couple of fibers worth of light might only cause an(edit) increase of a couple of micro-Volts.  (edit) That, of course, is measured at the solar cell, nominal 2.5 volts in bright light.
Certainly, that switch arrangement requires a quantity of light you would expect from a full flashlight, rather than a couple strands of fiber, where the flashlight illuminates the whole bunch.
Just curious.

[RJSV]

   Thanks, MK14.
   Previous ventures soaked up about $ 25 k, to obtain a 'real' office setting and start buying needed tools.  But those are single instance expenses, office rent ongoing but not very much ($220).
Ongoing, beyond initial seed money, was rent and labor time...lots and lots of labor time.  I took on a job, when it was offered, so that helped with paying the office rent.  Overall, was 5+ years with some productive outcome...(mostly gained wisdom), and better appreciation for US Patent Office procedures...

[RJSV]

   Now, since I'm going to be trying out a single, extremely feeble portion of total light, via one isolated strand of that (decorative tree), I started on kitchen table, getting a rough count, (of total fibers there).

   The bundle diameter is close to 9/16 inch, where the area calculates to, est. π/12.6 sq inches (roughly 1/4).
The fiber 'gauge', lacking a handy micrometer, was then estimated: 20 fibers side by side takes up 11/32 ". comes to est. 17.6 thousandths of inch.  So, I used 20 here, Fibers est. at 20 thousandths diameter.

   Run that out, total area divided by area of a single fiber (fiber is est. π\ 10,000); that divides to 10,000/12 or about 833 fibers !

   (Wow, lucky, that's a 'magic' number...or at least 0.833 is...    That's 6/7ths).

   Anyway, if you figure around 1000 fibers, or 833, that's the factor of reduction.  So, if a 10 milliwatt LED manages to shine about 4 mW directed into that bundle, you 'could' expect around 4 MICROwatts at the end of exactly one fiber, separated and isolated by dark cloth. 
   That also would apply, approximately, to say a viewer's perception, each of the tiny tiny points seem almost to be less intense,...than the stars, individually seen, at night.  Wow.

These preliminary estimates are to be checked and measured next, on the bench.

[RJSV]

   Measuring voltage response, using solar cell as sensor, like the garden light's do;
   With minor light leaks, through cloth, the little solar cell reads 0.030 (30 milliVolts), and then with 'signal' we read 0.520 volts, approx. which is the response I'm looking to measure, while using small bundle.
Small fiber bundle is approx. 1/16 of area of full, 1000 strands, or about 62 fibers, at 250 microWatts total.
If that's correct, it's close to 4 microWatts estimated, per fiber.  (That's when assuming 4 milliwatts goes into the whole, 1000 fiber bundle.)

[RJSV]

Please forgive, some of these preliminary numbers aren't trustworthy yet.
   Paring down to FIVE individual fibers, out of the 1000 fiber bundle, I've gotten it to go through change of 0.008 volts (8 milliVolts), dark, changing to 0.030 (30 millivolts), illuminated, with 5 strands.

   However, I need to solidify things, on the table here, as my light baffle has to securely hold the 5 little optical fibers, while simultaneously blocking and holding the rest of the bundle secure.
But, it looks like the electronic aspects, of detecting that little portion of light is easy, if feeble.  Need to set up to read that photocell current as well, but seems a sensitive FET can easily handle the (30 mV), even if total power isn't much.
Tomorrow, better test jig...

[RJSV]

   Wanted to briefly show, an older concept, of using the lawn lights as digital switches, having less layout rules, as it's light beam paths that carry signals, where usual electronics has...wirrs.
(That's broken slang, for 'Wires').
I noticed right away, that such 'amorphous' gate interplay was causing a latching ability, similar to cross-connected gates.

[RJSV]

(Electronics would simply run traces wherever needed, regardless of any requirement (in optical) for running 'straight line' signal paths.

[RJSV]

So also, while viewing the last two Garden Light layout arrangements it should be clarified that the 'two' inputs featured, in the NOR gate illustrations, the meaning is really 'one or more' inputs, depending on where each light beam is traveling.  Two inputs shows, how the little gates can be used as '2 input NOR' logic.
In an 'accidental' bio-system layout, that random orientation would be, could be, massive numbers, like hundreds of tiny cells, waiting for evolutionary selection to act.  Eventually, a complex system could emerge, from the disorganized jumble presented here.

The latter diagram shows a nicely reorganized and more clearly discernable structure...implementing classic 'SR' FlipFlop.

[RJSV]

Maybe not obvious, but in context of popular neuro-network analog qualities, you would have attenuation (i.e. adjusting analog input weights), caused or controlled through device spacing and optical beam angles.
Of course this sort of free-space in 3-D layout wouldn't be used in some of the integrated devices...they used optical fibers and conduits, waveguides, rather than free space setups.

[RJSV]

One point is, with the above 'amorphous' jumble of gates, is that such functions as edge detection and signal changing sensitivity (with steady state staying more quiet) are hallmarks of biological neurology.
Note that the human visual system has mechanisms dedicated to detecting and conveying when something changes, rather than just some steady state, transferring something like only 1 % of info from the eyes, to higher brain activity.
That's thanks to "Neurological Science for Dummies",
Author Frank Amthor.