(preface: what follows is a cut/paste of a post I did some time back. There is a less easy to follow and less insightful bit of information on my old web page first published ~1990. In 1987 I conducted the research into the evolution of the upc code and studied the engineering implications of emerging technologies as they related to the possibility of having a mark which would meet the qualifications of the one described in Revelation. Mysteriously this information appeared in more graphic form on the 'dial a truth' page sometime after I began publishing that and the fellow from there Terry spammed me and treated me rudely. Whatever. As long as the truth is being put out and people are aware that they need to make a choice to reject the world's religion, which is Lucifer's religion he presented to Adam and Eve so long ago in the garden.)
Hang with me here. A computer program that is giving code to a microprocessor which evaluates the incoming data from the scanner *might* be reading the black lines as 1's and the white lines as 0's, or visa versa. In fact in this upc format they actually do ONE of those on one side of the 'median' and the other on the other side.
But anyway, pick one. It doesn't matter. Because the number you will see there, (assuming that there is a white line after the last dark one) is totally readable as 666 one direction with blacks and 1's....and the other with whites as one's. :-) Kind of freaky huh? I might add for the mathematically impaired, that numbers like 222, 333, 444, 555, etc. do not possess this property. For example 11011110 is 222. Notice that while the OUTER two numbers are indeed mirror inverse image....the next two are both 1's and hence this number doesn't do that little trick.
The engineering reasons why this is important will be made evident...but for now I just want you to realize that this isn't even dependent. Because the PROPHECY is about a human being looking WITH WISDOM at the number ...and simply calculating it. A wise person would obviously check both bit polarities...and both directions. And..interestingly enough one of them works both directions. Provided like I say that, to serve it's function, there need only be one zero on the right.
1010011010 appears to be what I read if I go from left to right and ASSUME (out of my engineering wisdom) that the "0" on the end has to be there. Why? (Hoping you understand here. I'm talking about the fact that it could be presumed since there's just white space out there....that there are no zeros represented by it..that the black line is the last actual data in the check code....or that there are several zero's.)
This is where you really have to read/understand the whole article I wrote. Because it's all about having an optimal check code in THE FUTURE's highly optimized codes that they put on humans. See like I say on my page I seem to recall...I'm not sure why this number appears to be in the present check code. Because I mean they could have done other things that would have worked just as well and avoided having people say 'hey 666 is in the upc code!'. However, they didn't. Was it a practical joke? I mean...computer people..like to do that kind of thing I've noticed in the past.:-).
But regardless, the thing that made me believe that this number was going to BE the check code in the mark of the beast is this. STrap in...and ride with me on a beam of light.
Here we go. We're moving rapidly across the target pattern we are being pointed at. As we reflect off the target, we move to a sensor that notes the intensity of our reflection. And it makes an assessment about where the beam is at that point. Now recall, the mechanism that orients us has NO idea which direction the hand or forehead we are scanning currently is oriented.
After our first pass, the firmware has noted that it can't get valid data yet. So the orientation of the scanner's pivoting beam is rotated and we try again. Oops. Still no good. One more orientation and..OK we're getting data! The sensor notes The two broad white spaces as it comes reverse direction, then begins accumulating data as it reads the two black lines on the other half of the "median", which this idealized check code is forming. Then it senses a single white line, which resets the 'position pointer', a firmware article which allows the machine to distinguish between one black line and two for instance. The code micro-calibrates so that errors due to the angle of the scan are blocked out possibly. Other applications may just keep incrementing the rotation til everything is just right but, in this application we also have to take into account that the forehead, for instance, might be slanted in such a way as to create lines that appear to the scanner as closer than they actually are if viewed from a flat plane perspective.
See...there's a lot to explain. This is how firmware is written though. We have to consider all possibilities to make a foolproof application.
Anyway so at some point let's say we got a data error (by way of parity checking. Having distinguished the median lines we at least know which side of the code we are on and hence which parity type is being used. (Parity is odd on one side and even on the other also. Can't recall which is which without thinking about it. But it doesn't matter for now. )
At this point, the rotation is incremented again and this time we'll probably get a good read. So back we go streaking the other direction. And this time of course the sensor detects the two long black lines first, then we begin accumulating data with the two white lines, then a dark one, a single light one, and the final dark one. AT THIS POINT the firmware compares the accumulated data to a number that is stored in the 'immediate access register' of the microprocessor at the beginning of each scan direction. It asks 'is this number fetched = to 11010? IF NOT, then the next instruction is "is fetched number the NOT of 11010?" This requires only one instruction cycle and is nicer than loading another number for speed and simplicity.
Then we begin reading the actual data. PERFECT! All data parity plus the check code matched. We store the fetched data and reload the immediate register with 11010 again. Back the other direction goes our beam of light. It again ignores all the lines until if finds the two long double lines. Then repeats the process above checking for opposite parity.
Ok, so..what happened DURING those scans across the error check code?
The double lines being recognized as two proved that the sync is working at least well enough to tell two from one line. Then there is the most concise combination which provides a single line of BOTH types on both sides. As I said, this is so that we can verify that the machine can recognize the narrowest possible lines of both types to verify that it has minimal contrast recognition in both the lights and darks.
I don't think I explained this as well on my web page as I did here. That was written a long time ago. I think I communicate better now hopefully :-). But anyway....
So basically both halves of the code verify that RIGHT BEFORE READING THE DATA on THIS PASS.....all the essential minimal requirements have been met. The two asymmetrical halves have the BEAUTY of not only possessing all the combinations essential, but ALSO impart the knowledge of which direction we are scanning so that the computer knows which parity check type to load, and which BCD (binary coded decimal) set to be checking for in the data on that side.
There is no other combination of bits possible which satisfies these engineering requirements. This is simply the shortest possible number that does all that and serves as a nice median to boot. The beauty...ahem.....of the beast. -Bob