Optical Bench REDUX: Digital Switching can have Analog Functions!

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