Talk:Random Distribution

Based on the August 05, 2011 Patch, which lists "Adjusted chances for pseudo-random items/abilities to proc so they are correct (less frequent for chances > 25%)", I created an article on PRD (assuming it works as in DotA). If anyone knows anything different, put it here. Also, feel free to add to the lists. -Baloroth 01:14, 8 November 2011 (UTC)

Has someone just added together ~42% to say that it will always happen after three times? The odds do not suddenly rise to 126% to influence future procs. By this reasoning if you flip a coin and get tails you will always get a heads right after. You have done a 50% chance twice, obviously the odds are now at 100%.

The actual formula goes 1-(58%^x) where x is how many hits you've done so far. That is to say, after one hit you are at 0.6636, two hits puts you past 0.7 to 0.804888 and so on. Basically you calculate the odds for the proc NOT happening, then you pull that from one.


 * That's not how PRD works. It does, infact, add the chance each time you get hit.It isn't random: hence, Pseudo-random. -Baloroth 18:11, 6 June 2012 (UTC)


 * I might be being really picky here, but I think you guys are using pseudorandom not in the sense that it was defined to be used by mathematicians and physicists. Almost every computer game out there uses pseudorandom number generators to make their random numbers, because to make "truly random" numbers you need to measure quantum mechanical effects, take the lowest significant digit from a voltage measurement or physically roll a dice [1 ]. The way you guys are using it (and I know the original Playdota article suffers from the same problem) is that even though both the WC3 Dota way and the Dota 2 way of getting random numbers through means that makes those numbers trivially pseudorandom, you guys are using the term to describe something outside it's generally accepted definition--that the WC3 method is basically a contrived method used to ensure that the player will guarantee a proc after a certain number of attempts. I suppose this makes sense if the word "pseudorandom" wasn't already taken, but it is so I think this dual interpretation of pseudorandom may confuse some of the physicists and mathematicians out there who may care to visit this page (not that I'm a physicist or mathematician). --CtChocula 19:00, 11 August 2012 (UTC)


 * Never mind, noticed Valve was the one who started using the term. --CtChocula 19:04, 11 August 2012 (UTC)


 * "Pseudorandom distribution" is unrelated to "pseudorandom number generation". This is confused so often that I should probably make a note about it. --Kroocsiogsi 20:01, 11 August 2012 (UTC)


 * Sorry; I just edited the page without reading the discussion first. Anyway, as far as I can tell, the first use of pseudorandom to refer to dependent randomness came from Valve. This was most definitely a mistake by them (I mean, they are after all human and do make errors) since this does not match the words used everywhere else. Wikipedia has an article on dependence/independence for more information: [2 ]. This concept is centuries old, and is introduced in any basic probability course; it is used by anyone who has studied or uses probability in their lives. I definitely think that DoTa should use the word that is used everywhere else to descibe this process, and not just come up with its own definitions. You have already seen the problem it's caused by being similar to "pseudorandom number generation". But that's not the only problem. The other problem is that it gives people the belief that dependent random processes are in some way not random. This is completely false, and will just lead to even more confusion. Furthermore, the word 'dependent randomness' descibes the process perfectly, so it would be folly to not use that word. Valve was obviously unaware of all this, but then it is our duty to correct the mistake here, and not make Valve suffer for their error for ever.
 * Also, I don't know how to edit titles; could someone do so? Thanks
 * I agree that the correct course of action is to change the name to reflect the terminology used in probability theory, and doubly so in this situation where the incorrect name is confusing. AFAICT, this name was not chosen by Valve initially, but rather comes from the playdota article referenced. However, this is a very large change, and making this change without any discussion is likely the wrong move, even in clearcut situations like this. I've reverted the changes for now. If there are any objections to changing the page to use the DRD terminology, then we can give them a few days to make their case. If not, then we can undo my revert. The page itself cannot be renamed. If we decide to make the change, IIRC, the correct course of action is to copy the whole page contents over to a new page with the appropriate name, and then make the current page a redirect. --68.228.245.62 15:00, 31 March 2014 (UTC)

Shouldn't Lycanthrope be renamed to Lycan on this page to reflect the recent name changes? --66.189.43.12 08:08, 2 December 2013 (UTC)

Someone should do the number crunching for 17% (axe's helix) --Jimmydorry (talk) 12:16, 4 May 2014 (UTC)


 * I did a bit of testing and the "c" value of a 17% chance proc is around 0.04097 (thus you can be hit 24 times max without proccing Counter Helix at worst). I don't know which value does Valve use for that, but I heard Axe's counter Helix PRD is the best PRD of Dota 2, because it is the only one entirely done by Valve (the others PRDs were ported from DotA I've heard). --129.104.247.2 08:15, 30 May 2014 (UTC)


 * Thanks, I'll go add that now. The only problem is that the table increments every 5%, but Axe's Counter Helix is 17%... I could just make a special note. However, Legion Commander's Moment of Courage also had PRD added. I'm not quite sure how to test for the constant, so finding those numbers for me would be a huge help.
 * --PimpadelicX (talk) 08:38, 30 May 2014 (UTC)

The following statement is FALSE : "Max N is the minimum number of attacks that would result in C * N becoming greater than 1.00, and the maximum number of attacks that could possibly occur before a modifier succeeds", it is not C * N becoming greater than 1, but C * (N + 1), because N is intended to represent the maximum number of "failures" (modifier not being applied), which leads to a failure during the Nth try, so its probability C * N has to be strictly less than 1. --129.104.247.2 07:28, 30 May 2014 (UTC)


 * I saw this a long time ago, but never bothered to edit because I wasn't big into Wiki editing. Now that I've gotten used to it, I will absolutely change it. It makes no sense that an 80% ability will proc at least every 1 attack... That's 100%! I will just add +1 to all the numbers, as opposed to changing "Max N" to "Max Misses". It makes more sense in my mind, but I'm sure that's what the original poster had in mind.
 * --PimpadelicX (talk) 07:59, 30 May 2014 (UTC)

Has anyone verified those DotA mechanics also apply for Dota 2 ? --129.104.247.2 07:28, 30 May 2014 (UTC)


 * I'll answer to myself : after a bit of searching it seems Valve ported DotA RPD to Dota 2, the only exception being Axe's Counter Helix (17%, inexistent in DotA). --129.104.247.2 08:17, 30 May 2014 (UTC)


 * No love for Moment of Courage I see :P
 * --PimpadelicX (talk) 08:38, 30 May 2014 (UTC)

Someone tell me how to generate PRD constant C for a certain probability. I couldn't figure out C for newly incorporate 17% PRD for counter helix. Saspoon (talk) 17:00, 3 June 2014 (UTC)
 * There's no formula, but it's relatively easy to simulate, see http://exar.ch/files/prd.html for instance178.83.234.41 20:44, 25 June 2014 (UTC)
 * This website only uses 1 million trials which may seem like a lot, but causes a lot of fluctuations. I decided to take the code from the website and increase the trials. I'll come back with my findings for Legion Commander's 16%, 18%, and 22% for Moment of Courage.
 * --PimpadelicX (talk) 22:02, 25 June 2014 (UTC)
 * After using 500 million trials, I've come up with these values. I assume they are the same as in the game, because the percentages don't deviate until 25%.
 * 16% - 0.03645
 * 18% - 0.04562
 * 22% - 0.06668
 * --PimpadelicX (talk) 22:32, 25 June 2014 (UTC)

Verifying Article Math
I'm having difficulty reproducing the table of C and Nmax values given the nominal (this article uses the term theoretical but that sounds like a misnomer to me) tooltip trigger (proc) rate, so I'd like to reopen the discussion, either to prove myself wrong or to correct a perceived inconsistency.

For starters, lets assume "The probability of a modifier occurring on the Nth attack since the last successful modifier is given as P(N) = C * N" is a totally correct statement; if it isn't then my argument is borked right off the bat, but that would mean the article is also kinda borked. This formula (function) makes sense: if N = 0 then the probability is also zero, since you can't crit/bash/block if nobody has made any attacks yet. For N = 1, the probability is C, which also makes sense in context of the rest of the article. It also makes sense that there is an N max, since valid probabilities can never exceed 1.0, so at some point the function has to stop growing as N increases (or equivalently, N must have a finite upper bound).

Allow me to explicitly define what N represents and show that it is completely consistent with the statement taken as correct quoted above. N is a random variable that counts the number of hits since the last proc that have occurred at the instant the next proc occurs. N cannot be zero because that implies no hits have been launched (consistent with above). If N = 1, then the next proc occurs immediately after the last proc, and this happens with probability C (consistent with above). If N = 2, the first hit is a no proc and the second hit is the next proc. If N = 3, the first two hits are no proc, and so on. This subtle change of wording is what I used to reason through the rest of the argument, so please use extra scrutiny here; if my definition is not 100% equivalent to the one stated in the article, then my whole argument collapses!.

From here, we can formalize our formula by using the probability operator P and write the probability mass function (PMF):

P(N = n) = Cn, 0 ≤ n ≤ N max.

By doing this, we can solve C in terms of N max via the axioms of probability theory, since the summation of the PMF must equal 1. So:

ΣP(N = n) = 1 = C(1 + 2 + ... + N max ) →  C = 2 / (N max ² + N max ).

Immediately, we come to an issue; this relationship does not satisfy most pairs of C and N max provided in the table, except for a few that are correct within rounding up or down since N max has to be a whole number.

If we carry on, we can find the expected (mean) value of N for a given value of C using the expectation operator:

E(N) = ΣnP(N = n) = CΣn² →  E(N) = (1/3)(1 + 2N max ).

From here, we can realize that this expected value represents how many (on average) total hits take place per single proc, which we can connect to the nominal proc rate (which I will call r) simply:

r = 1/E(N) ,

From which we can back-substitute for N max in terms of r:

N max = (3 - r) / (2r).

Therefore; given the nominal r from the tooltip of a skill/item known to use the PRD, we can find analytical values for C and N max that should be exactly correct (provided I didn't make a mistake in my derivation or in my definitions). The problem is, of course, none of these formula produce numbers that match the tables presented in the article. I'd like to propose two routes towards solving this problem:


 * 1) Is the definition of N provided inconsistent with that of the original formula?  I realize that the Maximum N provided in the table may actually be different from my N max, but they should be within +/- 1 of each other.
 * 2) Are there mistakes in my algebra?  I don't think there are.
 * 3) Has anyone obtained large scale samples of PRD data from the actual in-game DOTA2 (not DOTA1/WC3) client to validate the probabilities presented in the table?  Others in the discussion page have mentioned a simulator but there is no guarantee that it is comparable to the DOTA2 client unless there are links to its source code and relevant data taken from DOTA2 itself.

--TheKman0 (talk) 21:11, 20 November 2014 (UTC)
 * My understanding is that to get N max, you find the first value for N when P(N) exceeds 1. So P(N) = 1, solve for N, then round up to the nearest int. P(N)= C * N -> 1 = C * N -> 1/C = N. 1/C = N seems to match up with the values on the table. Does that make sense, and answer the question? source: http://www.playdota.com/forums/showthread.php?t=7993 &mdash; LingoSalad (talk) 00:36, 21 November 2014 (UTC)


 * I see; if that's the intention then I think the phrasing of P(N) isn't really wrong, it's just ambiguous and can mean two separate things at once. In that case, the probability mass function isn't the same as P(N); P(N) is actually the conditional probability of a proc happening given that you haven't procced yet.  In other words, if you haven't procced in 2 hits, then the probability of the next hit proccing is 3C; every time you swing without a crit, you flip a different coin with NC% chance to crit.  The actual probability of proccing on a particular n'th swing since the previous proc should be given by:


 * P(N = n) = nCΠ(1 - kC), 0 ≤ k ≤ (n - 1) ,


 * I'll test this to see if it's consistent with the numbers in the table, and see if I can come up with a less ambiguous phrasing. --TheKman0 (talk) 18:19, 21 November 2014 (UTC)


 * After some work, I've managed to derive an expression relating the value of C to the actual expected proc rate (P(A) in the current article). I would like to volunteer a complete rewrite of this page, expanding it to include an explanation of classically random (non-PRD) effects in DOTA2, of the current understanding of PRD effects in DOTA2, and of how the PRD accomplishes the goal of smoothing out crit/helix streaks.  Comments?--TheKman0 (talk) 18:26, 4 December 2014 (UTC)

Javelin
Can anyone confirm that Javelin uses PRD? The internal PRD types (such as DOTA_PSEUDO_RANDOM_ITEM_MKB) don't include one for Javelin. Pie4all88 (talk) 01:52, 2 February 2015 (UTC)