Draco Malfoy and the forbidden love

The "Trouble"

Dream Investigation ResultsOfficial Report by the Minecraft Speedrunning TeamPublished: December 11, 2020Updated: December 15, 20201ContentsI Introduction 31 Mechanics 32 Motivation 33 Objectivity 4II Data 54 Piglin Bartering 55 Blaze Rod Drops 6III Analysis 66 Methodology 67 The Binomial Distribution 87.1 The Intuition . . . . . . . . . . . . . . . . . . . . . . . . . . 87.2 Generalizing the Binomial Distribution . . . . . . . . . . . . 87.3 The Cumulative Distribution Function (CDF) . . . . . . . . 98 Addressing Bias 108.1 Accounting for Optional Stopping . . . . . . . . . . . . . . 108.2 Sampling Bias in Stream Selection . . . . . . . . . . . . . . 118.3 Sampling Bias in Runner Selection . . . . . . . . . . . . . . 128.4 P-hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Code Analysis 149.1 Confirming the Probabilities . . . . . . . . . . . . . . . . . . 149.2 Setting RNG Seeds . . . . . . . . . . . . . . . . . . . . . . 159.3 Linear Congruential Generators . . . . . . . . . . . . . . . . 169.4 Periodicity . . . . . . . . . . . . . . . . . . . . . . . . . . . 179.5 Bartering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189.6 Blaze Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 19IV Results 2010 Computation 2010.1 Naive Estimate . . . . . . . . . . . . . . . . . . . . . . . . 2010.2 Full Computation . . . . . . . . . . . . . . . . . . . . . . . 2110.2.1 Pearls . . . . . . . . . . . . . . . . . . . . . . . . . 2110.2.2 Blaze Rods . . . . . . . . . . . . . . . . . . . . . . 2110.2.3 Combined Number . . . . . . . . . . . . . . . . . . 2211 Conclusion 23A Raw Data 24B Stopping Rule Computation Algorithm 25C Probability Computations 272Part IIntroduction1 MechanicsNote: This section exists to explain Minecraft 1.16 Random Seed Glitchless speedruns to theunfamiliar reader. Motivation begins a discussion of why this investigation took place, and is asuitable starting point for those already familiar with Minecraft speedruns.Speedrunning is a hobby in which people compete to complete a video game as quickly as possible.This paper concerns speedruns of Minecraft: Java Edition, and, in particular, speedruns of thecategory known as "Any% Random Seed Glitchless" (RSG) performed on version 1.16. A briefsummary of the relevant mechanics and speedrun strategies follows for the unfamiliar reader.The final boss of Minecraft is located in an alternate dimension known as The End, which canbe accessed using End Portals. An end portal consists of twelve End Portal Frame blocks,a random number (usually 10-12) of which must be filled with an Eye of Ender in order toactivate the portal. Thus, the runner is required to have up to twelve eyes of ender when theyarrive at the portal to be able to enter The End and complete the game.In 1.16, the only way to obtain an eye of ender is by crafting it, which requires one EnderPearl and one Blaze Powder. Ender pearls can be obtained in several ways, but the fastest isto use a mechanic known as Bartering. In a barter, the player exchanges a Gold Ingot with aPiglin (a humanoid creature in the Nether dimension) for a randomly chosen item or groupof items. For each barter, there is about a 5% chance (in 1.16.1) the piglin will give the playerender pearls.Blaze powder is crafted out of Blaze Rods, which are dropped by Blazes—a hostile mob.Upon being killed, each blaze has a 50% chance of dropping one blaze rod.The main focus during the beginning of a 1.16 RSG speedrun is to obtain (hopefully) 12 eyesof ender as quickly as possible, by bartering with piglins and killing blazes. These two parts ofthe speedrun route are the primary concern of this paper.2 MotivationMembers of the Minecraft speedrunning communityareviewed six consecutive livestreams of 1.16RSG speedrun attempts by Dreambfrom early October 2020. The data collected show that 42 ofthe 262 piglin barters performed throughout these streams yielded ender pearls, and 211 of the305 killed blazes dropped blaze rods. These results are exceptional, as the expected proportionof ender pearl barters and blaze rod drops is much, much lower.An initially compelling counterclaim is that top-level RSG runners must get reasonably goodluck in order to get a new personal best time in the first place, so, while it is surprising to seesuch an unlikely event, it is perhaps not unexpected. However, upon further research, Dream'sobserved drop rates are substantially greater than those of other top-level RSG runners—including,Illumina, Benex, Sizzler, and Vadikus. If nothing else, the drop rates from Dream's streams areso exceptional that they ought to be analyzed for the sake of it, regardless of whether or not anyone individual believes they happened legitimately.aThe data were originally reported by MinecrAvenger and danhem9.bhttps://www.twitch.tv/dreamwastaken33 ObjectivityThe reader should note that the authors of this document are solely motivated by the presenceof exceptional empirical data, and that any runner—regardless of popularity, following, or skill—observed experiencing such unlikely events would be held to the same level of scrutiny. Thereader should also note that the data presented are extensively corrected for the existence of anybias. It would lack rigor and integrity for the conclusions made in this report to substantiate themoderation team's decision if they were merely based on a surface-level analysis of the data.Indeed, these corrections inherently skew the analysis in Dream's favor. We aim to calculate notthe exact probability that this streak of luck occurred if Dream is innocent, but an upper boundon the probability; that is, we will arrive at a value which we are certain is greater than the trueprobability.The goal of this document is to present the unbiased, rigorous statistical analysis of the data,as well as an analysis of the Minecraft source code, to conclusively determine whether or notsuch an event could be observed legitimately.4Part IIDataThe raw data (and its sources) from which the following graphs were derived can be found inAppendix A.4 Piglin BarteringFigure 1: Dream's pearl barters, charted alongside various comparisons. The 99.9th percentileline represents one-in-a-thousand luck (calculated using a normal approximation), which is alreadyquite unlikely—if not necessarily proof of anything.55 Blaze Rod DropsFigure 2: The same for blaze rod drops.Part IIIAnalysis6 MethodologyWhat follows is a thorough description of every aspect of our investigation in an accessible manner.We will begin with an introduction to the binomial distribution, and follow with adjustments toaccount for sampling bias and other biases lowering the accuracy of the binomial distribution.Finally, we will analyze Minecraft's code to justify the assumptions made in our statisticalmodel. To strengthen our analysis to the skeptical reader, we now preemptively address expectedcriticisms and questions.Why are you not analyzing all of Dream's runs? Doesn't that introduce sampling bias?Yes. There is clearly sampling bias in the data set, but its presence does not invalidate ouranalysis. Sampling bias is a common problem in real-world statistical analysis, so if it wereimpossible to account for, then every analysis of empirical data would be biased and useless.Consider flipping a coin 100 times and getting heads 50 of those times (a mostly unremarkableresult). Within those 100 coin flips, however, imagine that 20 of the 50 heads occurred back-toback somewhere within the population. Despite the proportion overall being uninteresting, we6still would not expect 20 consecutive heads anywhere. Obviously, choosing to investigate the20 heads introduces sampling bias—since we chose to look at those 20 flips because they werelucky, we took a biased sample.However, we can instead discuss the probability that 20 or more back-to-back heads occur atany point in the 100 flips. We can use that value to place an upper bound on the probabilitythat the sample we chose could possibly have been found with a fair coin, regardless of howbiased a method was used to choose the sample.It's also worth noting that the choice to only consider Dream's most recent streak of 1.16streams is the least arbitrary distinction we could have made. The metaphor of "cherry-picking"usually brings to mind choosing from a wide number of options, but there were at most a smallhandful of options meaningfully equivalent to analyzing every stream since Dream's return topublic streaming. Note the importance of the restriction that we must analyze the entire sixstreams as a whole; true cherry-picking would specifically select individual barters to support adesired conclusion.How do we know this investigation isn't biased?Concerns about the impartiality of the authors of this paper have been raised in discussionabout the investigation. We do not think this is a significant issue; we have made an effort to beas fair to Dream and thorough as possible in our investigation. Regardless, it is a concern worthaddressing.This paper has been written to be as accessible as possible to an audience without in-depthknowledge of statistics or programming. This is primarily so that you do not have to take ourword for its accuracy. By reading the analysis, you should be able to understand at least on abasic level why the statistical corrections we made account for all the relevant biases.Additionally, as noted in Section 3: Objectivity, we aimed not to calculate the preciseprobability of Dream experiencing these events, but an upper bound on the probability. Thismakes it much more difficult for bias to have any effect; if we correct for the largest amount ofbias in the data that there could possibly be, there is little risk our analysis will be skewed due toour bias causing us to underestimate how much we ought to correct.We believe that, to the extent any bias exists, these measures should be more than sufficientto account for it. Additionally, note that we are not the only people capable of analyzing theseevents—if any unbiased third party points out a flaw in our statistical analysis or notes a glitchthat could potentially cause these events, they would, of course, be taken seriously.What if Dream's luck was balanced out by getting bad luck off stream?This argument is sort of similar to the gambler's fallacy. Essentially, what happened to Dreamat any time outside of the streams in question is entirely irrelevant to the calculations we aredoing. Getting bad luck at one point in time does not make good luck at a different point intime more likely.We do care about how many times he has streamed, since those are additional opportunitiesfor Dream to have been noticed getting extremely lucky, and if he had gotten similarly luckyduring one of those streams an investigation still would have occurred. However, what luckDream actually got in any other instance is irrelevant to this analysis, as it has absolutely nobearing on how likely the luck was in this instance.77 The Binomial DistributionNote: If the reader is equipped with a basic understanding of statistical analysis and the binomialdistribution, they may skip to Section 8: Addressing Bias. Note that the explanations presenthere are sufficient for the probability calculations performed throughout the rest of the paper,but are not exhaustive. Supplemental reading is provided via footnotes where relevant.7.1 The IntuitionInformally, if the outcome of a particular event can be described as "it either happens or itdoesn't", then it can be modeled with the binomial distributionc. For example, imagine wewanted to compute the odds of flipping a fair coind 10 times and having it land on heads exactly6 of those times. Since a coin either lands on heads or it doesn't, we can use the formula for thebinomial distributioneto determine the chance of this occurring.Since we flip the coin 10 times, we say 푛 = 10, and since we want exactly 6 of those flips tobe heads, 푘 = 6. The chance of a (fair) coin landing on heads is 50%, so 푝 = 0.5. If we plugthese values into the binomial distribution formula, we getP (6; 0.5, 10) =1060.56(1 − 0.5)10−6 ≈ 0.205 (1)To interpret this value, if we flip a coin 10 times, we can expect to get exactly 6 heads about 20.5%of the time. To understand why this formula yields the probability of a binomial distribution,and how to generalize it, we break down each term.7.2 Generalizing the Binomial DistributionGenerically, the probability of exactly 푘 successes with probability 푝 occurring in 푛 trials (in ourearlier example, 푘 = 6 heads with probability 푝 = 0.5 occurring in 푛 = 10 flips) is given byP (푘; 푝, 푛) =푛푘푝푘(1 − 푝)푛−푘(2)We can deconstruct this formula term-by-term to understand why this represents the probability.Basically, this formula figures out how many distinct orderings of 푘 successes and 푛 − 푘 failuresmeet the criteria, and then sums the probability of each orderingf.The notation푛푘, read as "푛 choose 푘", represents the binomial coefficientg, which is thenumber of ways we can observe 푘 successes in 푛 trials—the number of ways, with 푛 options fortrials to be successes, you could "choose" 푘 of them. For example, there are two ways to observe푘 = 1 heads in 푛 = 2 coin flips. The head could occur on the first flip, or it could occur on thesecond flip. Therefore,21is equivalent to 2. With similar reasoning,42is equivalent to 6; therecThe binomial distribution also requires the assumption that we are observing discrete independent randomvariables. Since piglin bartering and blaze drops are discrete independent random variables (see Section 9: CodeAnalysis), we can safely make this assumption. There are other considerations about stopping rules which will beaddressed in Section 8: Addressing Bias.dA "fair coin" is defined as one whose probability of landing on heads is exactly the same as its probabilityof landing on tails. We are also not considering the probability that the coin lands on its side, which is entirelynegligible for this introductory-level explanation to the binomial distribution.ehttps://en.wikipedia.org/wiki/Binomial_distributionfFor an explanation of why this works, see https://www.youtube.com/watch?v=QE2uR6Z-NcU.ghttps://en.wikipedia.org/wiki/Binomial_coefficientare 6 unique ways to distribute 2 successes (heads) across 4 trials (coin flips). (These are 1&2,1&3, 1&4, 2&3, 2&4, and 3&4.)As the first term represents the number of distinct orderings, the next two terms representthe probability of any one order. To find this probability, we simply take the product of theprobabilities of the events necessary to produce a given ordering; that is, the product of theprobability of observing 푘 successes and 푛 − 푘 failures.Since 푝 is the probability of a given trial being successful, and there are 푘 successful trials,we can account for the successful trials with the term 푝푘(푝 multiplied by itself 푘 times)h.Similarly, we account for the failures by raising the probability of a failure to the power of thenumber of failures. As the only two possibilities in a given trial are success and failure, and theprobabilities must sum to 1, the probability of a failure is (1 − 푝). It follows that, since each trialthat is not a success must be a failure, the number of failures is (푛 − 푘). Thus, the final term is(1 − 푝)푛−푘.Multiplying all three terms together yields the probability of a binomial distribution with agiven 푘, 푝, and 푛.7.3 The Cumulative Distribution Function (CDF)It would be helpful to have a way to compute the probability of observing 푘 or more successes.Intuitively, we can expect the probability of observing exactly 푘 successes in 푛 trials to be smallerthan the probability we observe 푘 or more successes in the same 푛 trials.Referring back to the coin-flipping example, if we wanted to compute the probability ofobserving 6 or more heads within 10 trials, then we can simply add together the probabilities ofobserving exactly 6 heads, exactly 7 heads, (...), exactly 10 heads, given byÕ10푘=610푘0.5푘(1 − 0.5)10−푘 ≈ 0.377 (3)Indeed, this agrees with our intuition; it makes sense that it is more likely to get 6, 7, 8, 9, or 10heads in 10 flips, than it is to get exactly 6 heads in 10 flips.The chance of receiving 푘 or more successes is often referred to as a 푝-value. More specifically,푝-values are the chance of observing 푘 or more successes given the null hypothesis. While thatnuance is irrelevant if you already know for a fact the coin is fair, it is important to keep in mindin this scenario—our entire goal is, essentially, to analyze whether or not Dream is using a biasedcoin.Armed with a basic understanding of the binomial distribution, we will now discuss how thisinitial calculation must be corrected in order to be applied to Dream's runs.hFor an explanation of why this works, see https://www.youtube.com/watch?v=xSc4oLA9e8o.98 Addressing BiasThere are a few assumptions of the binomial distribution that are violated in this sample, someof which were noted in the document Dream published on October 27. This section accounts forthese violated assumptions, and proves computations that account for these biases.Note that some of these biases only apply to pearls, as blaze rod drops were examined in thesame streams as pearls due to the pearl odds, which are independent of the blaze rod drop rate.This eliminates the sampling bias from the decision to investigate the pearl odds based on thefact that they are particularly lucky.8.1 Accounting for Optional StoppingThe initial calculation for the 푝-value assumed that barters and rod drops within sequencesof streams are binomially distributed, which is not precisely true (although likely a very goodapproximation). For the data to be binomially distributed, the stopping rule—the rule by whichyou decide when to stop collecting data—must be independent of the contents of the data.For instance, Dream may be more likely to stop streaming for the day after getting aparticularly good run, which is more likely to happen on a run with good barters and blaze rods.Indeed, Dream did stop speedrunning 1.16 RSG after achieving a new personal best time. Thiswill result in the data being at least slightly biased towards showing better luck for Dream, andthus the data is not perfectly binomial.To account for the stopping rule, we will correct for the worst possible (most biased) stoppingrule. Imagine that this investigation was being conducted by Shifty Sam, a malicious investigatorwho is trying as hard as possible to report misleading data that will frame Dream. Since a lower푝-value is more damning, Shifty Sam computes the cumulative 푝-value after every barter or afterevery blaze kill, and stops collecting datai once he deems the 푝-value "low enough" to makethe strongest case against Dream. This is the worst possible stopping rule, since Shifty Sam willstop collecting data once the 푝-value is arbitrarily low enough (as deemed by him to be mostconvincing). It should be abundantly clear that this stopping rule is far worse than whateverstopping rule Dream actually followed during his runs.It may not be immediately obvious how we can calculate a 푝-value under this stopping rule.We cannot look directly at the number of success in the data, as that is always going to beexceptional to this degree. What we can consider, however, is how quickly Shifty Sam reached his푝-value cutoff. Intuitively, we might expect Shifty Sam to spend a long time waiting for the datato reach his 푝-value cutoff. To put it another way, it would certainly be surprising, regardlessof how shifty Sam is, to hear that Dream got 30 successful barters in a row as soon as ShiftySam started looking at the data. Knowing that Shifty Sam only decided to show you this databecause it supported his argument would not really make that any less surprising (concerns aboutsampling bias aside—those will be addressed later).Since the data reaching a 푝-value this extreme so soon is somewhat surprising even if weknow the data comes from Shifty Sam, we will look at the probability that Shifty Sam stopscollecting data at least as soon as Dream stopped. In other words, if 푛 is the number of trialsin Dream's data, our corrected 푝-value will be the probability that a series of trials will, at anypoint on or prior to the 푛th trial, have a binomial CDF 푝-value at least as small as the one forDream's data.iSince Shifty Sam here is supposed to represent whatever caused Dream to choose to stop running 1.16 RSG,suppose Shifty Sam is, say, Dream's manager, and can tell Dream when to stop or continue streaming.10Although that value could be computed through brute force, that approach would involveevaluating the probability and 푝-values for well over 2305 different sequences—which is obviouslycomputationally intractable. As such, we used a method that allowed for dealing with multiplesequences at once. The exact algorithm is somewhat involved, so a description has been includedin Appendix B for interested readers.8.2 Sampling Bias in Stream SelectionAs mentioned previously, we chose to analyze Dream's runs from the point that he returned tostreaming rather than all of his runs due to a belief that, if he cheated, it was likely from the pointof his return to streaming rather than from his first run. Although we cannot be entirely certain,it is also likely that MinecrAvenger decided to investigate Dream's streams due to noticing thatthey were unusually lucky. This, of course, means that the streams investigated are not actuallya true random sample. Even if MinecrAvenger somehow chose streams to investigate at completerandom, we are choosing to investigate these streams due to the fact that they are lucky. Thus,we cannot treat this as a true random sample.To account for the maximum possible amount of sampling bias, imagine that Shifty Saminspected every speedrun stream done by Dream and reported whatever sequence of consecutivestreams was the most suspicious.j This would produce the strongest possible bias—or at least abias much stronger than there actually is—from the choice of these particular Dream streams.Recall the example of investigating the 20 back-to-back heads within 100 coin flips fromearlier. Much like you could calculate the probability of 20 consecutive heads occurring at anypoint in the 100 flips, we can calculate the probability that Dream experienced bartering luckthis unlikely in any series of consecutive streams. This would account for the bias from ShiftySam, and thus more than account for the actual bias under consideration.To calculate the chance that at least one sequence of streams is this lucky, we first calculatethe chance that no sequence is. Assuming independence, we can do this by taking the chancethat a given sequence isn't sufficiently lucky (1 − 푝) to the power of the number of sequences, 푚.If an event occurs more than zero times, then it must have occurred at least once, so we can thensubtract (1 − 푝)푚 from one to get the chance that it occurs at least once, giving 1 − (1 − 푝)푚.The number of consecutive sequences consisting of at least two streams from a set of 푛streams is푛2, as you choose two different streams to be the first and last. Adding in the 푛sequences consisting of only one stream, which were not included because the first and laststream are the same stream, you get푛2+ 푛 which is equal to 푛(푛+1)2.We can now get an upper bound 푝푛 on the 푝-value across 푛 streams, using the 푝-valuederived from our sample.푝푛 ≤ 1 − (1 − 푝)푛(푛+1)2 (4)At this point, let us go back and analyze an earlier assumption we made: that the 푝-valuesbetween sequences of streams are independent of one another. This assumption is false—however,it is not false in a way that could cause 푝푛 to be greater than this upper bound.Consider the exact way in which the sequences of streams are dependent on one another.Since they all contain streams from the same set (those from Dream), some of the data in eachsequence will be identical to that in other sequences. This lowers the chance that Shifty SamjWe can safely assume the streams reported would be consecutive—it would be extremely obvious that thestreams were cherry-picked if Shifty Sam reported the luck in, say, Dream's first, seventh, and tenth streams.Non-consecutive streams could be reported credibly in unusual circumstances, but that possibility is essentiallynegligible.could find misleading data, as he has less data to look through for unlikely events. In technicalterms, we can say the 푝-values of the sequences of streams are positively dependent upon oneanother—they are positively correlated with each other. For this bound to fail, the sequenceswould need to be negatively dependent.8.3 Sampling Bias in Runner SelectionIn addition to these particular streams of Dream's being analyzed due to their high proportion ofpearl barters, Dream was initially analyzed out of all runners due to his experiencing unusuallygood luck. Much like we calculated the chance of observing data as unlikely as the data inquestion in any sequence of streams, we will analyze the probability of observing data this unlikelyfrom any runner in the Minecraft speedrunning community, using the same formula for thechance of something occurring at least once in a series of trials that we used earlier.This results in the following correction, where 푝푛 is the 푝-value corrected for a communitywith 푛 runners, and 푝 is the 푝-value for Dream in particular:푝푛 ≤ 1 − (1 − 푝)푛(5)Note that, as we are discussing the 푝-value for data this unlikely occurring to a runner withintheir entire speedrunning career, the size of their career is not relevant. Although a runner maybe more likely to experience six exceptionally lucky streams if they stream more often, we alreadyaccount for the amount they stream when calculating 푝—in other words, if someone streamsmore than Dream, they would need a luckier sequence of streams to have an equally low 푝.8.4 P-hackingPerhaps Shifty Sam examined multiple types of random events and only picked the most significantones. For instance, there could have been analyses of flint drops or iron golem drops, and onlypearls and rods were reported due to those being the most significant—indeed, some other barteritems, as well as eye of ender breaking rates, actually were recorded.To correct for this, we take the probability of finding each result at least once among anupper bound ℎ on the different types of events that could have been analyzed. Unfortunately, thecorrection used for selection across individuals and streams will not work here. That correctionrequires either independent or positively dependent probabilities; however, there are negativelydependent probabilities involved here. For instance, the more pearl barters you receive, the lessopportunities there are to receive an obsidian barter: your numbers of pearl and obsidian bartersare negatively correlated.We can still correct for this, but it will require a much looser upper bound than the oneswe have used previously. Remember that the probability of any one of a number of mutuallyexclusive events occurring is the sum of their probabilities—for example, the chance of rollingeither a two or a five on a six-sided die is 16+16=26.However, this is not the case for non-mutually exclusive events. Consider the chance of rollingeither a number less than three or an even number. The chance of rolling a number less thanthree (1 or 2) is 26and the chance of rolling an even number (2, 4, or 6) is 36. Adding thesetogether would produce 56. But this counts rolling a two twice, producing a number higher thanthe true probability of 46.This double-counting problem is the reason why adding together fails for probabilities thatare not mutually exclusive, so it is not a problem that our probabilities are not mutually exclusive:12the sum of the probabilities will still work as an upper bound. Thus, we have the followingk,where 푝ℎ is the 푝-value corrected for ℎ comparisons, and 푝 is the initial 푝-value:푝ℎ ≤ 푝ℎ (6)We will choose values for these formulas and compute the final results in Part IV. However, toensure these computations are not invalid due to unusual behavior of Minecraft's random numbergeneration, we will first analyze Minecraft's code.kThis is commonly known as the Bonferroni correction.139 Code AnalysisWhen discussing probabilities this low, concerns about edge-case behavior in Minecraft's randomnumber generator (RNG) are relevant. We have been working under the assumption that theresults of piglin bartering and blaze drops are independent random variables, as one would naivelyexpect if Minecraft's RNG were truly random. This would mean that the variables cannot affectone another; that is, past piglin barters and blaze drops tell you precisely nothing about futureones. However, it may seem possible that, in some edge cases, piglin barters or blaze drops failindependence in ways which increase the probability of observing Dream's data. Here, we willanalyze how likely that is by inspecting Minecraft's code.Before beginning the analysis, it is worth noting that if Minecraft's RNG were to fail in sucha way that piglin barters and blaze drops could not be said to be approximately independent, itwould still be astonishingly unlikely for them to fail in exactly the way required to produce theobserved data. The failure(s) would need to (1) occur repeatedly over the course of six separateplay sessions for Dream, (2) only occur to Dream out of all runners, (3) affect both bartering andblaze drops, and (4) specifically bias the results towards piglins bartering ender pearls and blazesdropping blaze rods, rather than towards some other barter item or blazes not dropping rods.Although this may still be more likely than the data occurring without a flaw in Minecraft's RNG,even before analyzing the code it appears a priori extremely unlikely.9.1 Confirming the ProbabilitiesThough the probabilities we have been using thus far for piglin and blaze drop rates in Minecraft1.16.1 are publicly available information, it is important to identify exactly where these probabilitiescome from. The piglin bartering proportions are determined by the piglin_bartering.jsonfile found in the 1.16.1 jar filel. As expected, exactly once each barter, the game selects an itemfrom the following weighted table:Item WeightBook 5Iron Boots 8Potion 10Splash Potion 10Iron Nugget 10Nether Quartz 20Glowstone Dust 20Magma Cream 20Item WeightEnder Pearl 20String 20Fire Charge 40Gravel 40Leather 40Nether Brick 40Obsidian 40Crying Obsidian 40Soul Sand 40Table 1: The simplified contents of piglin_bartering.json. Here an item of weight 푛 is 푛times more likely than an item of weight one. Additional information regarding enchantments,stack sizes, and potion effects not shown.Since the weights sum to 423, and ender pearls have a weight of 20, the probability of anender pearl barter is indeed 20423 as expected (in 1.16.1, the version Dream used).lTo read these files on Windows, simply rename 1.16.1.jar to 1.16.1.zip and navigate todata\minecraft\loot_tables.14Blaze drops are specified by a file called blaze.json, an excerpt of which is included below:1 " function ": " minecraft : set_count ",2 " count ": {3 "min": 0.0 ,4 "max": 1.0 ,5 " type ": " minecraft : uniform "6 }One can see that, when the player's weapon does not have a looting enchantment, blazesselect between dropping either 0 or 1 rods using a uniform distribution. Thus, a rod drop occurswith probability 0.5 as expected.9.2 Setting RNG SeedsFailures of one of Minecraft's RNGs to behave randomly are not unheard of—the most famousexamples of these are the RNG manipulation exploits found in versions prior to 1.13. These allwork on the same principle: some part of Minecraft's code resets an RNG being used by otherparts of the code, causing predictable behavior. For example, in 1.12, loading a chunk runs somewoodland mansion code which resets an RNG also used for mob spawns, allowing them to bemanipulated given controlled conditions. A careful investigation of how and when Minecraft'sRNGs are seeded is needed to ensure there is no bias that could contribute to the observed data.Many of Minecraft's RNGs are initially seeded in a similar manner when they are created,including the RNGs used for bartering and blaze drops. Two components are used: an RNG calledthe "seed uniquifier", and the system time. The seed uniquifier is a linear congruential generator(LCG) which is seeded at 8682522807148012 when Minecraft is started up, and used (as well asupdated) many of the times an RNG is seeded. (We will describe how LCGs work in the nextsections.) The system time is a value provided by the computer's operating system which, onmost modern devices, represents the time in nanoseconds since the computer was turned on.These two components are then combined using an operation referred to as bitwise XORto produce a seed. (Normal) XOR, or exclusive or, is an operation which takes two boolean(TRUE or FALSE) values as inputs and returns TRUE if either but not both of the values are TRUE.Otherwise, it returns FALSE. Another way of looking at XOR is that it returns TRUE if the inputvalues are different from each other and FALSE if they are not. Bitwise XOR takes two inputnumbers, which it represents as a binary string of bits. It then performs a XOR on the bits ofeach input number in a certain place value (interpreting 0 as FALSE and 1 as TRUE) to decide onthat bit for the output number. For example, the bitwise XOR of 1001 (9 in decimal) and 1100(12) is 0101 (5).Combining a value with another by bitwise XOR cannot make it less random, provided the twovalues are independent. Although system time may not be absolutely independent of the seeduniquifier, they are clearly not related enough to cause problems. If the "randomness" decreases,it is not by much. Thus, as long as at least one of the input values is sufficiently random—andboth of them ought to be, for our purposes—this method of setting a seed cannot cause issues.15The code implementing this procedure is shown below.1 private static long seedUniquifier = 8682522807148012 L;23 // seed a new Random object randomly4 public Random () {5 this ( seedUniquifier () ^ System . nanoTime () ) ;6 }78 // set the seed of a Random object to a predetermined value9 public Random ( long seed ) {10 // implementation not relevant here11 }1213 private static long seedUniquifier () {14 seedUniquifier = seedUniquifier * 181783497276652981 L ;15 return seedUniquifier ;16 }The RNG used for bartering is known as the "world RNG" since it is attached to the worldobject in Minecraft's code. The world RNG is also used by random ticksm, mob spawning, andseveral other miscellaneous features. The fact that many different things utilize this RNG couldcause concern that something might be setting the RNG to a specific state at an impropertime—as it is in 1.12.However, a careful search of every instance in which Minecraft sets any RNG's seed or createsany new RNGs reveals that the "world RNG" is never reset in 1.16. This was confirmed bynoting that the world object is final (final objects in Java cannot be replaced, only modified) andexamining every single call to Random::setSeed in the Minecraft codebase. None of these callsaffected the Nether world RNG. Ultimately, this RNG is only ever set upon world load using thebitwise XOR between the seed uniquifier and the system time.The situation for blaze rods is much simpler: every time a blaze is killed it creates an entirelynew RNG for the blaze's single drop, using the same bitwise XOR procedure.As no possibility exists that external factors may be setting the seeds of these generators, weconclude that any failure of randomness must lie with Java Random itself. Having eliminated themost obvious possible cause of a potential glitch that would result in the observed data, we willnow analyze Java's RNG closely to see if there are any more subtle causes of bias.9.3 Linear Congruential GeneratorsIf the reader is unfamiliar with the properties of modular arithmetic, they are encouraged toread https: // en. wikipedia. org/ wiki/ Modular_ arithmetic for at least a conceptualunderstanding.Nearly all of Minecraft's randomization is computed through Java's pseudo-random numbergenerator (PRNG), which utilizes a linear congruential generatorn. As the name suggests, anmTick is a term used to refer to each individual update of the program state, often referred to as frames inother games. In Minecraft, the distinction must be drawn because screen rendering can occur more than once pertick. 20 ticks occur in one second when there is no lag. Random tick is jargon for a certain type of event thatoccurs on, as the name suggests, a random tick.nhttps://en.wikipedia.org/wiki/Linear_congruential_generator16LCG generates a sequence of numbers through a discontinuous linear equation in which eachterm in the sequence is computed by performing operations on the previous term. Each time anew random value is needed, the LCG seed is updated according to the following equation beforebeing used to generate an integer (or other kind of variable).seed푛+1 = 푎 · seed푛 + 푏 mod 푚 (7)In the case of Java's PRNG, the constants 푎, 푏, and 푚 in the above equation are given by푎 = 25214903917, 푏 = 11, and 푚 = 248. Note that these constants are specific to the Java LCGand will vary depending on the implementation.seed푛+1 = 25214903917 · seed푛 + 11 mod 248 (8)LCGs are designed to be fast and memory-efficient rather than cryptographically secure; itis crucial to appropriately use the sequence so as to not cause unwanted bias. Notably, someLCGs have bad periodicity in their lower bits, and some fail what is called the spectral testo.That said, cryptographic security is a much higher standard than required to avoid the kinds ofbias witnessed here. LCGs see frequent use for small Monte Carlo simulations like this one—acommon piece of folklore is that sampling less than the square root of your modulus (in thiscase 224, or about 17 million) gives good samples. They are the go-to random number generatorin a number of compilers and languages, notably C++11, Java, and the GCC compiler for C.Furthermore, as we will soon see, Java Random was specifically designed to mitigate the knownweaknesses of LCGs.9.4 PeriodicityAs the Java Random LCG can only hold 248 different seeds, the sequence of seeds must loop inat most 248 calls to the randomizer (Java's values for 푎 and 푏 were chosen in part to guaranteeit only loops after 248 ≈ 281 trillion calls). This is a problem for large computer simulations, butthis scenario involves a number of RNG calls extremely small compared to the period of 248.However, the choice of 248 as the modulus also means the LCG still demonstrates periodicity inits lower bits.If two numbers are equivalent mod 248, then they must also be equivalent mod 2. This isintuitively clear if you think of the numbers represented in binary: if the last 48 bits of twonumbers are the same, then each bit within those last 48—including the very last one—must bethe same. Thus, we have:seed푛+1 = 25214903917 · seed푛 + 11 mod 2= (25214903917 mod 2) · seed푛 + (11 mod 2) mod 2= seed푛 + 1 mod 2This makes it clear that seeds must alternate between even and odd. In fact, all bits repeatin a similar way with different periods. The first (lowest) bit has a period of two, the secondhas a period of four, the third has a period of eight, and in general the 푛th bit has a period of2푛. The advantages of having a large period suddenly break down when making use of the loweroJava Random and its Seed Uniquifier do not fail the spectral test in any dimensions we care about. Infact, at least the uniquifier was chosen for its good results on the spectral test http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.6553&rep=rep1&type=pdf, suggesting the Java authors were aware of theissue. The spectral test is also irrelevant here - interference from other game mechanics would remove the problem.17bits. Fortunately, as this behavior is well known, Java generates random integers in a way thataccounts for this.nextInt(n)pis the Java method used to generate random integers. When called, it returnsa random non-negative integer less than 푛. The exact process Java uses to account for theaforementioned problem differs depending on whether 푛 is a power of two.• For non-powers of two (such as 푛 = 423, used in bartering), nextInt(n) takes the 31highest bits of the seed, modulo 푛. This implies that calls with even bounds will havesome very clear dependence on lower bits of the seed—the lowest relevant one being the18th, which has a period of 218 ≈ 262 thousand. It does, however, mean the bits withparticularly small periods are entirely irrelevant.• For powers of two, nextInt(n) simply returns the highest log2(푛) bits of the seed. Forexample, nextInt(2), which is used for blaze drops, returns the highest log2(2) = 1 bit(the 48th bit) of the seed, which has a period of 248. This is done because it is muchmore effective than simply applying the method used for non-powers of two—nextInt(2)would then return the 18th bit, and have a period of only 218.9.5 BarteringAs stated earlier, bartering randomization takes place using the world RNG. Thus, periodicitycould conceivably be relevant, depending on precisely how often world RNG is called.The first time concerns due to periodicity would come into play (recall that 푛 = 423 forbartering, which is not a power of two) is when the 18th bit loops after 218 calls to the LCG. Forexample, when 푛 is evenq, the parity (whether a number is even or odd) of a nextInt(n) call isalways the same as the parity of the 18th bit. If it were possible to call the LCG precisely 218times per game tick, one could potentially use that fact to guarantee nextInt(n)'s output toeither always be even or always be odd.This specific attack has seen no use in the RNG manipulation scene so far because of itsstringent requirements, but it is not immediately obvious that 218 LCG calls per tick could notoccur naturally. However, (1) they do not, and (2) it would not matter if they did.1. Empirical evidence shows that the world RNG is called 6000 to 9000 times per tick inthe Netherr. This value may depend on render distance and what is present in the givenchunks, but it should never come close to 218 (262144) calls in a natural setting. Thismeans that even in the best possible case you would only expect a period to complete inaround 30 ticks.2. When 푛 shares no factors with 231, the output of nextInt(n) does not depend on anyone bit of the LCG seed.Even if one could set the bottom bits of the world RNG to only take on certain values, thefact that 423 is odd (invertible mod 2푘) means that the upper bits would foil almost all biasintroduced—at worst some outputs have just one more seed mapping to them than the others.Periodicity cannot explain the observed bias in Dream's pearl trades.phttps://docs.oracle.com/javase/8/docs/api/java/util/Random.html#nextInt-intq푛 also must not be a power of two.rReaders who have been following the investigation may have heard about lava holding some relevance topossible RNG failures. This is because the abundance of lava in the Nether contributes significantly to those 6000to 9000 RNG calls.18Before abandoning our discussion of Bartering and world RNG, it is worth noting that theextra calls to the world random can be viewed as an extra source of randomness. The chaoticnature of when Minecraft needs numbers, especially taken across both runs and streams, onlyadds entropy to the system. To expect all of these factors to conspire to increase the probabilityof anything unrelated is absurd—they are far more likely to decrease the probability of someother RNG failure occurring.9.6 Blaze DropsWhen blazes die, the generic method for all mobs that drop items, LivingEntity.dropLoot(),is called. However, the Random object used to determine the number of dropped items is notseeded and is instead left as null (meaning it has no value whatsoever—not even zero).1 protected void dropLoot ( DamageSource source , boolean causedByPlayer ) {2 Identifier identifier = this . getLootTable () ;3 LootTable lootTable = this . world . getServer () . getLootManager () .getTable ( identifier ) ;4 LootContext . Builder builder = this . getLootContextBuilder (causedByPlayer , source ) ;5 lootTable . generateLoot ( builder . build ( LootContextTypes . ENTITY ) ,this :: dropStack ) ;6 }LootContext.Builder.build() catches the null object and sets it to a new Random instance.In layman's terms, it realizes the object has no value and then gives it one using the proceduredescribed in Section 9.2: Setting RNG Seeds.1 Random random = this . random ;23 if( random == null ) {4 random = new Random () ;5 }Essentially, both the number of nanoseconds since computer start-up and the result ofa different LCG are used to seed the LCG that decides whether or not to drop a blaze rod.Furthermore, the state of the Uniquifier when the seeding occurs in turn is dependent on howmany Random objects have been created by Minecraft since it was started (the value persistsacross worlds), which adds more entropy to they system.The code then runs nextInt(2) to determine the number of blaze rods that should bedropped (0 or 1).As a thought experiment, one could imagine freezing nanoTime() value through the operatingsystem, but since nextInt(2) returns the highest bit of the seed, there would still be no visibledependence; to be informal, the seed uniquifier alone provides enough "randomness". Likewise, ifone were to fix the uniquifier and let nanotime vary normally, the value of nextInt(2) wouldchange every few microseconds or sos- fast enough that factors such as lag and run lengthshould be considered a further major source of randomness in blaze drops. Regardless, it isalmost certain both of these components were working as expected, so the Random objects usedfor Dream's blaze drops should not have had unusual correlations.sThis estimate comes from dividing 247, the desired average size of a change of the seed needed for a changein value, by the multiplier for Java Random. This estimate is only rough due to the "scrambler" in the Randomconstructor, but is easily seen to hold up in practice.19Finally, given their vastly different implementations and separate code bases, it is reasonableto assume that a bug could not simultaneously affect both bartering and blaze rod drops. In fact,even in the (hilariously unlikely) occurrence of cosmic ray interference, two independent bit flipswould need to occur at bare minimum for it to have an effect on both.Part IVResults10 Computation10.1 Naive EstimateThe initial computations performed by community members directly applied the binomial distribution without considering the biases present in the data. To reiterate, what follows are naiveestimations operating under faulty assumptions we have spent the entire paper accounting for.The criticisms of directly applying these computations to this situation are legitimate, but theyare still meaningful and relevant if they are properly interpreted and their inaccuracies are kept inmind. First, for pearls:P(푋pearls ≥ 42) ≈ Õ262푘=42262푘(0.0473)푘(1 − 0.0473)262−푘 ≈ 5.65 × 10−12 (9)This is Shell Guy's "1 in 40 billion" number often referenced, which more accurately shouldbe 1 in 177 billion. Then, for rods:P(푋rods ≥ 211) ≈ Õ305푘=211305푘(0.5)푘(1 − 0.5)305−푘 ≈ 8.79 × 10−12 (10)For independent discrete random variables, the probability of two events occurring simultaneouslyis the product of their individual probabilities. Thus,P(푋pearls ≥ 42 ∩ 푋rods ≥ 211) ≈ (0.00000000000565319) (0.00000000000879143)≈ 0.000000000000000000000049699624≈ 4.9699624 · 10−23(11)This is 1 in 20 sextillion. The idea something this unlikely occurred is obviously ridiculous. Thenext section actually applies what we have discussed in the previous sections to compute astatistically rigorous upper bound on the probability.2010.2 Full ComputationThe code implementing these calculations can be found in Appendix C.10.2.1 PearlsUsing the method described in Section 8: Addressing Bias, we may compute an upper boundon the 푝-value. It is worth noting that this upper bound is conservative, and using it as if it werean exact 푝-value would result in an analysis that would be extremely biased in Dream's favor.First, we examine the pearl odds. Using the stopping rule correction from Section 8.1, weobtain a value of 1.22 × 10−11. Using this, we can bound the probability of getting this 푝-valueor less in a sequence of 11 streams (the number of streams that Dream did), as follows:1 −1 − 1.22 × 10−1111(11+1)2 = 8.04 × 10−10 (12)8.04 × 10−10 represents the highest possible probability of Dream ever, while on stream,getting pearl barter rates as exceptionally good as the ones in the data.Finally, we account for the chance across one thousand runners, a generous upper bound onthe number of runners who would be examined in a similar way:1 −1 − 8.04 × 10−101000= 8.04 × 10−7(13)8.04 × 10−7represents the probability that any active runner in the Minecraft speedrunning community would ever experience events as rare as Dream, at some point withinhis 11 streams, experiencing luck extreme enough that a malicious investigator wouldbe able to portray it as being as rare as Dream's bartering luckt.This should not be equivocated with the probability that Dream experiences luck as extremeas he did on any particular occasion, which is far lower. This number describes how surprising itis for this to ever happen—not how surprising it is for it to happen in a given instance. Althoughevents with a one in a million probability may occur sometimes, it is almost always when thereare multiple chances for them to occur—this number has already accounted for the multiplechances for Dream (or anyone else) to experience luck this exceptional.10.2.2 Blaze RodsLike with pearls, we again apply the stopping rule correction. This yields a 푝-value of 4.72 × 10−11.Unlike with the pearl drops, this is our final number. As mentioned previously, blaze rods are notsubject to selection bias across streams or runners, as Dream's blaze rod drops were examinedonly because of his pearl rates. Potential selection across RNG types by a malicious investigatoris still a problem, but this will be addressed in the combined 푝-value.tAs we account for p-hacking using the combined p-value rather than each individual p-value, technically youmust include the assumption that the malicious investigator only looks at one type of RNG. This assumption willbe addressed in the final p-value.10.2.3 Combined Number푝-values may be combined by Fisher's methodu. Fisher's method involves taking −2 times thesum of the logs of the 푝-values:푧 = −2log (푝rods) + log푝pearls (14)This value is known to follow a 휒2 distribution with 4 degrees of freedomv. Hence, we may usethe 휒2 CDF to get a combined 푝-value. Taking 휒2푘(푧) to mean the CDF of a 휒2 distributionwith 푘 degrees of freedom at 푧, we have:푝combined = 1 − 휒24(푧) ≈ 1.472 782 × 10−15 (15)We may then correct this value for potential investigatory bias as described in Section 8.4. Notethat there are not many obvious RNG targets for a runner to cheat. The two most obvious arepearls and blaze rods, but beyond that, it becomes less clear. Obsidian is an option, possiblyallowing for nether travel. Another option is string, which runners have recently started hopingfor with the advance of "hypermodern" strats that involve skipping villages—but hypermodernstrats were not well-developed during the time that Dream ran, and Dream did not go for string.Other potential options include flint rates from gravel, iron amounts from iron golems, and eyeof ender breaks, but these are not as obvious or as advantageous as the other options. As agenerous number, we use 10 for the number of likely targets. We have 10 options for our firstsource of RNG, and another 9 for the second (not 10 anymore, as the same source cannot beused twice), giving us 90 possible options:푝final = 푝combined × 90 = 1.325 504 × 10−13 (16)This is about 1 in 7.5 trillion. As stated earlier, this should not be equivocated to the probabilityDream got this lucky in a given instance, as it already accounts for many other factors beyondthat. This is a loose (i.e., almost certainly an overestimate) upper bound on the chancethat anyone in the Minecraft speedrunning community would ever get luck comparableto Dream's (adjusted for how often they stream).uhttps://en.wikipedia.org/wiki/Fisher's_methodvFisher, R. A. (1992). Statistical methods for research workers. In Breakthroughs in statistics (pp. 66-70).Springer, New York, NY.11 ConclusionIn our analysis, we were able to conclude the following statements:• The events that were observed on Dream's stream cannot be modeled by any sensible,conventional probability distribution.• After accounting for any contributors of bias, the likelihood of this occurring is stillunfathomably small.• There are no circumstances in a natural setting in which bartering and blaze drops could bedependent or biased to any notable degree, much less a degree strong enough to producethis result.• There is no way to accidentally manipulate these values in real time during an RSG speedrun,nor any conceivable way to do it intentionally using only conventional methods.The only sensible conclusion that can be drawn after this analysis is that Dream's game wasmodified in order to manipulate the pearl barter and rod drop rates.23A Raw DataFigure 3: Dream's pearl barter data. Timestamps and data from other runners athttp://bombch.us/DPPU.Figure 4: Dream's blaze drop data. Timestamps and data from other runners athttp://bombch.us/DPPV.24B Stopping Rule Computation AlgorithmThis section will describe the algorithm used to calculate the probability of a sequence of somenumber of Bernoulli trials will have at any point had a binomial CDF 푝-value below a certaincutoff. As with the other computations, the code implementing this algorithm can be found inAppendix C.The critical observation to understanding the algorithm used is that sequences with the samenumber of successes in the first 푛 trials can be treated as essentially equivalent in some ways.Critically, their 푝-value (after the first 푛 trials) will be equal: the binomial CDF calculation onlyconsiders the number of successes and the length of the sequence. Due to these equivalences,we can calculate these groups of sequences as a package-deal without considering the individualsequences.1/11/2 1/21/4 2/4 1/41/8 3/8 3/8 1/81/16 4/16 6/16 4/16 1/161/32 5/32 10/32 10/32 5/32 1/32This table depicts the probability masses of various sequences of blaze rod drop trials, groupedbased on how many successes they had in the first few trials of the sequence. Some readers mayrecognize a resemblance to Pascal's triangle, which famously is closely connected to the binomialcoefficient.Rows in this table, zero-indexed, represent the number 푛 of trials at the start of a sequencewhich are being considered, and columns, also zero-indexed, represent the number 푘 of successeswhich have occurred in the first 푛 trials. The numbers in a certain row and column are theprobability that, within the first 푛 trials, 푘 successes occur.As you move down the table, you can imagine each number giving some of its probabilitymass to the number directly below it (which represents the next trial being a failure, and thusnot increasing the number of successes) and the number below and to the right (which representsthe next trial being a success, and thus increasing the number of successes by one). Since weare discussing blazes, it will be split evenly; with bartering, it is split about 95% down and 5%down-right.To give a concrete example, the second "3/8" received a probability mass of 24×12=28fromthe 24to the up-left and a probability mass of 14×12=18from the 14directly up. This representsthe two ways two successes in three trials can be achieved: having one success in two trials,followed by an additional success, or having two successes in two trials, followed by a failure. Itshould be fairly simple to check by hand that, of the eight possible sequences of three successes orfailures a sequence might begin with, there are indeed three which have exactly two successesw.Next, consider the bolded 1/32 on the bottom. This passes a 푝-value cutoff of 푝 = 0.05,which we will use for the purposes of this example due to the actual 푝-value being impracticallysmall. Since all the sequences which have five successes in the first five trials will have met our푝-value cutoff at some point, we will remove these sequences from the table before continuingand add the entire probability mass of 132 to our stopping-rule corrected 푝-value before generatingthe next line.wSince the chances of success and failure are equal for blaze rods, each sequence is equally likely. Withbartering, on the other hand, not all sequences are equally likely and this method of checking would not work.251/16 4/16 6/16 4/16 1/161/32 5/32 10/32 10/32 5/32 0/321/64 6/64 15/64 20/64 15/64 5/64 0/64Notice how the table no longer follows Pascal's triangle; the last two fractions no longerrepresent the probability of a sequence with five or six successes in the first six trials, but theprobability of such a sequence which also did not have a 푝-value over the cutoff at any point inthe past. This is done to prevent double counting. For example, we already added the probabilitymass of the sequences beginning with six successes to the adjusted 푝-value when we added thatof the sequences beginning with five successes, so we do not need to add that probability mass asecond time.This process continues until we reach the desired number of trials. An important note is thatyou cannot simply look at whether one of the fractions is below the 푝-value cutoff: that is notthe probability that 푘 or more successes are gotten in 푛 trials. Instead, we calculate the numberof successes required to get a 푝-value below the cutoff for every number of trials before the totalamount, and then compare to the relevant number of successes at each step.26C Probability Computations1 import java . math . BigDecimal ;2 import java . math . RoundingMode ;3 import org . apache . commons . math3 . distribution . ChiSquaredDistribution ;45 class Corrections {67 static int SCALE = 100;8 static int NUM_TRIALS , NUM_SUCCESSES ;9 static BigDecimal P_SUCCESS , P_FAIL ;1011 public static void main ( String [] args ) {12 System . out . println (" --- ENDER PEARLS ---") ;13 double pearlStoppingRule = shiftyInvestigator (262 , 42 , " 0.0473") ;14 System . out . println (" Stopping rule : " + pearlStoppingRule ) ;15 double pearlStreamBias = 1 - Math . exp ( Math . log1p ( -pearlStoppingRule ) * 66) ;16 System . out . println (" Stopping rule + stream selection bias : " +pearlStreamBias ) ;17 double pearlRunnerBias = 1 - Math . exp ( Math . log1p ( -pearlStreamBias ) * 1000) ;18 System . out . println (" Stopping rule + stream selection bias +runner selection bias : " + pearlRunnerBias + "

