Products > Dodgy Technology

Optical Bench REDUX: Digital Switching can have Analog Functions!

<< < (46/63) > >>

   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.

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

   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.8)' 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' 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...


   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'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

   Considering the multiply operation itself, turns out the X0 point8 (X 0.8), 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. 


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod