MRB DECIMAL - ENTRY INDEPENDENT SPOT CHECKER
MRB DECIMAL - ENTRY INDEPENDENT SPOT CHECKER
From a conversation with GPT. The author (Marvin Ray Burns) takes full responsibility of all claims in this notebook.
This version takes only the claimed CMRB value/digit file . It does not require you to supply a known - correct CMRB value . It independently computes what it needs from the defining MRB series using NSum, caches that calculation, and tests the claimed decimal - entry parity against it . One unavoidable point : some independent computation of MRB is mathematically necessary . What we have eliminated is the need to provide a previously known correct value .
In[]:=
First test : a known - correct value
You can calculate your 10, 000 - digit claim as before :
You can calculate your 10, 000 - digit claim as before :
In[]:=
mrbClaim=N[NSum[(-1)^n(n^(1/n)-1),{n,1,Infinity},Method->"AlternatingSigns",WorkingPrecision->10010],10000];
Then:
In[]:=
good=MRBClaimSpotCheck[mrbClaim,{1000,1250,1500,2000,2500,3000,4000}];good["Summary"]good["Results"]
Computing an independent MRB reference from the defining series...
Target decimal digits: 8130
Working precision: 8160
Independent usable digits: 8110
Out[]=
Requested7,Resolved7,Passed7,Failed0,PrefixFailures0,Unresolved0,IndependentDigits8110,IndependentAccuracy8130.73
Out[]=
The checker will independently calculate its own reference . The first call does the expensive calculation; later tests reuse it . Then deliberately spoil digit 2001
First convert the claim :
First convert the claim :
In[]:=
claimDigits=MRBLoadDigits[mrbClaim];
Force digit 2001 into the opposite class :
In[]:=
wrongClaim=MRBFlipNextDigitClass[claimDigits,2000];
Now :
In[]:=
bad=MRBClaimSpotCheck[wrongClaim,{2000}];bad["Summary"]bad["Results"]
Out[]=
Requested1,Resolved1,Passed0,Failed1,PrefixFailures0,Unresolved0,IndependentDigits8110,IndependentAccuracy8130.73
Out[]=
That should produce a parity contradiction . For the value we saw earlier, the good digit at position 2001 was in the 0–4 class, so the deliberately flipped claim should predict the opposite parity and fail . Your 10
−2000
/e experiment
You can also test a naturally corrupted numerical value :
−2000
/e experiment
You can also test a naturally corrupted numerical value :
In[]:=
wrongNumericalClaim=mrbClaim-N[10^-2000/E,10000];
Then :
In[]:=
bad2=MRBClaimSpotCheck[wrongNumericalClaim,{1998,1999,2000,2001,2002,2010}];bad2["Summary"]bad2["Results"]
Out[]=
Requested6,Resolved6,Passed2,Failed4,PrefixFailures4,Unresolved0,IndependentDigits8110,IndependentAccuracy8130.73
Out[]=
Here I expect the program to detect either a prefix failure or a parity failure at the point where the perturbation first becomes visible . One especially useful control remains : deliberately replace a digit with a different digit in the same half . The exact - digit column should say False, while the parity test may still say True . That is precisely what the theorem predicts : it checks the binary division
0, 1, 2, 3, 4 versus5, 6, 7, 8, 9, not the exact digit .
0, 1, 2, 3, 4 versus5, 6, 7, 8, 9, not the exact digit .