Calculating the avoidance value of expertise

[theckhd]

Is this taking into consideration that not all parries lead to a hasted attack? As I understand if anyone has 20% to go on its swing timer and they parries an attack they gain no benefit.

Yes, that's the 0.24 in the formulas. Someone did some calculations to determine that the average amount of parry-haste you get is about 0.24 due to the "less than 20%" limitation. Unfortunately, I'd have to do some digging to find the link, it was in my PM Inbox but was lost when the admins had to purge a portion of it a few weeks ago.

Theck, I was wondering why you take a boss swing speed of 2.0 seconds. Since this is about paladins tanking the boss, I would assume you have a 100% uptime of JotJ and thus the base swing speed would be 2.4 seconds.

Partly because not all bosses have a base swing speed of 2 seconds. For example, Vezax is 1.8 seconds after JotJ.

The other reason is that the longer a boss's swing speed, the less important parry-haste is to us as tanks. Yes, a parried attack will speed up their next attack by more seconds, on average, than a faster-attacking boss. But the real danger to us as tanks is a series of hits, like "hit, parry-hasted hit, hit." That sequence will occur more quickly vs. a boss who has a faster base swing speed than it will against a slower one, increasing the danger slightly. This does mean that my estimate of the value of expertise will be a little larger than if I had used a 2.0 base boss swing speed, but it's (hopefully) also more relevant to the situations that are likely to kill us.

[theckhd]

By the way, I made a few slight errors in the second calculation I posted. Luckily one of the errors served to basically correct all of the others.

Just for clarity though, I'll go through the math step-by-step to demonstrate the errors, and explain why they canceled out (sort-of).

First of all, we'll start with the formula for player swing speed:

Code: Select all

1/player_swing_speed = 1/1.3 + (1-boss_avoid)/1.3 + 1/6 + (1-boss_avoid)/6
                     = (2-boss_avoid)/1.3 + (2-boss_avoid)/6

This is basically correct, for now anyhow. Next, let's look carefully at the parryhaste formulas:

Code: Select all

player_parryhaste = (1+((player_swing_speed.*(player_parry./100).*0.24)./boss_swing_speed))
boss_parryhaste=(1+((boss_swing_speed.*(boss_parry./100).*0.24)./player_swing_speed))

There are a few important notes here, and the easiest way to get them all across is to dissect the formulas:

• The general form is (1 + haste_factor_due_to_parrying_opponent's_attacks)
• the second term has four components:
  
  1. The unit's parry % (player_parry for the player, boss_parry for the boss). Self-explanatory and static (constant). Can be read off of the character sheet.
  2. 0.24, which is the factor that represents the average amount of haste you get due to the way the parry mechanic works (capping the attack speed at 20%). Again, I need to find a link to the source for this, just to confirm it's right.
  3. The player's swing speed. This is where it get's interesting, because player_swing_speed is modified by player_parryhaste.
  4. The boss's swing speed. This is also interesting, because boss_swing_speed is modified by boss_parryhaste, which comes later.
• The swing speeds make this set of relations recursive. In other words, when we calculate player_parryhaste and boss_parryhaste due to the initial player_swing_speed and boss_swing_speed, we've calculated the factor that governs how much faster both units are swinging. But that's effectively a change to player_swing_speed and boss_swing_speed (because we're attacking faster now, since we have more attacks in a given period of time due to the extra swings after a parry).
  
  So now that we've changed player_swing_speed and boss_swing_speed, we need to recalculate player_parryhaste and boss_parryhaste again, using the new values. Technically we'd have to repeat this several times to get it all correct.

This is where the first error occurred. I naively wrote:

Code: Select all

player_net_swing_speed = player_swing_speed / ( (1-Reck) (player_parryhaste) )

However, while that would have been correct in the original version where I only considered auto-attacks, it's not right for our new definition of player_swing_speed. Our parries will haste only our next melee attack, not our HotR casts. So technically, we should recalculate player_net_swing_speed by returning to our new definition and inserting player_parryhaste this way:

Code: Select all

1/player_swing_speed = (2-boss_avoid)*(player_parryhaste)/1.3 + (2-boss_avoid)/6

The Reckoning haste factor would be substituted in the same way (multiplicatively with the first term) if we were including it.
As long as we're only concerned with boss auto-attacks (i.e. the boss doesn't have any other parry-able special abilities), boss_swing_speed would still be updated for the next round of iteration as

Code: Select all

boss_net_swing_speed = boss_swing_speed / boss_parryhaste

So as I said, we'd then have to take these values for net_swing_speed, and recalculate the parryhaste values, which we then use to recalculate new swing speeds, which we use to recalculate new parryhaste values, and so forth. Lather, rinse, repeat until the parryhaste values converge to a value, or at least change by less than some sort of tolerance constraint (like 1% or something).

This is where the second error occurred. There's a further wrinkle here, because the term

Code: Select all

player_swing_speed.*(player_parry./100).*0.24

in the player_parryhaste calculation represents the speed-up of our melee auto-attacks. But player_swing_speed represents our net swing speed from auto-attacks, HotR, and HV applications. So it's not the right speed to use in this formula! To do this all properly, we need slightly more specific definitions of player swing speed. Let's let "player_swing_speed" refer to only our melee auto-attack swing speed, and define a new variable that represents our net attack speed:

Code: Select all

player_swing_speed = 1.3 / player_parryhaste
player_attack_speed = 1 /[ (2-boss_avoid)*(player_parryhaste)/1.3 + (2-boss_avoid)/6 ]
                    = 1/ [ (2-boss_avoid) * ( player_parryhaste / 1.3 + 1/6 ) ]

player_swing_speed now properly reflects our auto-attack speed, while player_attack_speed is the mean time between outgoing parry-able attacks (identical to our old definition for player_swing_speed).
We can make a similar definition for bosses, but since all we're considering is auto-attacks,

Code: Select all

boss_attack_speed=boss_swing_speed

Still, we'll use this notation for consistency in the parryhaste formulas, which need to be rewritten as well:

Code: Select all

player_parryhaste = (1+((player_swing_speed.*(player_parry./100).*0.24)./boss_attack_speed))
boss_parryhaste=(1+((boss_swing_speed.*(boss_parry./100).*0.24)./player_attack_speed))

Now for the kicker. This is where the third error occurred, which was the one that fixed everything. In my example I only used half of an iteration, because I calculated our parry-haste based on the default values, and then planned to plug our hasted speed into the boss_parryhaste formula. However, when I calculated boss_swing_speed, I used the original (base) value of player_swing_speed (0.5609), not the incorrectly calculated hasted version (player_net_swing_speed, or 0.5534).

That means that for that calculation, I effectively skipped the iteration process entirely, making it correct as a first-order approximation (and 'correcting' both errors made in calculating the hasted version by ignoring them entirely!).

Now that we see what went wrong, let's quickly do a few iterations correctly to see how it works out.

Starting Values:
boss_avoid = 7.5+2=9.5
boss_swing_speed=2
boss_attack_speed=2
player_parry=20

First iteration: (both parryhaste variables treated as unity for initial speed calcluations)
player_swing_speed = 1.3
player_attack_speed=1/[(2-0.095)*(1/1.3 + 1/6)] = 1/1.7829 = 0.5609

player_parryhaste=1+((1.3*(20/100)*0.24)/boss_attack_speed) = 1.0312
boss_parryhaste=(1+((boss_swing_speed.*(7.5./100).*0.24)./0.5609)) = 1.0642

At this point, all of the calculations from the previous post are correct, because we haven't used player_parryhaste at all.

Second iteration:
player_swing_speed= 1.3 / 1.0312 = 1.2607
player_attack_speed=1/[(2-0.095)*(1.0312/1.3 + 1/6)] = 0.5469
boss_swing_speed=boss_attack_speed = 2 / 1.0642 = 1.8794

player_parryhaste=1+((1.2607*(20/100)*0.24)/1.8794) = 1.0322
boss_parryhaste=(1+((1.8794.*(7.5./100).*0.24)./0.5469)) = 1.0619

recalculating the same stats as before for these new values gives:
redux per point of expertise skill: 0.21%
# of extra attacks due to parries: 9.8745
expertise to remove 1 extra attack: 3.0381
corresponding dodge rating: 24.9051
corresponding dodge % after DR: 0.3418
corresponding number of attacks dodged (compared to 0.4 for expertise): 0.5794

Third Iteration
player_swing_speed= 1.3 / 1.0332 = 1.2594
player_attack_speed=1/[(2-0.095)*(1.0332/1.3 + 1/6)] = 0.5464
boss_swing_speed=boss_attack_speed = 2 / 1.0619 = 1.8835

player_parryhaste=1+((1.2594*(20/100)*0.24)/1.8835) = 1.0321
boss_parryhaste=(1+((1.8835.*(7.5./100).*0.24)./0.5464)) = 1.0620

You can already see we're getting very little change in the values here, which means good convergence even after only a few iterations. The stats work out to be:
redux per point of expertise skill: 0.21%
# of extra attacks due to parries: 9.8824
expertise to remove 1 extra attack: 3.0357
corresponding dodge rating: 24.8852
corresponding dodge % after DR: 0.3416
corresponding number of attacks dodged (compared to 0.4 for expertise): 0.5778

Fourth and further iterations:
These would follow the same pattern. Rather than writing them out, I'll just post tables containing the relevant statistics:

Code: Select all

variable        Iteration #1          #2          #3          #4          #5
player_swing_speed       1.3      1.2607      1.2594      1.2596      1.2596
player_attack_speed  0.56089     0.54687     0.54643     0.54647     0.54647
boss_swing_speed           2      1.8794      1.8835      1.8832      1.8832
player_parryhaste     1.0312      1.0322      1.0321      1.0321      1.0321
boss_parryhaste       1.0642      1.0619       1.062       1.062       1.062

variable                  Iteration #1           #2           #3           #4           #5
redux / exp skill           0.00213946   0.00206198   0.00206815   0.00206762   0.00206766
# extra attacks                9.62758      9.87446      9.88236      9.88156      9.88163
expertise to rem 1 att         3.11605      3.03814      3.03571      3.03596      3.03594
equiv dodge rating             25.5438      24.9051      24.8852      24.8873      24.8871
equiv dod % post-DR           0.350551     0.341831     0.341559     0.341586     0.341584
equiv # att dodged (vs 0.4)   0.559576      0.57941     0.577785     0.577924     0.577912

We see very nice convergence out to more deicmal places than we would ever care for, so 5 iterations should be sufficient.
So to update the summary from the previous post with the new numbers, for a single target:

• Expertise is about 73% as effective as dodge rating for reducing incoming damage (0.207% reduction for 1 expertise skill, compared to 0.282% reduction for an equivalent amount of dodge rating at reasonable DR levels).
• Expertise is about 69% as effective as dodge rating for reducing the number of incoming attacks that connect (0.4 attacks for 3.116 expertise skill, compared to 0.578 for an equivalent amount of dodge rating).
• Each point of expertise rating also gives us about 1/3 of a point of STR.

Again, the code is available here for those interested: calc_expertise_mitigation.m

[theckhd]

By the way, if you plug in 2.4 for boss__swing_speed in the first iteration (or boss_base_swing_speed in the code), you get the following results:

Code: Select all

variable        Iteration #1          #2          #3          #4          #5
player_swing_speed       1.3      1.2671      1.2655      1.2656      1.2656
player_attack_speed  0.56089     0.54915     0.54858     0.54864     0.54864
boss_swing_speed         2.4      2.2284      2.2366      2.2359       2.236
player_parryhaste      1.026      1.0273      1.0272      1.0272      1.0272
boss_parryhaste        1.077       1.073      1.0734      1.0734      1.0734

variable                  Iteration #1           #2           #3           #4           #5
redux / exp skill           0.00256735    0.0024347   0.00244627   0.00244521   0.00244531
redux / equiv dodge         0.00282233   0.00282233   0.00282233   0.00282233   0.00282233
# extra attacks                9.62758      9.13011      9.17351      9.16954      9.16991
expertise to rem 1 att         3.11605      3.28583      3.27029       3.2717      3.27157
equiv dodge rating             25.5438      26.9356      26.8082      26.8198      26.8187
equiv dod % post-DR           0.350551     0.369548     0.367809     0.367967     0.367953
equiv # att dodged (vs 0.4)   0.471939     0.495675     0.493502       0.4937     0.493682


Which proves my initial intuition wrong, because it makes expertise even better (86% as good at mitigating incoming damage, 80% as good at reducing number of attacks that land).

Perhaps I can be forgiven though, it's tough to guesstimate these things though due to the recursion. Increasing boss_swing_speed makes the second term of the player_parryhaste formula smaller, which makes player_attack_speed larger, which should make the second term of boss_parryhaste smaller. However, since boss_swing_speed is also in the numerator of that same term in the boss_parryhaste equation, it should simultaneously make the term larger. I had incorrectly guessed that the denominator contribution (from player_parryhaste) would be the larger factor because of the 0.048 it was multiplied by (0.2*0.24), but that factor is obviously irrelevant because it's multiplicative with both factors.

[Arees]

This might be answered somewhere, but there are way to many numbers and lots of numbers confuse me.

How does expertise compare to parry rating for removing damage? I'm wondering this because I see several pieces with dodge/parry and several with dodge/expertise.... for all I know it might turn out that the dodge/expertise ones give more "avoidance" than a similar item with dodge/parry.

[nutron]

expertise being that good to avoid hits is quite suprising to say the least. Thanks for bringing this to our attention theck, solid work as always.

[theckhd]

How does expertise compare to parry rating for removing damage? I'm wondering this because I see several pieces with dodge/parry and several with dodge/expertise.... for all I know it might turn out that the dodge/expertise ones give more "avoidance" than a similar item with dodge/parry.

I didn't calculate it explicitly for parry, just for dodge. I could calculate for parry as well, I guess, but that's trickier. In general, you can use the rule of thumb for whether to gem dodge or parry here:

Code: Select all

(character_sheet_dodge_% - 10) / (character_sheet_parry_% - 10) = 1.88

If that value (calculated for you in your tanking gear while fully raid-buffed) is above 1.88, then the parry/expertise item is likely better, whereas if you're below 1.88, the dodge/expertise item is probably better.

Technically that's only accurate if the two items have exactly the same amount of expertise and exactly the same amount of dodge or parry rating (i.e. like a gem would be, 10 parry / 10 exp vs 10 dodge / 10 exp). But it's probably as good a rule-of-thumb as you'll be able to get. Trying to compare two different items with different amounts of expertise, dodge, and parry rating is a much more complicated thing to do. It would depend on:
each item's dodge, parry, and expertise rating
your current dodge %
your current parry %
your current expertise

With 9 variables, I couldn't give you a generic answer or easy rule-of-thumb that would be valid for all configurations. The only reliable way to do it would be to incorporate this expertise math into an addon like RatingBuster, so that it could compare each item for you directly.

[Amaranthea]

What we need now is a solid list of which bosses parry haste and which don't.

There was a somewhat similar thread (but with less math, obviously) some time ago that tried to work out the avoidance equivalent of generating fewer parries by using a slower weapon (Broken Promise vs Last Laugh, I believe) and a bunch of people posted the standard "LOL EXPERTISE LOLOL WE DON'T CARE ABOUT PARRYGIB NOOB" response. That might be a worthwhile thing to simulate as well, especially since slow weapons are superior for threat. I have a feeling that slow one-hand melee dps weapons will not only give us the most threat by a significant margin, but also be reasonable choices in terms of damage mitigated against a boss capable of parry haste.

[Arees]

What we need now is a solid list of which bosses parry haste and which don't.

I don't think we need to figure it out. If the boss doesn't parry haste blizz usually tells us about it. I know that Patchwerk doesn't and Ignis doesn't... I don't know about others though.

[Doxa]

Theck,

Any chance of getting some new tests on Blade Ward with the SoV changes? I'm hearing rumblings about it being better in 3.2 and it makes me wonder if it is a result of the SoV changes and more tanks using the Glyph of SoV (i.e. using more expertise).

[theckhd]

There was a somewhat similar thread (but with less math, obviously) some time ago that tried to work out the avoidance equivalent of generating fewer parries by using a slower weapon (Broken Promise vs Last Laugh, I believe) and a bunch of people posted the standard "LOL EXPERTISE LOLOL WE DON'T CARE ABOUT PARRYGIB NOOB" response. That might be a worthwhile thing to simulate as well, especially since slow weapons are superior for threat. I have a feeling that slow one-hand melee dps weapons will not only give us the most threat by a significant margin, but also be reasonable choices in terms of damage mitigated against a boss capable of parry haste.

Sadly, I might have been one of the people who sided with the "parrygib isn't issue" folks. Parrygib itself isn't an issue, or at least not a massive danger like it was before with crushing blows. On the other hand, it's clearly much better for reducing incoming damage than any of us gave it credit for.

I'll run the simulation again with a slow 2.6 weapon tomorrow to see how it changes the result.

Theck,

Any chance of getting some new tests on Blade Ward with the SoV changes? I'm hearing rumblings about it being better in 3.2 and it makes me wonder if it is a result of the SoV changes and more tanks using the Glyph of SoV (i.e. using more expertise).

My guess is that it will increase the proc rate considerably because we've nearly doubled the number of melee attacks we make (via HV applications). Whether that makes it good or not, I'm not sure. I saw some testing somewhere that it was now at around 26% uptime (and mongoose was at 43% or so), but I don't remember exactly where I read that. I think it was the EJ prot thread, but I'm honestly not sure.

Shouldn't be too hard to write a simple simulation to test it if we know the mechanics though. I.e. proc chance, any ICDs, etc.

[Spectrum]

Wow, I don't know what to say. I've always been in the "LOL Hit and Expertise" camp. I'll admit I didn't read through all the details, as I'm really just trying to kill my last 10 minutes at work, but Theckd has a reputation that I trust, so I'm going to go with him on this one.

You've got me seriously considering some expertise on my gear now.

[Petrus]

How does this affect how we gem, though? I'm in the camp that puts Agi/Stam in my red socket (and only one to activate the meta), but at what point should we gem for expertise in that socket instead? I'm not a big fan of it considering it's all over my gear (and if I didn't need the hit from the current neck I have, I'd have 30 expertise which is 7% or something like that; well over dodge cap).

[Torquemada]

After having read this, with a migraine already, I can't possibly understand why they would think they need to simplify itemization...

Theck, you are amazing, and this is no disrespect to you, but I got out of engineering precisely because I couldn't get down into the weeds like this for number crunching and optimization.

[theckhd]

How does this affect how we gem, though? I'm in the camp that puts Agi/Stam in my red socket (and only one to activate the meta), but at what point should we gem for expertise in that socket instead? I'm not a big fan of it considering it's all over my gear (and if I didn't need the hit from the current neck I have, I'd have 30 expertise which is 7% or something like that; well over dodge cap).

I sorta have a post on Gemming Theory half-written as well to address the issue of socket color matching, which would probably be the better framework in which to discuss it. But in short

For pure avoidance, expertise will be weaker than dodge for at least a good while (probably till 70% total avoidance or so, i'll have to calculate the crossover point tomorrow).

However, if you think about it in terms of ipoints; each point of expertise rating is equivalent to 0.8 ipoints of dodge for damage reduction, plus 0.3 ipoints of STR for threat. So it's effectively like getting 10% more itemization points out of your gem, but being limited to splitting it between threat and avoidance.

For the people that gem straight stam except to activate a meta, that's probably not a strategy that sounds appealing. It all depends on how much you value threat and avoidance, which depends on the player. But I'll talk more about that in the gem theory post, when I get it written.

My opinion is that I don't see a great reason to gem expertise yet, because threat isn't as high a priority for most things at the moment. I'll probably continue sticking to agi/stam or pure stam gems, because i prefer the armor from Agi to the threat i'd get from expertise. But it certainly makes me less hesitant to pick up all of the new items with expertise in Coliseum, since I now know it's got serious mitigation/avoidance value and isn't just a weak threat stat.

[Meloree]

I sorta have a post on Gemming Theory half-written as well to address the issue of socket color matching, which would probably be the better framework in which to discuss it.

That's easy. I'll precis it for you. "Wrath of the Lich King and an era of unlimited healer mana and throughput, along with the trivial nature of maintaining threat has reduced protection paladin gearing into the enviably simple situation of having to look at only 2 stats on gear. The stamina, and the armor. Therefore, aside from one token red gem (pick up a 9 stam bonus with it), you should put 30 stam gems in every socket. The only exception is if you're below the defence minimum of 536."

Yeah, it makes me just a little bit sick inside, too.

--
Meloree, <Edge>, Garona