{"id":"359d2f35-cd51-430b-bbda-a89411570908","arxiv_id":"2608.06438","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"low","formal_verification":"none","parameter_count":1,"one_line_summary":"Pi's decimal digits, fed into a Monte Carlo circle-area estimator, reproduce pi as 3.14159313 ± 0.00000035, confirming the digits' practical randomness at record scale.","lead":"A group of physicists used the 314 trillion digits of pi themselves as random numbers in a Monte Carlo simulation, and the simulation recovered pi to seven decimal places. The result is an empirical stress test of how random pi's digits actually are, using the largest pi dataset ever computed.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's central numerical result is internally inconsistent: Section 2 derives/uses 14 digits per point, Section 3 describes 16 digits per point, and the reported counts match only 14. This makes the estimate and its quoted uncertainty unreproducible as written.","rationale":"The paper's empirical setup is simple, and the statistical idea of using a long pseudorandom-looking stream to estimate pi is sound. The key evidence is the single Monte Carlo estimate in Eq. (14), so the exact definition of the sample matters enormously. The manuscript fails that test: the sample construction is described in two incompatible ways. Section 2's arithmetic error (ceil(log10(1.772e7))=7 instead of 8) would justify 8 digits per coordinate, not 7; Section 3 says 8+8, but the reported totals and the hit count are numerically consistent only with 7+7. This is not a cosmetic inconsistency: with 7-digit coordinates there is a lattice-discretization bias of order 10^-7 in pi, which is comparable to the quoted uncertainty, and with 16-digit blocks the given N is impossible. The reader's independence concern is legitimate but partially answered by the paper's comparison of chunk-level and binomial standard errors; the block-size contradiction is unaddressed and blocks verification. A simple rerun with instrumented code would settle it. I therefore do not move the verdict: the paper should remain conditional until the mapping and counts are reconciled and the discretization bias, if any, is included.","tokens_in":5356,"tokens_out":14928,"duration_ms":151698,"concrete_test":"Run the public Backblaze digit files through two independent tallies: (A) non-overlapping 14-digit blocks (x=first 7 digits, y=next 7) and (B) non-overlapping 16-digit blocks (8+8), recording total points and hits. Check which mapping reproduces N_in=17,615,350,257,158 and N=22,428,557,114,832. For mapping (A), also compute the exact lattice count of grid points with i,j in [0,10^7-1] and i^2+j^2<=10^14; compare 4 times that count divided by 10^14 to pi. If mapping (A) is the true one and the lattice bias exceeds about 1e-7, the error budget in Eq. (16) must include it; if mapping (B) is the true one, the reported counts must be corrected and the discrepancy explained.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing weakness is an internal inconsistency in the construction of the sample, not the explicitly acknowledged non-independence of pi's digits. In Section 2, Eqs. (5)-(8) set n_x=n_y=ceil(log10 sqrt(314e12))=7 and therefore use 14 digits per point, giving N=22.4e12. But sqrt(314e12)=1.772e7, whose base-10 logarithm is about 7.25; the ceiling is 8, not 7. Thus the derivation of the 14-digit mapping is arithmetically wrong. In Section 3, Eqs. (10)-(11) instead state that each worker consumes blocks of sixteen digits (8 per coordinate), yet the reported total in Eq. (15), sum N_i=22,428,557,114,832, is exactly what follows from 14 digits per point on a 314e12-digit stream (314e12/14 is about 22.43e12), and cannot arise from 16-digit blocks, which would give 19.625e12 points. The two descriptions cannot both be true. If the actual code used 7-digit coordinates, the points lie on a 10^7 by 10^7 lattice and the expected hit probability is the lattice count fraction, which differs from pi/4 by a deterministic O(10^-7) boundary or discrepancy term; this is comparable to the quoted sigma=0.00000035 and is omitted from Eqs. (14)-(16). If the code used 8-digit coordinates, the quoted N is impossible from the stated dataset. Either way, the reported central estimate and its uncertainty are not pinned down by the manuscript.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes to use the publicly available 314-trillion-digit decimal expansion of pi as the random-number source for a classic Monte Carlo estimate of pi. Digits are blocked into coordinate pairs in the unit square, points are classified inside or outside the quarter unit circle, and the fraction of inside points is multiplied by four to estimate pi. The authors report \\hat\\pi = 3.14159313 \\pm 0.00000035 from approximately 22.4e12 points, with t-test and chi-square p-values of 0.17, and interpret the result as evidence that the digit stream behaves as a statistically valid pseudorandom source at this scale. They also discuss the philosophical question of whether pi can 'generate itself' from its own decimal expansion.","tokens_in":5721,"tokens_out":4614,"duration_ms":47727,"significance":"If the construction were exactly as stated, the paper would provide a clean, large-scale empirical test of the random-like behavior of pi's digits in a nontrivial stochastic computation, using a uniquely large public dataset. The reported aggregate counts and statistical p-values are internally consistent with a 14-digit-per-point binomial calculation, and the estimator formulas in Eqs. (14)-(16) are standard. The main strength is the direct use of the complete record dataset, which makes the test more stringent than earlier digit-frequency analyses. However, the manuscript currently contains a load-bearing internal inconsistency about the number of digits per point, and an unresolved lattice-discrepancy issue, so the experiment as written is not reproducible and the quoted uncertainty is not fully justified.","major_comments":[{"comment":"Equation (7) is arithmetically wrong. From Eq. (6), N_x = sqrt(314e12) = 1.772e7, whose base-10 logarithm is about 7.25, so ceil(log10 N_x) = 8, not 7. If the code really used 7-digit coordinates, the points lie on a 10^7 by 10^7 lattice with 10^14 cells, not on the N_x by N_y grid required by Eq. (5). If the intended grid has 3.14e14 cells, each coordinate requires 8 digits and Eq. (8) would give N = 314e12 / 16 = 19.625e12, not 22.4e12. The derivation of the sample size and the optimal block length therefore needs to be corrected or explicitly restated to match the actual implementation.","section":"Section 2, Eqs. (5)-(8)"},{"comment":"The paper contradicts itself on the block size. Section 3 states that each worker consumes blocks of sixteen decimal digits, with eight digits per coordinate, but the reported sum of counts in Eq. (15), 22,428,557,114,832, equals 314e12 / 14, not 314e12 / 16 = 19.625e12. The subsequent histogram test in the same section also uses 10^7 bins and mean 2 N_i / 10^7, which corresponds to 7-digit coordinates, not 8-digit coordinates. These descriptions cannot all be true. The actual block construction must be stated unambiguously, and the quoted N_i and aggregate counts must be recomputed or reconciled with that construction.","section":"Section 3, Eqs. (10)-(11) and Eq. (15)"},{"comment":"If the actual implementation used 7-digit coordinates, the success probability is not exactly pi/4. On a 10^7 by 10^7 lattice, the expected fraction of points inside the quarter circle is the number of lattice points in the quarter circle divided by 10^14, which differs from pi/4 by a deterministic boundary term of order 10^-7. This is comparable to the quoted sigma = 0.00000035 in Eqs. (14) and (16). The manuscript does not quantify or correct this lattice bias, so the uncertainty and p-values are not centered on the true sampling distribution unless the code used 8-digit blocks, in which case the reported N is impossible. The authors need to either confirm the exact digit-to-coordinate mapping and account for the lattice correction, or provide evidence that the bias is negligible at the stated precision.","section":"Section 3, final paragraph, and Eq. (16)"}],"minor_comments":[{"comment":"The abstract reports pi approx 3.141593, while Eq. (14) gives 3.14159313 +/- 0.00000035; these should be made consistent so that the claimed 'first sequence of decimal digits' is precisely defined.","section":"Abstract and Eq. (14)"},{"comment":"The text contains the typo 'additional data data'; it should read 'additional data'.","section":"Section 3, paragraph 4"},{"comment":"The claim that the 628 p-values are 'uniformly distributed between 0 and 1' is not accompanied by a figure, histogram, or summary statistic. A visual or quantitative support would make this verification check reproducible.","section":"Section 3, final paragraph"},{"comment":"The scaling statement sigma ~ 1/sqrt(N) is correct in order of magnitude, but the precise prefactor for the pi/4 Bernoulli estimator is 4 sqrt(p(1-p)) with p = pi/4, which gives sigma = 3.47e-7; stating the exact relation would improve clarity.","section":"Section 2, Eq. (9)"}],"recommendation":"major_revision","confidential_remarks":"The paper is a computational case study rather than a proof-oriented contribution, so its fit with math.GM depends on editorial judgment about empirical mathematics papers. The central result may be salvageable, but the internal contradiction between the 14-digit and 16-digit descriptions in Sections 2 and 3 is exactly the kind of issue that reviewers cannot resolve without access to the code or a definitive statement from the authors. I would ask the authors to state precisely how many digits per coordinate were used, reconcile the reported counts with that block size, and address the lattice-discrepancy term if 7-digit coordinates were used. The philosophical discussion in Section 4 is not load-bearing for the numerical claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe paper is a clean empirical exercise: use the digits of pi as the random source for the standard quarter-circle Monte Carlo estimator of pi, applied to the new 314-trillion-digit dataset. What is genuinely new is the scale and the 628-chunk consistency analysis – no one has run this on the full record stream. Credit where due: the estimator is standard, the authors are clear that the digits are deterministic and that independence cannot hold, and the philosophical section does not oversell. The reported result, pi-hat = 3.14159313 ± 0.00000035, matches what N^{-1/2} precision would predict and is a legitimate empirical test of the digit stream's random-like behavior.\n\nThe soft spot is not the acknowledged non-independence; it is the internal contradiction in the sample construction. Section 2 derives 14 digits per point (7 per coordinate) and N = 22.4e12. But Eq. (7) is arithmetically wrong: sqrt(314e12) is about 1.772e7, whose log10 is 7.25, so the ceiling is 8, not 7. Section 3 states that each point uses 16 digits (8 per coordinate). The reported total N = 22,428,557,114,832, however, is exactly 314e12/14, which cannot arise from 16-digit blocks (that would give 19.6e12). The two descriptions are mutually incompatible. If the code used 7-digit coordinates, the points lie on a 10^7 by 10^7 lattice and the expected hit probability is the lattice fraction, not pi/4, with a deterministic O(10^-7) boundary correction comparable to the quoted sigma; if it used 8-digit coordinates, the quoted N is impossible. Either way, the central estimate and its uncertainty are not pinned down by the manuscript. This is a reproducibility issue, not a cosmetic typo, because a reader cannot tell which procedure generated the numbers.\n\nThe underlying idea probably works, and the discrepancy may be fixable, but as submitted the paper is not self-consistent. I would send it to peer review because the scale is new and the flaw is concrete and correctable, but I would not accept until the block-length discrepancy is resolved and the code or data are made available. The citation pattern is unremarkable; the only references are standard.\n\nThis paper is for readers interested in pi digit statistics and Monte Carlo methods, not for those seeking a theoretical advance. Worth a look in reading group if someone wants to debug the inconsistency, but I wouldn't cite it in its current form.","headline":"A cute scale-up of a known Monte Carlo curiosity, but the manuscript's internal 14-vs-16-digit inconsistency makes the headline estimate unreproducible as written.","tokens_in":6223,"tokens_out":4669,"would_cite":false,"duration_ms":43081,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["11K16","65C05","11K45"],"pacs":[],"model":"deepseek-v4-flash","headline":"Using pi's own digits as the random-number source, a Monte Carlo simulation recovers pi to seven decimal places.","keywords":["pi digits","Monte Carlo estimation","normality","pseudorandom numbers","statistical randomness","decimal expansion","314 trillion digits"],"falsifier":"Shift the segmentation of the digit stream by one digit and recompute the same Monte Carlo estimator: under the paper's uniformity assumption, estimates from the original and shifted segmentations should agree within roughly $2\\sigma$. A systematic gap many times $\\sigma$ would show that the apparent agreement is specific to the chosen block boundaries rather than a property of the digit stream itself.","tokens_in":5159,"feed_emoji":"🥧","tokens_out":9733,"duration_ms":95254,"temperature":0.7,"pith_summary":"Can pi's own decimal expansion supply the randomness needed to compute pi? Using the record 314-trillion-digit dataset, the authors map consecutive digit blocks into coordinates inside the unit square and run the simplest Monte Carlo estimator, counting how many points fall inside a quarter circle. The result, $\\hat\\pi = 3.14159313 \\pm 0.00000035$, reproduces the first seven decimal digits of $\\pi$, with a measured deviation of about $1.4\\sigma$ and a $p$-value of $0.17$. The authors read this as empirical evidence that the digit stream behaves as a statistically uniform random source at the available scale, while stating clearly that this proves neither normality nor independence.","feed_headline":"Pi's own digits reproduce pi to seven decimals","feed_subtitle":"A 314-trillion-digit Monte Carlo run finds no detectable bias in pi's decimal expansion.","key_machinery":"The load-bearing object is the hit-or-miss Monte Carlo estimator for $\\pi$: sample points uniformly in the unit square, keep those with $x^2+y^2\\le1$, and estimate $\\pi=4N_{\\rm in}/N$. The paper's twist is that the uniform samples are generated by decoding consecutive digits of $\\pi$ themselves, with the block length chosen so that the expected occupancy is about one point per cell of a square grid. The quoted error bar is the binomial standard deviation $\\sigma=4\\sqrt{p(1-p)/N}$ with $p=\\pi/4$, giving $\\sigma\\approx 3.5\\times10^{-7}$, and the goodness-of-fit tests check that the per-file estimates scatter by the expected amount.","core_discovery":"The central claim is that the decimal expansion of pi can successfully act as its own source of pseudorandom numbers in a large-scale Monte Carlo simulation. The digit stream is split into blocks; each block is read as the fractional coordinates $(x,y)$ of a point in the unit square, and the point counts as a hit when $x^2+y^2\\le 1$. From roughly $2.24\\times10^{13}$ points the hit fraction gives $4N_{\\rm in}/N = 3.14159313 \\pm 0.00000035$, matching the exact value of $\\pi$ to seven decimal places. The paper's statistical checks, a Student $t$-test on the 628 per-file estimates and a Pearson $\\chi^2$ test on digit-bin histograms, show no evidence of bias, and the authors emphasize that this is a practical, finite-scale demonstration, not a proof of normality or digit independence.","pith_inferences":["A stricter version of the paper's test would split the digit stream: estimate the hit fraction from the first 90% of the digits and use it to predict the last 10%, removing the circularity of measuring randomness and target on the same data.","Running the identical estimator on the first 314 trillion digits of a proven-normal constant or a high-quality pseudorandom generator would calibrate how unusual a $p$-value of 0.17 really is.","Because only non-overlapping blocks are tested, correlations at lags shorter than one block remain invisible; an autocorrelation scan of the inside-circle indicator over lags 1 to 1000 block lengths would probe exactly that gap."],"forward_implications":["No detectable statistical bias appears in pi's digits up to 314 trillion places, so frequency-based normality tests are corroborated by a practical stochastic computation at this scale.","The estimator already sits at the $\\sigma\\sim10^{-7}$ precision limit set by the dataset size; larger future digit records should extend the recovered decimals of pi as $N^{-1/2}$.","The same digit-to-coordinate mapping provides a generic testbed for the practical randomness of any long decimal expansion, not only pi.","Deterministic digit streams such as pi's can serve as reproducible seeds for physics Monte Carlo simulations, as the paper suggests for spigot-generated constants."],"supporting_citations":[{"why":"Provides the record 314-trillion-digit decimal expansion of pi that is the entire dataset for the Monte Carlo analysis.","marker":"[8]"},{"why":"Documents the public release and storage of the digit files that allowed the authors to download and process the dataset.","marker":"[9]"},{"why":"Earlier statistical analysis of the first 22.4 trillion digits that this work extends to the larger record dataset.","marker":"[10]"},{"why":"Introduces the Monte Carlo method whose hit-or-miss estimator the paper uses to turn random points into a pi estimate.","marker":"[11]"},{"why":"Textbook reference for the Monte Carlo framework underlying the error estimate and sampling statistics.","marker":"[12]"},{"why":"Connects random generators and normal numbers, the theoretical context for treating pi's digits as a random source.","marker":"[6]"}],"fun_headline_variants":["Pi's digits simulate pi to 7 decimals in 314T-digit test","Monte Carlo with pi's own digits recovers pi to 7 places","314 trillion pi digits as randomness yield pi to 7 decimals","Self-sampling pi: digits as Monte Carlo seed hit 7 decimals","Biggest pi dataset shows digits compute pi themselves"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The quoted uncertainty and p-values treat every digit-block-derived point as an independent, uniform random draw. Since the digit stream is deterministic, independence can only hold approximately; if strong correlations persist across blocks, the effective sample size is smaller than $N$ and the error bars are underestimated.","fun_headline_variants_meta":{"raw":{"variants":["Pi's digits simulate pi to 7 decimals in 314T-digit test","Monte Carlo with pi's own digits recovers pi to 7 places","314 trillion pi digits as randomness yield pi to 7 decimals","Self-sampling pi: digits as Monte Carlo seed hit 7 decimals","Biggest pi dataset shows digits compute pi themselves"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001095,"raw_usage":{"total_tokens":4539,"prompt_tokens":879,"completion_tokens":3660,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":495,"completion_tokens_details":{"reasoning_tokens":3569}},"tokens_in":495,"tokens_out":3660,"duration_ms":22732,"temperature":1.0,"reasoning_tokens":3569,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T04:25:08.774750+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Shift the segmentation of the digit stream by one digit and recompute the same Monte Carlo estimator: under the paper's uniformity assumption, estimates from the original and shifted segmentations should agree within roughly $2\\sigma$. A systematic gap many times $\\sigma$ would show that the apparent agreement is specific to the chosen block boundaries rather than a property of the digit stream itself.","supporting_citations":[{"cited_title":"314 Trillion Digits ofπ,","cited_arxiv_id":null,"evidence_quote":"Provides the record 314-trillion-digit decimal expansion of pi that is the entire dataset for the Monte Carlo analysis."},{"cited_title":"314 Trillion Digits of Pi Stored in the Backblaze Cloud,","cited_arxiv_id":null,"evidence_quote":"Documents the public release and storage of the digit files that allowed the authors to download and process the dataset."},{"cited_title":"Digit Statistics of the First 22.4 Trillion Decimal Digits of Pi","cited_arxiv_id":"1612.00489","evidence_quote":"Earlier statistical analysis of the first 22.4 trillion digits that this work extends to the larger record dataset."},{"cited_title":"The Monte Carlo Method,","cited_arxiv_id":null,"evidence_quote":"Introduces the Monte Carlo method whose hit-or-miss estimator the paper uses to turn random points into a pi estimate."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Textbook reference for the Monte Carlo framework underlying the error estimate and sampling statistics."},{"cited_title":"Random Generators and Normal Numbers,","cited_arxiv_id":null,"evidence_quote":"Connects random generators and normal numbers, the theoretical context for treating pi's digits as a random source."}],"review_version":1}