Calculating the avoidance value of expertise

[Wrathy]

I have been spreading the word about these findings, with due credit. I also tabulated the results here:
http://pwnwear.com/2010/02/11/parry-has ... n-citadel/

I would have to say that my sites number 1 hits per day are searching about parry hasting too. It is just too bad they turned it off, because I was getting giddy to use my hard cap expertise set

[Ros]

These theorycrafting results about parry hasting seem to be getting a lot of attention, which is very nice. However, I believe the parry-haste theorycraft still suffers from an error. The amount of haste gained on average when parrying an attack is not 24%, as originally stated in the "Riddle me this - Parry Mechanics" thread on elitistjerks.com, and used in the discussions and calculations in this thread. The problem is related to the fact that weapon swing speed and haste are inversely proportional.


1. The simple mistake, and the naive (but wrong) solution
The error begins here.
Suppose your weapon speed is W. It is true that parrying an attack reduces the time on your next swing by 0.24W (24%), to 0.76W. But that does not mean you gained 24% haste. By the usual WoW definition of haste, swing speed (S) as a function of haste (H) is
S = W/(1 + H)
.76 = 1/(1 + H)
H = 31.6%
So decreasing your swing speed by 24% means you gained 31.6% haste, since they are inversely related. However ....

2. The subtler error, and the complicated (but correct) answer
The previous paragraph is closer to correct, but still wrong. Let us denote the operation of averaging a quantity X over the time of a swing as <X>. For convenience, let the weapon swing time (W) be normalized to 1.
We know the following: the average swing time when you make a parry is 0.76
<S> = 0.76
We want to find the average haste that you gain when you make a parry, <H>. H and S are related like this:
S = 1/(1 + H)
H = 1/S - 1
The naive solution assumed that <H> = 1/<S> - 1, but that is false since integration and division are non-commutative operations. This is how to perform the averaging operation correctly:
<H> = < 1/S - 1 >
We know S, and therefore H, as a function of time:

