RPPM Analysis + Haste Benefits / 5.2 Trinket Analysis

[Tehstool]

He had 30.4% uptime on renataki's that's insanely high. That's ~2228.776 agility.

[Ganbai]

He had 30.4% uptime on renataki's that's insanely high. That's ~2228.776 agility.

Eh... I read it as 17,4%... I forgot to check for the bossfight only. >.<

But I agree, that is really high.

[wimp]

Thoughts?

It looks like you were lucky with procs and general stats gods smiling upon your throughout that fight - top logs tend to be just, the top percentiles.

If you want to check the value of haste, I suggest you take a log of your usual rotation against a dummy for over 30 minutes (the longer the test, the more useful the results). The haste-proc relation which Conjor has mathed out is solid, but if you want to double check, reforge to a crit>haste setting, and take another log.

If you do run the tests (and i and many others would be grateful - the more data points the better!), it would be helpful for the theorycrafting if you could post your results in this thread - link to WoL and mention the base haste percentage your toon had when you carried out the test. If you use skada, you can keep track of your buff uptimes as you do this.

Unless haste is about as valuable as crit/mastery, The only scenario where I could envisage haste becoming more important is if using Rune paired up with another RPPM trinket. But as a hunter, I'm not sure how you'd feel about having all your crit disappear... Probably not too different from how I feel about losing all my mastery as an assassination rogue.

[Glurp]

What do you think about Talisman of Bloodlust. With enough haste and RPPM uptime on everything could get even better. Do you think it would be worth spending my EPGP on for raid tomorrow?

[Conjor]

There are some issues with a few formulas. I'm fixing them now.

--EDIT--

Fix them. Were only issues with the proc on pull and maximum time to proc formulas. I rearranged the document too because it was a disaster in terms of organization and notation.

[Saoron]

with the trinks and 2pc and meta.. is haste better than crit now ? i'd have to see some more logs, one could just be a fluke. But those numbers are definitely hard to ignore.. What result are you getting in FD glurp ? comparing the haste build with your old crit build ?

[Deleted]

with the trinks and 2pc and meta.. is haste better than crit now ? i'd have to see some more logs, one could just be a fluke. But those numbers are definitely hard to ignore.. What result are you getting in FD glurp ? comparing the haste build with your old crit build ?

I find it hard to believe that haste will surpass crit, but it will most likely surpass mastery unless it is a very high AoE fight.

[Moozhe]

I have been testing my RPPM trinket (Bad Juju 528) for about 2 hours now on a dummy. The uptime has stayed steady at around 24-24.5%.

According to my math in my spreadsheet here, with my haste rating of 16% I should be seeing an uptime of around 21.26%. The actual uptime I'm getting is reflecting that 2x my haste is contributing to the uptime. For example, the base uptime of 18.33% and I have 16% haste, so 18.33 * 1.32 = 24.20% uptime.

This type of change can happen at any moment on the server side without even a hotfix. Here's a screenshot showing the results from my test.

In any case, your calculations with 0% haste are quite different from mine. If you were to take an easy example like a 0.50 RPPM trinket, that's one proc roughly every two minutes. With a 20 second duration, that's 20 out of 120 seconds of uptime, or 16.66% uptime. So a 0.55 RPPM trinket should be 10% higher uptime, or 18.33% uptime. In the same scenario your spreadsheet is showing only a 16.75% uptime.

[Conjor]

I have been testing my RPPM trinket (Bad Juju 528) for about 2 hours now on a dummy. The uptime has stayed steady at around 24-24.5%.

According to my math in my spreadsheet here, with my haste rating of 16% I should be seeing an uptime of around 21.26%. The actual uptime I'm getting is reflecting that 2x my haste is contributing to the uptime. For example, the base uptime of 18.33% and I have 16% haste, so 18.33 * 1.32 = 24.20% uptime.

This type of change can happen at any moment on the server side without even a hotfix. Here's a screenshot showing the results from my test.

In any case, your calculations with 0% haste are quite different from mine. If you were to take an easy example like a 0.50 RPPM trinket, that's one proc roughly every two minutes. With a 20 second duration, that's 20 out of 120 seconds of uptime, or 16.66% uptime. So a 0.55 RPPM trinket should be 10% higher uptime, or 18.33% uptime. In the same scenario your spreadsheet is showing only a 16.75% uptime.

First off, your napkin math ignores some things like overlapping of procs.

Secondly, The math for dealing with non-icd trinket procs has been discussed several times and the formulas have never changed. It's a simple analysis of a decaying exponential chance at a proc. In fact, in your screen shot you are seeing a lower uptime then expected with your Bottle. Welcome to the world of randomness!

Thirdly, and I have said this many times to several people now, this is an approximation to what you will see in game. This analysis is completely theoretical. The spreadsheet is not a simulation tool and it was never meant to be one. It is not going to give you 100% accurate results. This is an attempt to see how the RPPM mechanic is expected to preform in a vacuum, on average, ad infinatum.

It is important to remember that the entire RPPM system is based on randomness. Complete and utter randomness! All I can do with the math is tell you what, on average, you can expect to see. That is it. I do not claim anything more than that with my numbers.