") ;1920 System . out . println (" --- BLAZE RODS ---") ;21 double rodStoppingRule = shiftyInvestigator (305 , 211 , " 0.5") ;22 System . out . println (" Stopping rule : " + rodStoppingRule + "

");2324 System . out . println (" --- FINAL PROBABILITY ---") ;25 double fisherMethod = -2 * ( Math . log ( pearlRunnerBias ) + Math .log ( rodStoppingRule ) ) ;26 ChiSquaredDistribution csd = new ChiSquaredDistribution (4) ;27 double cdf = 1 - csd . cumulativeProbability ( fisherMethod ) ;28 double pHacking = cdf *= 90;29 System . out . println ( pHacking ) ;30 }3132 static double shiftyInvestigator ( int trials , int successes , Stringp ) {33 Corrections . NUM_TRIALS = trials ;34 Corrections . NUM_SUCCESSES = successes ;35 Corrections . P_SUCCESS = new BigDecimal ( p ) . setScale ( SCALE ,RoundingMode . CEILING ) ;36 Corrections . P_FAIL = BigDecimal . ONE . subtract ( P_SUCCESS ) .setScale ( SCALE , RoundingMode . CEILING ) ;3738 BigDecimal targetP = BigDecimal . ONE . subtract ( binomCDF (NUM_TRIALS , NUM_SUCCESSES - 1) ) ;392740 int [] significantCutoffs = new int [ NUM_TRIALS + 1];41 significantCutoffs [0] = 0;42 for ( int observedTrials = 1; observedTrials <= NUM_TRIALS ;observedTrials ++) {43 boolean foundCutoff = false ;44 for ( int sucTrials = significantCutoffs [ observedTrials -1]; ! foundCutoff45 && sucTrials <= observedTrials ; sucTrials ++) {46 foundCutoff = ( BigDecimal . ONE . subtract ( binomCDF (observedTrials , sucTrials - 1) )47 . compareTo ( targetP ) <= 0) ;48 if ( foundCutoff )49 significantCutoffs [ observedTrials ] = sucTrials ;50 }51 if (! foundCutoff )52 significantCutoffs [ observedTrials ] = observedTrials ;53 }5455 BigDecimal [] lastRow = { BigDecimal . ONE , BigDecimal . ZERO };56 for ( int N = 1; N <= NUM_TRIALS ; N ++) {57 lastRow = genNthRowOfPascalWithCutoffs (N , lastRow ,significantCutoffs ) ;58 }5960 BigDecimal total = BigDecimal . ZERO ;61 for ( BigDecimal b : lastRow ) {62 total = total . add ( b ) . setScale ( SCALE , RoundingMode . CEILING );63 }6465 return BigDecimal . ONE . subtract ( total ) . doubleValue () ;66 }6768 static BigDecimal nCr (int n , int r ) {69 if ( r > n / 2)70 r = n - r ;7172 BigDecimal answer = BigDecimal . ONE . setScale ( SCALE ,RoundingMode . CEILING ) ;73 for ( int i = 1; i <= r ; i ++) {74 answer = answer . multiply (new BigDecimal ( n - r + i ) .setScale ( SCALE , RoundingMode . CEILING ) ) ;75 answer = answer . divide (new BigDecimal ( i ) . setScale ( SCALE ,RoundingMode . CEILING ) , RoundingMode . CEILING ) ;76 }77 return answer ;78 }7980 static BigDecimal binomialPDF (int n , int k ) {81 return nCr (n , k ) . multiply ( P_SUCCESS . pow ( k ) ) . multiply ( P_FAIL .pow ( n - k ) ) . setScale ( SCALE , RoundingMode . CEILING ) ;82 }288384 static BigDecimal binomCDF (int n , int maxSuccessesInc ) {85 BigDecimal answer = BigDecimal . ZERO . setScale ( SCALE ,RoundingMode . CEILING ) ;86 for ( int i = 0; i <= maxSuccessesInc ; i ++) {87 answer = answer . add ( binomialPDF (n , i ) ) . setScale ( SCALE ,RoundingMode . CEILING ) ;88 }89 return answer ;90 }9192 static BigDecimal [] genNthRowOfPascalWithCutoffs ( int N , BigDecimal[] lastRow , int [] significantCutoffs ) {93 BigDecimal [] result = new BigDecimal [ N + 2];94 result [0] = lastRow [0]. multiply ( P_FAIL ) . setScale ( SCALE ,RoundingMode . CEILING ) ;95 for ( int i = 1; i < N + 2; i ++) {96 if ( i <= significantCutoffs [ N ]) {97 result [ i ] = lastRow [ i - 1]. multiply ( P_SUCCESS ) . add (lastRow [ i ]. multiply ( P_FAIL ) ) . setScale ( SCALE ,98 RoundingMode . CEILING ) ;99 } else {100 result [ i ] = BigDecimal . ZERO ;101 }102 }103 return result ;104 }105 }