Code: Select all

       {1           for t <= .2 ,
S(t) = {1.2 - t     for  .2 < t <= .6 ,
       {0.6         for  t > .6


I leave it for the reader as an exercise to integrate H(t) from 0 to 1 to find <H>.
If my calculations are correct the answer is <H> = ln(5/3) - 2/15 = .377 , meaning that when you parry an attack, the average amount of haste you gain on your next swing is 37.7%. I'd appreciate it if someone could double-check that.

This should all be conceptually clear if you look at these graphs (pretend the axes are normalized to 1). Transforming the swing speed to a haste percentage stretches the shape and proportions of the graph. You can visually estimate the average value of the 2nd graph; it is close to 38% as I calculated.

I'm quite interested to see how the results in this thread would change if this error is corrected. The change from 24% haste to 38% could have significant effects; that is an increase of over 50%. However it is mostly an academic interest at this point. Also I'm looking forward to saying good riddance to parry-haste in Cataclysm.

[jere]

I leave it for the reader as an exercise to integrate H(t) from 0 to 1 to find <H>.

Oh no you don't! That was the most annoying thing ever in college textbooks. "This next equation requires a Volume integral done over a recursive Series equation, which must be done during a full moon under the effects of bad tacos from the suspect Mexican restaurant down the street, but we'll leave that up as an exercise for the reader". Don't you start too lol.

[theckhd]

These theorycrafting results about parry hasting seem to be getting a lot of attention, which is very nice. However, I believe the parry-haste theorycraft still suffers from an error. The amount of haste gained on average when parrying an attack is not 24%, as originally stated in the "Riddle me this - Parry Mechanics" thread on elitistjerks.com, and used in the discussions and calculations in this thread. The problem is related to the fact that weapon swing speed and haste are inversely proportional.
.....

If my calculations are correct the answer is <H> = ln(5/3) - 2/15 = .377 , meaning that when you parry an attack, the average amount of haste you gain on your next swing is 37.7%. I'd appreciate it if someone could double-check that.

I double-checked your math, and I also get 0.377 for the integral. So the statement made in the post you quoted:

So your average swing speed as a result of a parry is 0.4*0.6 + 0.2*1 + 0.4*0.8 = 0.76. In other words, 1% parry is worth 0.24% haste.

is certainly incorrect. The correct statement would either be that it's worth 0.377% haste, or that "when you parry an attack your swing timer is reduced by 24% of it's un-hasted value, on average."

However, I don't think this ends up affecting the calculation, as it wasn't derived in terms of haste at all. I worked out the problem in detail over here, but here's the short version:

In a time period T, you make N=T/W attacks in the absence of parry haste. To include parry-haste, you can view it one of two equivalent ways: You're either increasing the number of attacks made in time T from N to N+dN, or you decrease the amount of time it takes to make N attacks from T to T-dT. The two methods are equivalent (as I've shown in the linked thread), so we'll just look at the second version for now.

In T, you expect to parry T*Pp*Rb attacks, where Pp is your parry chance and Rb is the boss's attack rate (i.e. 1/W_boss). Each parry reduces the time taken by 0.24*W, such that

Code: Select all

dT = 0.24*W*T*Pp*Rb[/b].

Just to check that this makes sense, this is

Code: Select all

dT = (swing timer redux per parry)*(total time T)*(Boss Parry Chance)*(Boss Attack Rate)
dT = (swing timer redux per parry) * (total number of parries in time T)

We define c = 0.24*Pp to make the equations a little simpler. So our net attack rate 1/S after parry-haste is:

Code: Select all

1/S = N/(T-dT) = N / (T - c*W*Rb*T) = N/T * 1/(1-c*W*Rb) = 1/W * 1/(1-c*W*Rb)
(1-c*W*Rb)/S = 1/W
1/S = 1/W + c*W*Rb/S

or, defining Rao = 1/W as our base attack rate before parry-hasting effects, and Ra=1/S as our attack rate after parry-haste is included, we have:

Code: Select all

Ra = Rao + c*W*Rb*Ra/Rao

This is exactly the formula used in the simulation (from the OP under "Simulation Details"):

Code: Select all

Ra = Rao + c1*Rb*(Ra/Rao)
Rb = Rbo + c2*Ra*(Rb/Rbo)

c1=0.24*Pp/100
c2=0.24*Pb/100

Just to check, let W=1 (and thus Rao = 1/1 = 1). Then the equation for Ra=1/S becomes:

Code: Select all

Ra = 1 + c1*Rb*Ra
Ra*(1-c1*Rb) = 1
S = 1 - c1*Rb

If we consider a single parry-hasted swing (c1=0.24, Rb=1), we get S = 1 - 0.24 = 0.76, which is consistent with both the 37.7% haste your calculation predicts and our understanding of the parry-haste mechanic.

It's really a shame that all of this math is going to be irrelevant once Cataclysm comes out, given how much time tlitp and I have put into getting it right.

[tlitp]

If my calculations are correct the answer is <H> = ln(5/3) - 2/15 = .377 , meaning that when you parry an attack, the average amount of haste you gain on your next swing is 37.7%. I'd appreciate it if someone could double-check that.

I double-checked your math, and I also get 0.377 for the integral. So the statement made in the post you quoted:

So your average swing speed as a result of a parry is 0.4*0.6 + 0.2*1 + 0.4*0.8 = 0.76. In other words, 1% parry is worth 0.24% haste.

is certainly incorrect. The correct statement would either be that it's worth 0.377% haste, or that "when you parry an attack your swing timer is reduced by 24% of it's un-hasted value, on average."

However, I don't think this ends up affecting the calculation, as it wasn't derived in terms of haste at all.

I'm also getting 0.377 for the integral. But, as Theck already pointed out, the MATLAB code never used actual "haste" for the PHR factors. We've only worked with swing timers.

Furthermore, the data that Tree gathered for the testing of BW in a "real life" scenario is a strong back-up for the model inserted into the MATLAB code. The observed (average) swing timer of Tree was ~2.75, whereas the code offers a ~2.73 estimate.

It's really a shame that all of this math is going to be irrelevant once Cataclysm comes out, given how much time tlitp and I have put into getting it right.

It's a shame to see interesting mechanics vanish away, agreed. But I'm not sorry at all that our work will become devoid of meaning - we had loads of fun bashing our heads, while confronted with something that is actually worthy of theorycrafting.

[Ros]

However, I don't think this ends up affecting the calculation, as it wasn't derived in terms of haste at all.

I see, very good. At first I just glanced at the 0.24 in your calculations and assumed it would have to change, but that number is used correctly in the context of swing time reductions. Anyway, my main point was to reveal and correct the error from the old EJ thread. I was referring to the information from that thread in particular when I said "the parry-haste theorycraft still suffers from an error".

[Awyndel]

No harm done man. Doesn't hurt to check up on things.

[theckhd]

Yup. I wish people would look for errors in my calculations more frequently, to be honest. While it takes me time to answer the questions, it helps ensure the math is correct and helps fix errors more rapidly.

[Oldpappa]

Can we combine two thoughts then - the threat from expertise and the avoidance from expertise and have a summary given the parry haste data / bosses?

[Wrathy]

There is a thread on parry haste enabled bosses, and it has basically (and unfortunately) made this great work a labor of love, and not of practical use. The only bosses which have parry haste turned on are Lady Deathwhisper and Sindragosa, both of which are fight where melee damage is not the primary concern.

The post on parry haste enabling/disabling can be found here.

[Awyndel]

Well I think last time we checked expertise was the best single target and multitarget thread stat, so even if this works only on trash and 2 bosses, its a nice freeby for an already nice stat.