Products > Dodgy Technology

Optical Bench REDUX: Digital Switching can have Analog Functions!

<< < (63/71) > >>

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