Products > Dodgy Technology

Optical Bench REDUX: Digital Switching can have Analog Functions!

<< < (64/71) > >>

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 !