And yes, logs are nice, I have looked through a great many. Sometimes the trinket uptimes are less then my estimates. Sometimes they are more. That is just how the randomness of the RPPM system works. And I wouldn't have it any other way. I actually enjoy the system much more than the old one. This is definitely a case where understanding the inner workings of something does not detract from its "beauty" (if I can play on an old saying), but rather enhances it.

P.S. Tell Crooklyn I miss him! loljk.

---------- Post added 2013-03-16 at 07:27 PM ----------

I just added some more formulas at the request of Zeherah. Hopefully I can get to see some practical usage for my work lol.

[Nitwit]

I have been testing my RPPM trinket (Bad Juju 528) for about 2 hours now on a dummy. The uptime has stayed steady at around 24-24.5%.

According to my math in my spreadsheet here, with my haste rating of 16% I should be seeing an uptime of around 21.26%. The actual uptime I'm getting is reflecting that 2x my haste is contributing to the uptime. For example, the base uptime of 18.33% and I have 16% haste, so 18.33 * 1.32 = 24.20% uptime.

Are you accounting for the hotfix to RPPM mechanics (i.e. proc chance starts increasing whenever you haven't seen a proc for 1.5x+ expected proc interval)?

This should result in ~13.07% increased procs over what you'd expect from the RPPM value (21.26 x ~1.1307 = ~24.04% expected uptime, which is close enough to your observed 24-24.5%).

Can see the math behind that through the link of your choice:
http://elitistjerks.com/f73/t130885-...8/#post2264744 (in the linked twitter status photo)
http://elitistjerks.com/f78/t131716-...4/#post2265639 (includes a linked graph illustrating the downward shift in expected proc interval)
http://www.mmo-champion.com/threads/...1#post20512410

[Conjor]

Are you accounting for the hotfix to RPPM mechanics (i.e. proc chance starts increasing whenever you haven't seen a proc for 1.5x+ expected proc interval)?

This should result in ~13.07% increased procs over what you'd expect from the RPPM value (21.26 x ~1.1307 = ~24.04% expected uptime, which is close enough to your observed 24-24.5%).

Can see the math behind that through the link of your choice:
http://elitistjerks.com/f73/t130885-...8/#post2264744 (in the linked twitter status photo)
http://elitistjerks.com/f78/t131716-...4/#post2265639 (includes a linked graph illustrating the downward shift in expected proc interval)
http://www.mmo-champion.com/threads/...1#post20512410

Interesting info. I shall retire to the nerdery with my calculators and see what comes out.

---------- Post added 2013-03-17 at 04:01 AM ----------

OK I basically redid everything, checking it against Mathematica (was doing it by hand before).

New math sheet, spreadsheet updated. Ermuhgerd maths.

[wimp]

My previous post got left behind due to the time delay in posts for people with few posts... But good to see the maths moving!

Right then, here are my quick pre-breakfast thoughts on the new math:

1) The equations seem to model the ICD trinkets more accurately (since bad luck protection has been included, which brings us to my second point).

2) I like you've obtained a formula for the bad luck protection by integrating over the two ranges. The multiplying results by 13.07% at the end felt rather dirty, however much one loves Flannagan's finagling factor (or skinner's constant, depending on where you're from).

2) I'm not certain the new formulas for uptime of trinkets without ICD are taking into account proc overlap (which the old ones were). Again, this is from a quick look, the uptime value of Bloodlust appears to be too high (compared to logs, simulations), and goes over 100% uptime at 60% haste (a high value of haste, granted, but not an impossible one). Also, suspicious of the equation allowing uptime to go over 100%.
____
Edit:

Just looking at the changes for the ICD trinkets between the previous version and this version of the math (which are the changes to account for the bad luck protection), I'm puzzled by the fact the uptime percentage increase is different, not just for different trinkets, but also for different versions of the same trinket in the case of rune. As mentioned above in this thread, we were expecting this number to be 13.07% (as derived here: https://pbs.twimg.com/media/BFRHvJ4CQAANzmS.jpg:large by @HamletEJ).

However, comparing your old and new equations, I'm getting:

Renataki's: 12.15% increase

Rune: here the changes depend on the ilvl, rather peculiarly.
541 - 13.44% increase
535 - 13.26% increase
528- 13.07% increase
522 - 12.93% increase

Now, these differences aren't huge, but perhaps a bit too large to be put down to mathematica's aproximation?

[There are very large deviations for the non ICD trinkets, but I'm not including those here as I believe they are due to proc overlaps as mentioned in 2) above]

As of now, your previous formulas * 13.07 seem to be a closer match to the data than the new ones. But

[Conjor]

My previous post got left behind due to the time delay in posts for people with few posts... But good to see the maths moving!

Right then, here are my quick pre-breakfast thoughts on the new math:

1) The equations seem to model the ICD trinkets more accurately (since bad luck protection has been included, which brings us to my second point).

2) I like you've obtained a formula for the bad luck protection by integrating over the two ranges. The multiplying results by 13.07% at the end felt rather dirty, however much one loves Flannagan's finagling factor (or skinner's constant, depending on where you're from).

