Beautiful work !!!
I'm not good enough with statistical mathematics. But it's what I wanted to do to check why r-ppm is so much random.
Beautiful work !!!
I'm not good enough with statistical mathematics. But it's what I wanted to do to check why r-ppm is so much random.
OP is free to do what he wants with the my post.
Attempt to make it more accessible without the maths:
All graphic examples are made using 1 RPPM.
Issues with the current RPPM system:
With the current RPPM design, have you ever wondered why on some fights you get a lot more procs than on another ? Have you ever felt like the time for proc varies way too much ? Why sometimes procs override themselves and sometimes you have to wait 3minutes to get a single proc ?
All this is normal due to the formula employed in the current design. We can calculate the probability of "how much time it takes to get a proc". Here is the curve for the current RPPM (see under graphic for easy explanations) for 1 proc per minute:
This answers why you sometimes feel "Why sometimes procs override themselves and sometimes you have to wait 3minutes to get a single proc ?". The average time is at 60seconds (1 proc per minute). However, this average is made by a high probability in the short time (this means there is a high chance of getting a proc after a short time) and long times (far superior to 60) still having a non-negligeable probability.
This in essence means that the time until next proc varies a lot instead of being more symetric around its average.
=> With the current design you'll get sometimes very short procs and sometimes very long ones.
If you're interested in the mathematics involved you can take a look here in section "Analysis of the RPPM system".
This directly relates to the second issue "With the current RPPM design, have you ever wondered why on some fights you get a lot more procs than on another ?".
As before we can compute the probability to get a specific number of proc during a fixed time T. What you see below is the chance to get a number of procs for a 360seconds fight (for 1RPPM).
=>As you can see, while the average is around 6 procs a fights, the curve is "quite wide". It means there is a non-negligeable chance to get a very low number of procs and a very large number.
The proposition (smoothed RPPM):
If you've followed me so far we have identified two potential problems:
-The time between procs can vary a lot. We get a lot of short intervals and some potentially crazy long intervals. To the point where it is a bit extreme. While ICD trinkets were a bit too predictable, these are just crazy random.
-The number of procs during a fight is inconsistent. This make one trinket have wide performance differences between one fight and the next and between one person and another. This is something that most guilds hate on progression. "We wiped because my trinkets didn't proc more than once" or "I'm 10K dps behind because his trinket decided to proc 15 times while mine procced 3 times".
First, the proposed solution is still a random one. You still won't be able to accuretly predict when a trinket will proc. However, it is an attempt to diminish the 2 problems mentioned.
=>Get a more symetric "time until next proc" around its average. No very quick procs, no terribly long ones. Same average.
=>This should also make the number during a whole fight more consistent and with less variance. So that if a trinket is actually 1 RPPM you have a high chance to actually get that, i.e. 6 procs during 6 minutes. And sometimes you'll get 4 or 8 but no more 2 or 10 like the current system.
The solution is to add into the formula of proc chance a factor that is dependant on the time since last proc. That way, the more time has passed since the last proc, the more your chances are to get a new proc.
Here are the same curves as before but with the solution (green=smoothed RPPM blue=RPPM):
Density curves:
=>Here you can see most of the probability is centered around the average of 60seconds between procs. No more very quick ones, no more very long ones.
Probability for the number of procs:
=>Here you can see the bell is less wide and therefore more centered around a specific number of procs. While this wouldn't make the number of procs fixed it would decrease the variance of the number of procs per fight.
Once again for the exact formula and mathematics see here.
Formulas:
Current RPPM:
For every event that can trigger a RPPM-based proc, the chance that this actually happens is :
P = R * H * (t - t0) / 60
Where :
- R is the base RPPM rate (in procs per minute).
- H = (1 + h%) is the haste factor.
- t is the current time (in seconds).
- t0 is the time of the last event that had a chance to trigger the proc.
Proposition:
P = A * (t - t1) * R * H * (t - t0) / 60
A = Pi * R * H / (2 * 60)
Where :
- R is the base RPPM rate (in procs per minute).
- H = (1 + h%) is the haste factor.
- t is the current time (in seconds).
- t0 is the time of the last event that had a chance to trigger the proc.
- t1 is the last time the proc actually triggered. We will consider it to be 0 to keep the equations clear.
- A is a normalization constant.
Hope that helped you understand if you're not very maths savy !
Note to OP:
You can also make it more general I think by adding a power to (t-t1) => (t-t1)^k
Then you play with k to make the curves more or less centered depending on how wide you want the distribution to be. Current RPPM is k=0, it gets more and more centered around the averages as k increases.
Last edited by rezoacken; 2013-03-11 at 10:19 PM.
5.1 16/16 HC 5.2 12/12
That's a great clarification, are you okay with me quoting it in the OP before the analysis ? (I'll go ahead and do it right away, just tell me if you'd prefer not and I'll remove it).
Surutcra@EU-Hyjal (Arcturus#2484)
Nice work, very intelligently designed post.
GC has already stated they are "considering" something along the lines of the system you proposed.
https://twitter.com/Ghostcrawler/sta...67406013296640
Thanks for putting all the effort into writing this up!
The problem is that a system like this already exists in game for warlock Nightfall procs. If their goal was to have a system that scaled in some way based on the time since the previous proc (not last chance to proc) they likely would have done it. My guess is they like the "feeling" of a trinket that has the same chance to proc in any given second. The only way to combat RNG and keep this model is to do what they have done with weapon enchants and have something that has a relatively high rate compared to typical fight lengths.
Edithadn't seen the tweet when I posted this) It's like they never learn from anything they've experienced before...
Gamer, Nerd, Physicist. What more could you want?! Well fine, I have a youtube: http://www.youtube.com/user/shaidyadvice and a stream: www.twitch.tv/shaidyadvice
Thanks for that well written explanation, Rezoacken, very nice. Now I at least fully understand what I was sort of vaguely grasping at.
Even if they don't go for this exact same solution to the problem, I feel it's still posts like this that help them understand what the problem is, and what we'd like to see fixed.
I think crazy random with these gaps is exactly what they were going for when they made this system. I get the impression that they feel we can math out pretty much everything that they make at this point, and want to bring back some mystery and excitement that the game had before we could model pretty much everything. I really hated RPPM when it first was introduced, but it's starting to grow on me. Procs are starting to feel more like a bonus when I can use them well, instead of just another mandatory thing to be planned and accounted for. I like getting lucky. Hate getting unlucky, but it's kinda necessary if you wanna get lucky too, instead of feeling like you didn't do something mandatory. I'd support the switch, though. I can't imagine most people who notice care for the RPPM system, and I did feel more skillful when I could anticipate and play to my procs.
After being Medieve the Uberpally for many years, finally shelved in favor of Belledanna, the Uberlock!!! (patent pending)
W-Th 6:45 PM EST to 11:00 PM EST - Neolutum of Turalyon, always recruiting! http://neolutum.enjin.com/home
-Retired as of the end of 5.3
Totally true, but the math gets more complicated when it comes to computing the value of the normalization constant required to achieve E[T] = 60 / (R*H)
Working with dP = C * t^k * dt, g(t) = P[T > t] and f(t) = P[t < T < t+dt] / dt (probability density of T), you get :
(log g)'(t) = - C * t^k
g(t) = exp(-C * t^(k+1) / (k+1))
f(t) = C * t^k * exp(-C * t^(k+1) / (k+1))
Then you are faced with computing E[T] and E[T²]
E[T] = Integral(0, infinity)[t * f(t) * dt]
E[T] = Integral(0, infinity)[C * t^(k+1) * exp(-C * t^(k+1) / (k+1)) * dt]
Integration by parts : integrate t^k * exp(-C * t^(k+1) / (k+1)) and derive t
E[T] = ValueBetween(0, infinity)[- t * exp(-C * t^(k+1) / (k+1))] - Integral(0, infinity)[-exp(-C * t^(k+1) / (k+1)) * dt]
The ValueBetween is null, and you make the following variable change in the integral :
u = C * t^(k+1) / (k+1)
t = K * u^(1/k+1)
dt = (K/(k+1)) * u^(-k/(k+1)) * du
K = ((k+1)/C)^(1/(k+1))
E[T] = K/(k+1) * Integral(0, infinity)[exp(-u) * u^(-k/(k+1)) * du]
This integral is known as Gamma : Gamma(z) = Integral(0, infinity)[x^(z-1) * exp(-x) * dx]
E[T] = K/(k+1) * Gamma(1/(k+1))
However, afaik there is no analytical value known for any k > 1.
Noting G(k) = Gamma(1/(k+1)), we get the following condition on C :
E[T] = G(k) * ((k+1)/C)^(1/(k+1)) / (k+1) = 60 / (R*H)
<=> C = (R*H*G(k)/60)^(k+1) / (k+1)^k
(Note : with k = 1, G(k) = Gamma(1/2) = sqrt(Pi) and C = (R*H/60)² * (Pi / 2) as in the previous analysis)
E[T²] = Integral(0, infinity)[t² * f(t) * dt]
E[T²] = Integral(0, infinity)[C * t^(k+2) * exp(-C * t^(k+1) / (k+1)) * dt]
Variable change :
u = C * t^(k+1) / (k+1)
t = K * u^(1/k+1)
dt = K/(k+1) * u^(-k/(k+1)) * du
K = ((k+1)/C)^(1/(k+1))
E[T²] = Integral(0, infinity)[K * u^(1/k+1) * (k+1)*u * exp(-u) * K/(k+1) * u^(-k/(k+1)) * du]
E[T²] = K² * Integral(0, infinity)[u^(2/(k+1)) * exp(-u) * du]
E[T²] = K² * Gamma(1 + 2/(k+1))
Since Gamma(z + 1) = z * Gamma(z), noting G2(k) = Gamma(2/(k+1)) :
E[T²] = 2*K²/(k+1) G2(k)
(Note : with k = 1, G2(k) = Gamma(1) = 1 and E[T²] = 2 * ((2/C)^(1/2))^2 / 2 = 2/C) as in the previous analysis)
Then :
Var[T] = E[T²] - E[T]²
Rel_std_dev[T] = sqrt(Var[T]) / E[T] = sqrt( E[T²] / E[T] - 1)
Rel_std_dev[T] = sqrt( (2*K²/(k+1) * G2(k)) / (K²*G(k)² / (k+1)²) -1)
Rel_std_dev[T] = sqrt(2*G2(k)*(k+1) / G(k)² -1)
Here is a graph of the probability distributions for k = 0 (RPPM), 1 (Smoothed RPPM), 2 ... 5 :
And a graph of the relative standard deviation as a function of k :
Surutcra@EU-Hyjal (Arcturus#2484)
Note that as I mentionned in the analysis, you can always "reverse engineer" the formula for h(t) (in dP = h(t) * dt, i.e. h(t) is the probability to proc a trinket per unit of time when t time has passed since the last proc) in order to achieve a target probability distribution for T (say a normal distribution).
You will proabaly stumble on integrals that have no known analytical value (if you want T to be normal, you will encounter the Gaussian integral for example). But contrary to rezoacken's suggestion where you only need to get Gamma(1/(k+1)) once and for all (after you decided on which k to use), you would need to store the value of that integral for every possible value of t you want to consider (this is not really a problem either).
Surutcra@EU-Hyjal (Arcturus#2484)
Yeah that's still very unclear what they are going to do exactly, but as long as they got the issue on their radar and do something to fix it it can only improve the situation, I guess.
Also, a firend of mine testing some 0.5 RPPM trinket he got yesterday night assured me his trinket would proc almost 100% of times right after he pulled. Did not investigate much further but they obviously changed something already then, probably as a temporary measure. (This was on EU realms).
---------- Post added 2013-03-12 at 02:33 AM ----------
The formulas in the post are correct and normalized as they should be, that was really just me mistyping and plotting something else (which ressembled the right curve, thus the impression that it was just badly normalized). Everything's fixed now, though.
---------- Post added 2013-03-12 at 11:19 PM ----------
Something's coming !
https://twitter.com/Ghostcrawler/sta...62675836551168
I'm really curious now !
Surutcra@EU-Hyjal (Arcturus#2484)
45sec on it its pretty awsome then. But does it procs at start at most of the time?
Hydra still doesnt but I dont know if those things have gone up on Europe yet
Warlock / IA Operative / Wizard / Engineer
Well this is what Blizz decided to do to change the trinkets. This seems the current trinket discussion thread, so, thoughts? How does it match up against the idea put forth in the OP?Originally Posted by Blizzard Entertainment
Well in essence this is the same thing. That part: ''Every time the trinket fails to activate, there's an increasing chance that it will activate.'' is the same as the one used by pongueur. They probably added a function of t-t1 (where t1 is the last proc). Pongueur uses a linear function of "time since last proc", dont know what blizzard uses.
Now it would be easier to really know how they do it with the complete formula but so far its good news.
5.1 16/16 HC 5.2 12/12
Yep that's still too little information to make any calculation at this point. Assuming their solution is consistent with the model I presented here, it should be pretty straightforward to get results as soon as they give specifics.
I feel like this model is a very natural generalization of the RPPM one, but it's totally possible they came up with something else, in which case I'll do the math if I am able to ;-)
---------- Post added 2013-03-13 at 08:52 AM ----------
How sure are you the expected wait time is 45s (meaning : how long / how many procs did you test it for !). Because it's supposed to be 0.5ish RPPM, so 45s would be way off.
Surutcra@EU-Hyjal (Arcturus#2484)
Hey there quick question, as warlock ( im still considering my ms since todays nerfs) i got the lfr wuuuushlyas something or other trinket ( the council one) 5.2, is it worth replacing relic of yu'lon for this? i cant find any reliable data thanks XD