You may have heard the expression: Rubbish in, rubbish out.
Forty years ago Coco used a early version of SuperCalc (SC2 – a spreadsheet like Excel for those who cannot remember) for the preparation of monthly reports under the operating system C/PM. It was ‘cutting’ edge at the time using simple lists of transactions which were converted into a report showing monthly, cumulative and projected figures against a flexible budget. Coco shall not go into the technical details of this. It was not many months before Coco noticed that the report sometimes did not balance.
How could that be? The original data was complete, and balanced. Careful examination of the code indicated that nothing had been left out. It was only when Coco had set the code to run step by step, updating the display at each step, that quite by accident the problem revealed itself. As you will know, and if you do not, ledger accounts have two sides, a debit (on the left) and a credit (on the right). The code identified separately each debit total and each credit total for every account. This is important for the grand total of the debits and the credits must agree. In order to obtain the balance on the account for the report, the difference between the debits and the credits on each account must be determined. That was a very simple action. Put the debits into column A, the credits into column B, calculate the balance in and pick it up from column C.
This is where the mistake occurred. As SuperCalc accepted the values in column B it erased the value in every 16th row, and only every sixteenth row, in column A.
It is said that, for a given set of inputs a computer will always give the same result. You may give it that set of inputs any number of times, nothing will ever be different. If something is different, then it you must look at the programme not the inputs.
Coco never found out what it was in the SuperCalc code that prompted it to do this, but it was consistent. The correct solution was to fix SuperCalc, but my solution was not to try to fix SuperCalc but to fix the data to work around the error. Coco added dummy accounts into the system, each of which would have no data assigned to them and would fall onto these 16th rows. After that the reports balanced. It was a concern however that there might be something else lying around which would creep up unawares. We found such things were lurking later, when the then victorious Excel now and again got an arithmetic calculation wrong. The problem is still with us today if we expect say +(1-0.1-0.1-0.1-0.1-0.1-0.1-0.1-0.1-0.1-0.1) to be 0, it is not quite zero.
So we consider the mRNA vaccine, where it is reported (Covid study: mRNA vaccines could be fine-tuned) that there is a one in three probability that the ribosome will incorrectly read the data held in the mRNA. The solution is, so they say, to use non-slip mRNA, which will eradicate the incorrect reading of the data. They speak of the data as code, and code it is, just as this note is itself written in an alphabetic code which we read with our eyes and interpret with our brains.
The data, the code, however is read (just as Coco’s data was read by the SuperCalc code) by a ribosome, which is itself a complex chemical machine with its own code that interacts with the data in the mRNA. If one in three times the reading of the data produces a different result it suggests that it is something in the ribosomes that are reading the data that is different. Changing the data may, as it did for Coco, skip the thing that we do not understand that actually makes the difference, but the thing we do not understand is still there waiting to catch us out in different circumstances.
There is another possibility. Coco mentioned above that a given set of inputs will always yield the same output. We have seen many situations in the electronic world where this did not seem to be the case. Careful examination showed however that the starting conditions, which we thought were identical were not. A prior process, which may or may not have taken place, influenced the results of the later inputs. There was, if you like, an unknown input over which we had no control, which changed the result. This was unlike Coco’s SuperCalc problem.
Should we not try to understand why the same set of data, the same code, produces different outcomes one in three times before we say we have fixed it? Coco did not fix his problem, Coco merely worked around it, not knowing what other problems may arise later. What is it that causes the ribosome to read the data ‘incorrectly’ one in three times? Or is it that it is the two in three times that it does what we want it to do that is the incorrect result?
The unintended result of the misreading, or possibly correct reading, of the mRNA is the production of a few unintended proteins. Coco thinks that the implication is ‘harmless’ proteins, but that is not actually said. So the workaround is to change the mRNA, the data, in such a way that the ribosome will always read the data as we want it to: but do we understand why it read the original data in two different ways, not just occasionally but quite regularly? What else was going on? What was the unknown input that caused the data to be read in either of the two different ways? We have not addressed that, have we?
To address the matter with a workaround in the data is both reckless and negligent. When Coco used a workaround, he was only dealing with the reporting of how money gathered and how it had been used, the reporting is important, yes, but mRNA affects people’s lives.