2) I'm not certain the new formulas for uptime of trinkets without ICD are taking into account proc overlap (which the old ones were). Again, this is from a quick look, the uptime value of Bloodlust appears to be too high (compared to logs, simulations), and goes over 100% uptime at 60% haste (a high value of haste, granted, but not an impossible one). Also, suspicious of the equation allowing uptime to go over 100%.
____
Edit:

Just looking at the changes for the ICD trinkets between the previous version and this version of the math (which are the changes to account for the bad luck protection), I'm puzzled by the fact the uptime percentage increase is different, not just for different trinkets, but also for different versions of the same trinket in the case of rune. As mentioned above in this thread, we were expecting this number to be 13.07% (as derived here: https://pbs.twimg.com/media/BFRHvJ4CQAANzmS.jpg:large by @HamletEJ).

However, comparing your old and new equations, I'm getting:

Renataki's: 12.15% increase

Rune: here the changes depend on the ilvl, rather peculiarly.
541 - 13.44% increase
535 - 13.26% increase
528- 13.07% increase
522 - 12.93% increase

Now, these differences aren't huge, but perhaps a bit too large to be put down to mathematica's aproximation?

[There are very large deviations for the non ICD trinkets, but I'm not including those here as I believe they are due to proc overlaps as mentioned in 2) above]

As of now, your previous formulas * 13.07 seem to be a closer match to the data than the new ones. But

I used Mathmematica to give me the approximate formulas (for the most part). It wasn't a blind multiplication but just a reduction from a complex form into a simpler one (with some approximations on nonrepeating decimals along the way).

I'll look at the other points when I get some time.

[Glurp]

27.4% uptime on 522 Soul Charm on Primordius (I screwed up the puddles a bit) and 29.7% on Dark Animus (I hate this fight so much) gemming Agi > Haste > Crit > Mastery

[wimp]

I used Mathmematica to give me the approximate formulas (for the most part). It wasn't a blind multiplication but just a reduction from a complex form into a simpler one (with some approximations on nonrepeating decimals along the way).

I'll look at the other points when I get some time.

Thanks, I look forward to your thoughts on the other points. As for the blind multiplication characterisation, I thought I should clarify I didn't mean to suggest the formulas you derived boiled down to a blind multiplication - they aren't (and I appreciate their simplicity!). Nor is my suggestion to increase average uptimes by that amount a blind multiplication (or rather, it is a simple multiplication, but an informed one underpinned by the maths linked). On this point, I'm mostly querying the (small but non negligible) differences between these two approaches, as they fall outside the .1% margin of error you mentioned in your paper.

[Walajanilu]

gemming Agi > Haste > Crit > Mastery

Sounds like the worst idea i have ever heard.

[Glurp]

Sounds like the worst idea i have ever heard.

Why? Experimenting with how much haste effects RPPM. Since RPPM trinkets proc agi it's actually possible to directly convert Haste into Agility to a certain extent.

[Tehstool]

Why? Experimenting with how much haste effects RPPM. Since RPPM trinkets proc agi it's actually possible to directly convert Haste into Agility to a certain extent.

I would've done some calculations before doing it in a raid setting and if it looked good, then I would've tried it.

[Conjor]

Thanks, I look forward to your thoughts on the other points. As for the blind multiplication characterisation, I thought I should clarify I didn't mean to suggest the formulas you derived boiled down to a blind multiplication - they aren't (and I appreciate their simplicity!). Nor is my suggestion to increase average uptimes by that amount a blind multiplication (or rather, it is a simple multiplication, but an informed one underpinned by the maths linked). On this point, I'm mostly querying the (small but non negligible) differences between these two approaches, as they fall outside the .1% margin of error you mentioned in your paper.

This would be my first stab at it. Been letting Mathematica chug along for a while at it.

(*No ICD*)
(*H:=1.9
R:=3.3
\[Lambda]:=R (1+H)/60
tdur:=20*)
\[Lambda]t1[t_] := \[Lambda]
\[Lambda]t2[t_] := 3 \[Lambda]^2 t - 3.5 \[Lambda]
P1[t_, n_] := 
 Exp[-Integrate[\[Lambda]t1[u], {u, 0, t}]] \[Lambda]t1[t]^n/(n!)
P2[t_, n_] := 
 Exp[-(Integrate[\[Lambda]t1[u], {u, 0, 3/(2*\[Lambda])}] + 
      Integrate[\[Lambda]t2[u], {u, 3/(2*\[Lambda]), 
        t}])] \[Lambda]t2[t]^n/(n!)
Re[Integrate[tdur*P1[t, 1], {t, 0, 3/(2*\[Lambda])}] - 
   Integrate[(tdur - t)*P1[t, 1], {t, 0, tdur}] + 
   Integrate[tdur*P2[t, 1], {t, 3/(2*\[Lambda]), Infinity}]]/tdur

[Saoron]

I would've done some calculations before doing it in a raid setting and if it looked good, then I would've tried it.

it's irrelevant on farm content.. besides, he did try it on durumu and posted the logs.. Which showed a significant improvement.. But that is still just one log.. i'd suggest keeping that setup for farm and post more logs so we can get some real data to work with.