Optical Bench REDUX: Digital Switching can have Analog Functions!

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