Talk:Random Distribution

Untitled 1

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)

Untitled 2

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 [[w:Pseudorandomness|[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: [[w:Independence_(probability_theory)|[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)

Untitled 3

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)

Untitled 4

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)

Untitled 5

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)

Untitled 6

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)

Untitled 7

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 Nmax, 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 ≤ Nmax .
By doing this, we can solve C in terms of Nmax via the axioms of probability theory, since the summation of the PMF must equal 1. So:
ΣP(N = n) = 1 = C(1 + 2 + ... + Nmax) → C = 2 / (Nmax² + Nmax) .
Immediately, we come to an issue; this relationship does not satisfy most pairs of C and Nmax provided in the table, except for a few that are correct within rounding up or down since Nmax 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 + 2Nmax) .
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 Nmax in terms of r:
Nmax = (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 Nmax 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 Nmax, 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 Nmax, 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 —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)

Actual Proc Chance of Spirit Breaker's Greater Bash

Is there any reason not to assume that the actual proc chance of Greater Bash is the same as its PRD chance of 17% (comparing it to other PRDs, e.g. Slardar's Bash, the actual proc chance starts becoming lower than the PRD chance from 25% on and is always the same for lower percentages, of course neglecting the rounding)? Psion1C (talk) 13:13, 29 September 2015 (UTC)

I think it is 17% and obviously your logic seems correct to me. Wolfmonster3 (talk) 16:06, 29 September 2015 (UTC)

Test for PRD & CD

Hello,

1. Does PRD counter increase during cool down of basher?
2. Could it possible reset when the item is on CD too? or does it consider all hits failure and strictly increase counter?
3. how can we test this?

MapDesigner (talk) 09:17, 17 December 2016 (UTC)

I guess there's no way to find out, unless we get access to the source code. You still can mention your points in the article, it's important to know that we lack of this information. We don't know if Blind uses PRD either. Or if there's a timeout of the counter and if so, what's its value. Molldust (talk) 01:36, 18 December 2016 (UTC)

Ummm, I am pretty sure blind uses True random distribution. I do not exactly remember where I found that, I asked why solar crest is listed in both PRD and true random, and answer was that evasion is pseudo while blind was true random. Now what do you mean by "timeout of the counter" in your statement? MapDesigner (talk) 04:43, 18 December 2016 (UTC)

We had the official statement that Evasion now uses PRD, but had no validation if this applies or includes Blind. It's the same mechanic after all. You got the explanation why Solar Crest in on different pages at our best knowing. Unfortunately this doesn't mean it's true or still up-to-date. Having sources always beats opinions.

Every event under the effect of PRD has a counter that holds the amount of successive misses. If there wasn't a timeout, you could store up low chance hits (e.g. Bara, PA) over an indefinite timespan. As this would defeat the purpose of "random", PRD is usually paired with a timeout that "resets" the counter after a certain time to the initial chance. Molldust (talk) 09:37, 18 December 2016 (UTC)

Hmmmmm, I made a test which I believe could explain this.

1. Get doom with 100 attack speed and right click a unit.
2. Result, doom will have 20% chance to bash
3. Notes: during CD of basher, doom can only make 1 attack, therefore increasing the PRD counter by 1, if any.
4. Conclusion: since % is exactly as theoritical solution of true random, this indicate that PRD does not increase

results of the test running for 9 hours were:

1. DPS = 60.85
2. Average Damage per hit = 2*dps = 121.7
3. Dmg with no Bash = 109 = x
4. Dmg with Bash = 172.75 = 109+85/4 = y
5. avg = (xN1 + yN2)/(N1+N2)
6. avg (N1+N2) -xN1 = yN2
7. avg . N1 - xN1 = yN2 - avg N2
8. N2 = N1 . (avg - x)/(y-avg) = 12.8/50.95 = 0.25

MapDesigner (talk) 13:43, 18 December 2016 (UTC)

Sounds legit, you can write the conclusion on the page if you want. Molldust (talk) 15:16, 18 December 2016 (UTC)

Nah there seem to be something wrong. We need more tests than that. I already am making another test, and so far chance to bash is 23% (running for 1 hour so far), and it seems to have an increased chance more than 20%. If the chance is more than 20% then Counter is increasing. ATM the average DPS is 62.78 (last time it was 60.88 MapDesigner (talk) 15:38, 18 December 2016 (UTC)

Recent update to PRD C-values need reevaluation

On November 12, there was an update to the C-values for the PRD. However, I don't think the updated values are accurate. With the new value of 66.66667% (EDIT: for MKB's intended 75% proc chance), the probability of the second hit is P(2) = 66.6667%*2=120% (capped at 100%). This is verifiably false in a test lobby using MKB.

Counter-example log: [02:12.59] Bristleback hits Doom for 111 damage (5541->5430). - MKB proc

[02:13.59] Bristleback hits Doom for 113 damage (5434->5321). - MKB proc

[02:14.60] Bristleback hits Doom for 112 damage (5324->5212) - MKB proc

[02:15.60] Bristleback hits Doom for 44 damage (5215->5171). - No proc

[02:16.63] Bristleback hits Doom for 47 damage (5176->5129). - No proc

[02:17.63] Bristleback hits Doom for 108 damage (5132->5024). - MKB proc

--172.31.10.65 23:23, 23 November 2017 (UTC)

Until we can independently verify the new values, I think the old ones have more credibility.

im sorry why do you think the old values are more credible? Edit: nvm I think this whole article is out of date. I have made a test for about 500 mkb strikes and the actual chance of mkb doesnt match any of the nither the old nor new (chance was between 74% to 76% everytime I tested)

how does new PRD work? article out of date?

Hello guys,

I had the thought that MKB might not be actually as good as the tooltip says because in this article it says the actual chance is lower than 75%. anyway so i tested MKB for about 500 hits including 220 continues hits with doom, and I had 161 proccs and 79 fails to procc, which gives the chance to be 75.45% which is really close to the said value here. however, the problem is that I could actually have 3 consecutive hits failing to procc mkb. I had this multiple times during the test suggesting that PRD mechanic isnt exactly as explained here.

Can someone please explain how I could have these fails 3 times consecutively? — The preceding unsigned comment was added by MapDesigner (talk) • (contribs) 5 January 2017 • Please sign your posts with ~~~~