As I stated earlier, CodeFinder calculates the matrix R-values for the Matrix Report, which is displayed by a menu selection after you develop the matrix. The Matrix Report lists every term displayed in the matrix and has a column for text R-value and matrix R-value for each term. At this point, the matrix R-value is far more important.
What can we do with the matrix R-values? One thing we can do is sum the matrix R-values for those terms with positive matrix R-values to arrive at an overall R-value for the matrix. Why would we sum only the positive R-values? The answer is in the table above, where we see that with negative matrix R-values, we have expected occurrences of greater than 1.000. This means that we almost certainly expect to find a term with an expected occurrence of 1.000 within the matrix. Those negative matrix R-value terms do not add anything to the probability of the matrix, and frankly we could turn off the smaller terms with negative matrix R-values from display in the matrix. Therefore, we add only the positive matrix R-values for terms to get the overall R-value for the matrix. What does the overall R-value for the matrix tell us?
We can reverse the equation above to arrive at the Eoverall, as follows:
Once we have the Eoverall calculated, then we have a measure of the probability of the matrix. If you have log tables or an inexpensive scientific calculator, you can easily calculate log and antilog. For example, if we summed the positive matrix R-values in a matrix and came up with +6.000, then there is a 1 in 1 million probability for the occurrence of the matrix in a random text.
Does this method give an accurate probability for the matrix? No, and the reason why is that it only determines the probability that the terms would appear anywhere in the matrix. It neglects clusters of terms in the matrix and doesn't account for distance between related terms or their close proximity. The actual accurate probability of the matrix is going to be much less likely than we calculate using R-values. In fact, that method of accurately taking into account proximity or distance between terms, or the probability of clusters of terms, has not yet been invented. Part 3 of this article will explain what needs to be done to accurately calculate the probability of terms using distance, the different proposed solutions, and current progress.
The following is shown solely to demonstrate the usefulness of R-values and is not accurate, with the full Sid Roth life matrix statistical calculation shown in Part 4 Let's walk through this very rough (and not accurate enough) method of calculating the probability of a matrix. We'll use my recent life matrix on Sid Roth, in the Hebrew matrixes section of this website. The matrix has 8 very large clusters within the matrix, and 73 terms overall. We cannot calculate the probability of the 8 clusters using only matrix R-values, but we can calculate the probability that the terms would appear anywhere in the matrix. First we sum all the positive R-value terms and we get overall R-value equal to 5.431.
Therefore, the probability of the Sid Roth life matrix just using matrix R-values is 3.7 chances in a million, or 1 chance in 269,773.9. If fully calculated by taking into account the 8 large clusters, the probability of the matrix is even far less likely. See part 4 for the full calculation of probability.
In the meantime, CodeFinder users have a powerful first step in arriving at the probability of the matrix handy in using the matrix R-values in the Matrix Report. We actually had built in the reversal method in the CodeFinder program in the beta for the next version (1.21), but realized that the probability is not accurate enough for the overall matrix, and it was removed from the summary in the Matrix Report.
There is one additional point that needs to be made for CodeFinder users. Kevin Acres built in a slightly different calculation for determing the matrix R-values of terms at an ELS of +1. Terms at an ELS of +1 are in the normal surface scriptures of the text. In that case, CodeFinder actually counts the number of occurrences of the term in the surface text, and uses that measure of actual occurrences rather than using expected occurrences. Therefore, terms at an ELS of +1 are going to have a different matrix R-value than would be expected in a random text. Many codes researchers avoid using terms in the surface scriptures, but for those who do, the matrix R-value should reflect actual occurrences as calculated by the CodeFinder program, rather than expected occurrences in a random text. In most cases, this gives a lower matrix R-value for terms at an ELS of +1.
Another point specific to the CodeFinder software program is on the display of expected occurrences. When CodeFinder calculates the expected occurrence for a term that is less than one, it shows something like this in the lower right corner of the screen: EXPECT 7.81559575622489E-8. Some CodeFinder users have their screen size set smaller so that they cannot read the entire expected occurrence number and miss seeing the E-8 at the end. Then they write to me and say that CodeFinder doesn't calculate expected occurrences accurately. They say that when they look in Search Parameters for that same term, it shows an expected occurrence of about 0.0. They say, "how can it give an expected occurrence of 7.81 on the main screen, and in Search Parameters show an expected occurrence of about 0.0?" The error is not in the software program, it is due to user error, where you don't see the E-8 at the end of the expected occurrences number. Instead of showing a lot of leading zeros in the decimal for expected occurrences, it is standard practice to show the first significant digit as a whole number and multiply it by E (~2.7182818) to a negative power. Therefore, when you see an expected occurrence with an E-x at the end, you should know that the expected occurrence is far less than 1.0, and probably less than 0.01.
.